Pasar de la idea a la implementación con comandos de planificación

A quién le sirve. Programadores y fundadores técnicos que usan agentes de código y quieren más orden y menos gasto, con un plan único que se actualiza en cada fase.

Qué hicieron

El fundador montó cinco comandos encadenados (intención, análisis de impacto, planificación iterativa, orquestación de la ejecución y revisión con demostración) que actualizan un único archivo de plan en git, y lo revisa en cada fase. Un CONTRIBUTING.md compartido guía a los agentes, reglas de ESLint se ejecutan como ganchos tras cada edición y un script de aprobación de Bash filtra los comandos. Cuando el agente se porta mal, escribe una regla nueva con sus pruebas.

Cómo salió

Un script orquestador que convierte los planes en flujos de trabajo redujo el gasto de tokens a cerca del 20 % y el tiempo de ejecución de entre 5 y 6 horas a entre 20 y 30 minutos. Aun así revisa casi todo el código con git diff y lo describe como mayormente limpio.

Conviene saber

Las salvaguardas crecieron poco a poco: cada acción no deseada del agente o cada aviso de aprobación se convirtió en una regla nueva, así que cuenta con seguir invirtiendo en ellas.

Qué necesitas

• Claude Code y un proyecto en git.
• Un archivo de normas para los agentes, como CONTRIBUTING.md.
• Reglas automáticas de revisión de código (el caso usa ESLint) y pruebas que se puedan ejecutar.
• Un script (un programa corto) que filtre qué órdenes de la terminal se aprueban solas.
• Tiempo para ir añadiendo reglas según aparezcan los fallos.

Cómo hacerlo tú, paso a paso

1. Crea un CONTRIBUTING.md con las normas del proyecto para que los agentes lo lean.
2. Crea en Claude Code cinco comandos personalizados: intención, análisis de impacto, planificación iterativa, ejecución y revisión con demostración.
3. Haz que todos actualicen un único archivo de plan guardado en git, que tú revisas en cada fase.
4. Configura reglas de revisión de código como ganchos (acciones automáticas) que se ejecuten tras cada edición.
5. Añade un script de aprobación que filtre qué comandos de terminal se aceptan.
6. Prueba la cadena con una función pequeña y revisa los cambios con git diff, el comando que muestra qué ha cambiado.
7. Cuando el agente se porte mal, escribe una regla nueva con sus pruebas para que no se repita.

Monta para mi proyecto [repositorio o producto] una cadena de planificación con comandos personalizados: uno para recoger la intención, otro para el análisis de impacto, otro para planificar, otro para ejecutar y otro para revisar. Haz que el paso de ejecución lance [mis comandos de lint y pruebas] y se detenga si fallan. Pruébalo con esta función pequeña: [idea de la función]. Habrás terminado cuando la función haya pasado por los cinco pasos y yo tenga los cambios revisados. No hagas commit ni push sin preguntarme.

Consejos

• No intentes montarlo todo de una vez. Las salvaguardas del autor crecieron poco a poco, con cada acción no deseada.
• Revisa los cambios antes de aceptarlos. El autor revisa casi todo el código con git diff.
• Que no guarde cambios (commit) ni los suba (push) sin preguntarte.

Preguntas frecuentes

Fuentes

• Hacker News ↗

En el directorio desde el 5 de octubre de 2026.