Últimamente hay mucho “vibe coding”, sobre todo cuando se va a reiniciar el cupo. En ese momento se le tiran un montón de tareas a un Agent. Algunas tareas aparecen como ya completadas y uno no se mete; pero al día siguiente en las pruebas se descubre que no se han terminado. Vuelves atrás y revisas y resulta que se había creado un worktree, pero no se había modificado en `main` y, básicamente, no se había hecho el merge.
Luego le pedí al Agent que revisara de forma más concentrada, y había todavía bastantes worktrees así. Así que los limpió.
Al final le hice agregar una regla en `Agents.md`: no es que no se pueda crear worktree, pero no se puede omitir dejarlos sin limpiar.
--- Referencia: prompt para revisar worktree ---
Ayúdame a ver qué worktrees todavía no se han sincronizado con `main`; los que ya estén sincronizados, elimínalos directamente; los que no, enuméralos: rama, un resumen de los cambios (incluidos los últimos commits), y la sesión correspondiente.
--- Referencia: prompt para limpiar worktree ---
Ayúdame a ver el contenido de estos worktrees; para los que valga la pena fusionar, fusiona y limpia el worktree. Los que no estés seguro, confírmamelo, pero dame recomendaciones claras.
--- Referencia: reglas en AGENTS.md ---
- No debe quedar worktree abandonado: las tareas hechas dentro de un worktree, cuando se terminen, deben eliminar ese worktree y su rama. Antes de borrar, elige una de dos: fusionar en `main`; o si no se fusiona, primero subir (commit) los cambios no enviados a esa rama, poner un tag `archive/<nombre-del-worktree>` para archivarlo, y luego ejecutar `git worktree remove` + `git branch -D`. Las sesiones de los subagents encargadas del “handoff” se encargan de cerrar los worktrees que deriven. Si realmente se necesita conservar algún caso (pendiente de decisión del usuario, o con conflictos por resolver), en la respuesta final debe señalarse la ruta y el motivo explícitamente; no se pueden dejar silenciosamente.
Luego le pedí al Agent que revisara de forma más concentrada, y había todavía bastantes worktrees así. Así que los limpió.
Al final le hice agregar una regla en `Agents.md`: no es que no se pueda crear worktree, pero no se puede omitir dejarlos sin limpiar.
--- Referencia: prompt para revisar worktree ---
Ayúdame a ver qué worktrees todavía no se han sincronizado con `main`; los que ya estén sincronizados, elimínalos directamente; los que no, enuméralos: rama, un resumen de los cambios (incluidos los últimos commits), y la sesión correspondiente.
--- Referencia: prompt para limpiar worktree ---
Ayúdame a ver el contenido de estos worktrees; para los que valga la pena fusionar, fusiona y limpia el worktree. Los que no estés seguro, confírmamelo, pero dame recomendaciones claras.
--- Referencia: reglas en AGENTS.md ---
- No debe quedar worktree abandonado: las tareas hechas dentro de un worktree, cuando se terminen, deben eliminar ese worktree y su rama. Antes de borrar, elige una de dos: fusionar en `main`; o si no se fusiona, primero subir (commit) los cambios no enviados a esa rama, poner un tag `archive/<nombre-del-worktree>` para archivarlo, y luego ejecutar `git worktree remove` + `git branch -D`. Las sesiones de los subagents encargadas del “handoff” se encargan de cerrar los worktrees que deriven. Si realmente se necesita conservar algún caso (pendiente de decisión del usuario, o con conflictos por resolver), en la respuesta final debe señalarse la ruta y el motivo explícitamente; no se pueden dejar silenciosamente.