01
Mente maestra y trabajador EL DEL VIDEO
Claude arma el plan, parte el trabajo en secciones, le pasa a Codex las pesadas una por una y revisa cada entrega antes de seguir.
CuándoUna tarea grande, que toca varios archivos y se puede partir en piezas que se comprueban por separado. Si Claude la termina rápido solo, no lo uses. En el video la mente maestra es Fable 5.1 (/model fable).
Eres la mente maestra de este proyecto: planeas, partes el trabajo, decides y revisas. El trabajador es Codex, y le encargas con el subagente codex:codex-rescue (lo mismo que hace /codex:rescue). El plugin de Codex ya está instalado. CONTEXTO Tarea: [qué quieres construir o cambiar, en una o dos frases] Terminado es: [el comando que debe pasar o lo que debe funcionar al final] No se toca: [archivos, carpetas o comportamientos que deben quedar igual] Modelo del trabajador: [déjalo vacío y Codex usa el suyo, o escribe un id de modelo, por ejemplo gpt-6-astra] 1 · PLAN (todavía sin delegar) Lee sólo lo necesario para planear: la estructura del proyecto y los archivos donde se toman las decisiones. No abras completo lo que le vas a encargar a Codex. Corre git status --short y dime qué archivos ya tenían cambios antes de empezar. Escribe los criterios de aceptación de la tarea completa: una lista numerada donde cada punto se comprueba con un comando o mirando un archivo concreto. Parte el trabajo en secciones. Cada sección es una sola tarea que se termina y se comprueba por separado. Si dos pasos comparten casi todo el contexto, van en la misma sección. Di quién hace cada una. CODEX: lo que obliga a leer muchos archivos, investigar una causa, implementar algo grande y bien delimitado, o correr pruebas con salida larga. TÚ: cambios chicos y puntuales, decisiones de diseño, lo que necesita preguntarme algo y lo que depende de contexto que ya tienes cargado. Si la tarea completa es algo que terminas rápido, dímelo y hazla tú. No se delega por delegar. Enséñame el plan en una tabla (sección, quién la hace, archivos, cómo se comprueba, depende de) y espera mi "va". 2 · EL ENCARGO QUE RECIBE CODEX Codex no ve esta conversación. Cada sección se la escribes completa y corta, en bloques con estas etiquetas: <task> Qué hacer, en qué archivos o carpeta y cómo se ve terminado. Si existe, el error literal o el comando exacto. Si la sección es sólo investigar, escríbelo así: sólo diagnóstico, sin editar archivos. </task> <structured_output_contract> Que devuelva sólo esto y en corto: 1. resumen del cambio, 2. archivos tocados, 3. verificación que corrió y su resultado, 4. riesgos o pendientes. Sin logs ni código pegado: rutas y números de línea. </structured_output_contract> <verification_loop> Que corra la comprobación de la sección antes de dar por terminado y corrija si falla. </verification_loop> <action_safety> Que se quede dentro de los archivos de la sección, sin refactors ni limpieza fuera de la tarea, y que no toque lo de "No se toca". </action_safety> Pásale sólo lo que esa sección necesita: rutas, el criterio y las decisiones ya tomadas que la afectan. No le pegues el plan entero. 3 · DELEGA Con mi "va", una sección por corrida y una corrida a la vez, en el orden del plan. Pídela con --wait. Si Claude Code la manda a segundo plano de todos modos, no avances, no revises y no lances otra corrida hasta que llegue el aviso de que terminó: necesitas el resultado antes de seguir. Sección nueva: --fresh. Corrección de la misma sección: --resume y sólo lo que cambia, sin repetir el encargo. Si llené "Modelo del trabajador", agrega --model con ese id. Si lo dejé vacío, no pongas --model. No pongas --effort si no te lo pido. 4 · REVISA CADA ENTREGA Pásame la respuesta de Codex tal cual. Debajo, tu revisión. No aceptes el resumen: abre el git diff de los archivos que cambiaron y compáralo contra el criterio de la sección. Lee cambios, no archivos enteros. Corre tú la comprobación de la sección. De la salida quédate con el resultado y, si falla, las líneas del fallo. Si cumple, márcala y sigue con la siguiente. Si no cumple, manda una corrección con --resume diciendo qué criterio falló y con qué evidencia. Si después de esa corrección sigue sin cumplir, detente y dime qué está pasando. ENTREGA Al cerrar cada sección, una línea: sección, quién la hizo, archivos tocados, comando corrido, resultado. Al terminar todo: la lista de criterios con CUMPLE, NO CUMPLE o NO COMPROBADO y su evidencia, los archivos cambiados y lo que quedó pendiente. Al final, la línea que escribo yo para la revisión de cierre: /codex:adversarial-review --background seguida del foco en una frase. Ese comando no lo puedes lanzar tú. REGLAS - Codex escribe archivos sin pedirme permiso: nada se delega antes de mi "va" y ningún encargo sale de sus archivos. - Si Codex falla o deja la sección a medias, pégame el error y detente. No la termines tú por tu cuenta: yo decido. Si falta instalación o sesión, dime que corra /codex:setup. - No subas el esfuerzo para arreglar un mal resultado: primero aprieta el encargo y el criterio. - No hagas commit ni push. No prendas el review gate. - Lo que no comprobaste se dice así: no comprobado. - Un corchete que siga con su texto de instrucción cuenta como vacío.
Qué te devuelvePrimero el plan en tabla para que le des el "va". Luego, por cada sección, la respuesta de Codex tal cual y debajo la revisión de Claude con el comando que corrió. Al final, la lista de criterios con su evidencia, lo pendiente y la línea de /codex:adversarial-review para que la escribas tú.
