Jesse Vincent (obra) / using-git-worktrees
¿Debería tu agente de código trabajar en un git worktree aparte?
Para desarrollar funcionalidades, casi siempre. Y casi toda esta skill trata de no crear uno que ya tienes.
Lo que conviene recordar
- Se carga al empezar trabajo en una funcionalidad que necesita aislamiento, o antes de ejecutar un plan, y lo anuncia cuando lo hace.
- Detectar va antes que crear. Compara git-dir con git-common-dir, se protege de los submódulos y nunca crea un segundo worktree dentro del que ya ocupa.
- Una herramienta nativa, que la skill describe con nombres como EnterWorktree o una opción --worktree, gana a git worktree add, que dejaría un estado que el entorno no ve.
- Una base de pruebas que falla se informa en vez de ignorarse, para que los fallos posteriores no se confundan con los que ya estaban.
01Qué cambia en la práctica
Un agente que edita tu copia principal te deja dos malas salidas cuando algo sale mal: separar sus cambios de los tuyos, o tirar ambos. Un worktree le da al agente su propio directorio y su propia rama sobre el mismo repositorio, de modo que un intento fallido te cuesta borrar una carpeta.
Casi toda la skill existe para evitar aislamientos duplicados. Algunos entornos ya ejecutan cada agente en un worktree que gestionan ellos, y un agente que lanza git worktree add encima produce lo que la skill llama estado fantasma, un espacio de trabajo que el entorno no puede ver ni limpiar. El paso 0 comprueba primero, el paso 1 prefiere la herramienta nativa y git queda para el final.
- Directorio: tu preferencia declarada, luego una carpeta .worktrees o worktrees existente, y si no hay, una .worktrees nueva en la raíz del proyecto.
- Preparación: npm install, cargo build, pip install, poetry install o go mod download, según los archivos que encuentre.
- Base: el comando de pruebas del proyecto, con los fallos informados antes de empezar a trabajar.
02Dónde decepciona
La preparación es una consulta fija por nombre de archivo. Un pyproject.toml dispara poetry install, que no sirve en proyectos gestionados con otra herramienta, y un repositorio con varios manifiestos en la raíz recibe todos los comandos que coincidan. En estructuras poco habituales tendrás que corregirla.
En un caso, además, toca tu repositorio por su cuenta: si el directorio de worktrees no está ignorado, lo añade al .gitignore y hace commit. Es lo seguro para el repositorio y aun así es un commit que no escribiste, así que añade tú la entrada si te importa el historial.
Instalación y primera ejecución
- En Claude Code, instala superpowers con /plugin install superpowers@claude-plugins-official. La colección tiene licencia MIT, y esta skill es un único SKILL.md que necesita git y las herramientas de tu propio proyecto.
- Si esperas que use la alternativa con git, añade tú .worktrees/ al .gitignore antes. Si no, la skill añade la entrada y hace commit de ese cambio en tu copia actual.
- Lee el informe de la base de pruebas antes de dejar que el trabajo siga. Si las pruebas fallan antes de cualquier cambio, la skill se detiene y pregunta, y ese es el momento de decidir.
Preguntas que la gente hace de verdad
- ¿Qué es un git worktree?
- Un segundo directorio de trabajo unido al mismo repositorio y con su propia rama, para que dos líneas de trabajo no compartan archivos en disco.
- ¿Creará un worktree sin preguntar?
- No. En una copia normal pregunta primero, salvo que tus instrucciones ya declaren una preferencia, y si dices que no, trabaja donde está.
- ¿Qué skills de superpowers dependen de ella?
- executing-plans y subagent-driven-development la invocan para crear un espacio de trabajo, o verificar el existente, antes de empezar.
Fuentes
Versiones legibles por máquina de esta página