Jesse Vincent (obra) / subagent-driven-development
¿Cómo se construye un plan entero sin tener que confirmar después de cada tarea?
Con un implementador nuevo y un revisor para cada tarea, una detrás de otra, y solo cuatro motivos para parar.
Lo que conviene recordar
- Las tareas van en secuencia. La skill descarta los subagentes de implementación en paralelo porque generan conflictos.
- Cada tarea necesita los dos veredictos, cumplimiento de la especificación y calidad del código, y la autorrevisión del implementador nunca los sustituye.
- El avance se guarda en un archivo de registro dentro de un espacio de trabajo que git ignora, porque la memoria de la conversación no sobrevive a la compactación.
- Cada papel recibe un modelo elegido de forma explícita: uno rápido y barato para las tareas mecánicas y el más capaz disponible para la revisión final de toda la rama.
01Qué cambia en la práctica
Recorrer un plan largo en un solo contexto hace que cada tarea arrastre el desorden de las anteriores. Aquí la sesión que coordina entrega cada tarea a un implementador nuevo junto con la ficha de la tarea, extraída del plan, y después pasa el diff resultante a un revisor como archivo, de modo que su propio contexto queda libre para coordinar.
La ejecución tampoco se queda esperándote. Los conflictos, las ambigüedades y los defectos del plan se deciden en el momento, con la especificación como autoridad vinculante, y cada decisión entra en el registro junto con lo que costaría si fuera errónea. Al terminar, esas decisiones se reúnen en el último mensaje, para que puedas encontrar y deshacer las que no compartas.
02Dónde decepciona
No es barata. Según la propia skill, cuesta un contexto nuevo por tarea y por revisión, mientras que la ejecución en línea cuesta un contexto y un revisor final, y una tarea que sigue sin pasar la revisión puede llegar a cinco rondas de corrección antes de que los hallazgos abiertos se aparquen con una decisión anotada.
También depende de que el plan sea bueno. Las tareas muy acopladas quedan fuera de su alcance, y las decisiones tomadas sin una especificación accesible cuentan como provisionales, así que un plan vago se convierte en una serie rápida de decisiones que tendrás que revisar después.
Instalación y primera ejecución
- Instala superpowers desde obra/superpowers, con licencia MIT. La skill trae su SKILL.md con plantillas de prompt para el implementador y los revisores, siete archivos de referencia y tres scripts de bash.
- Ten el plan escrito antes de empezar y trabaja en un worktree aislado. La skill no empieza a implementar en main o master sin tu consentimiento explícito.
- Cuenta con que llegue hasta el final. Solo se detiene ante una operación irreversible o destructiva, una acción sensible para la seguridad, un efecto fuera del worktree como un push o una publicación, o un plan tan roto que cualquier camino sería adivinar.
Preguntas que la gente hace de verdad
- ¿Lanza subagentes en paralelo?
- No. Los implementadores trabajan una tarea cada vez, y la skill prohíbe lanzar varios subagentes de implementación a la vez porque chocan. Los problemas sin relación que se pueden atacar simultáneamente son el terreno de dispatching-parallel-agents.
- ¿En qué se diferencia de executing-plans?
- Las dos ejecutan el plan en la sesión actual, comparten el mismo espacio de trabajo y el mismo registro, y nunca se paran entre tareas. executing-plans hace todas las tareas en un contexto con un único revisor al final; esta skill usa un subagente nuevo y una revisión para cada tarea.
- ¿Qué pasa cuando una revisión encuentra problemas?
- Empieza un bucle de corrección. En las tres primeras rondas se retoma el mismo implementador, en la cuarta y la quinta se encarga uno nuevo con un modelo más capaz, y lo que siga abierto se aparca con una decisión anotada en el registro. Los hallazgos menores no entran en el bucle y esperan a la revisión final.
Fuentes
Versiones legibles por máquina de esta página