Si construyes con Claude, lo que te falta aprender es a dirigir

Abres Claude Code y escribes lo primero que traes en la cabeza. Te contesta rápido, se siente productivo. Veinte minutos después le pides otra cosa, y otra, y para el turno doce está construyendo lo que entendió de tu última frase, no lo que tú traías desde el principio. No se le olvidó: nunca lo tuvo escrito.

Ese es el techo real de trabajar sin documento. Mientras el plan viva nada más en tu cabeza, tú eres el único que lo conoce, y eso te vuelve el cuello de botella de todo lo que quieras repartir. No puedes delegar lo que no está escrito. Cada agente que lances va a recibir el resumen que se te ocurra en ese momento, distinto del que le diste al anterior.

Por eso el primer paso de orquestar no es abrir la terminal. Es producir un archivo.

Por qué gana un archivo

La forma rápida de sacarlo de tu cabeza

No te sientes a escribirlo. Deja que te entrevisten. El prompt de abajo abre una sesión que no construye nada: pregunta. Una pregunta, se detiene y espera. Si contestas vago, repregunta sobre ese mismo punto antes de avanzar.

Son entre diez y quince minutos, y sí, se siente lento. Es el mismo rato que ibas a perder corrigiendo trabajo mal encaminado, solo que gastado antes y no después.

Vas a entrevistarme para armar la lista de todo lo que tengo que sacar esta semana.

Reglas de la entrevista:
- Una pregunta a la vez. Preguntas, te detienes y esperas mi respuesta antes de la siguiente.
- Nada de preguntas dobles ni de listas de cinco puntos en un mismo mensaje.
- Si mi respuesta queda vaga, repregunta sobre ese mismo punto antes de avanzar.

De cada pendiente tienes que sacarme estas cinco cosas:
1. Qué tengo que entregar exactamente, y a quién le llega.
2. Para cuándo. Fecha concreta, no "esta semana".
3. Qué ya existe y qué es desde cero.
4. Qué NO se debe tocar: archivos, carpetas, accesos, textos que ya están aprobados.
5. Qué significa "terminado" para ese punto, dicho de una forma que se pueda comprobar.

Cuando ya no me quede ningún pendiente por contarte, escribe el archivo SEMANA.md con la lista completa: un bloque por pendiente y esos cinco campos en cada bloque.

No propongas soluciones, no me recomiendes herramientas y no empieces a construir nada. Esta ronda es solo para entender qué hay que hacer.

De cada pendiente te va a sacar cinco cosas: qué se entrega, para cuándo, qué ya existe, qué no se toca y qué significa terminado. El campo incómodo es el último. Ahí es donde vas a descubrir que la mitad de tus pendientes no tienen definición de terminado, tienen una sensación.

# SEMANA.md — del 3 al 9 de agosto

Cinco pendientes. Ninguno se da por terminado sin su criterio.

---

## 1 · Landing de Casa Miralta

- **Entregable:** la página del cliente en /clientes/casa-miralta, con encabezado, tres bloques de servicio, formulario de contacto y pie.
- **Fecha:** viernes 7, antes de las 6 pm. La presento en llamada ese día.
- **Qué existe:** los textos ya están aprobados en textos/casa-miralta.md y el logo está en public/clientes/. La página es desde cero.
- **No tocar:** nada fuera de la carpeta del cliente. El tema global y los componentes compartidos se quedan como están.
- **Terminado cuando:** la página abre sin errores en consola, se ve bien a 390 y a 1280 de ancho, y el formulario manda el correo de prueba a mi bandeja.

---

## 2 · Tres creativos para la campaña de agosto

- **Entregable:** tres piezas, cada una en 1080x1350 y en 1080x1920. Seis archivos.
- **Fecha:** miércoles 5. Se programan el jueves temprano.
- **Qué existe:** concepto y copy aprobados en campanas/agosto/brief.md. Las fotos de producto ya están en la carpeta.
- **No tocar:** el copy no se cambia ni una palabra. Los precios no aparecen en las piezas.
- **Terminado cuando:** los seis archivos existen con el nombre acordado, ninguno recorta el producto, y todo el texto queda dentro de la zona segura de cada medida.

---

## 3 · Agente de WhatsApp que conteste preguntas frecuentes

- **Entregable:** el documento con las preguntas, las respuestas y las reglas de cuándo pasa a una persona.
- **Fecha:** domingo 9. El lunes 10 arranca la prueba con clientes reales.
- **Qué existe:** las conversaciones viejas exportadas en datos/whatsapp/. El bot todavía no existe; esta semana es solo el guion.
- **No tocar:** no se inventan políticas de devolución, tiempos de entrega ni precios. Si falta un dato, se marca como FALTA.
- **Terminado cuando:** hay al menos 15 preguntas con su respuesta, cada respuesta cabe en un mensaje de celular, y está escrito qué se escala a una persona.

---

## 4 · El formulario de contacto no manda correo

- **Entregable:** el arreglo, en el archivo donde esté la falla.
- **Fecha:** hoy. Lleva dos días caído y ahí es donde entran los prospectos.
- **Qué existe:** pasa solo en producción desde el martes; en local sí manda. El proveedor de correo no reporta caídas.
- **No tocar:** no se cambia de proveedor ni se mueven variables de entorno sin avisarme antes.
- **Terminado cuando:** se manda un correo de prueba desde producción y llega, y queda escrito en una línea cuál era la causa.

---

## 5 · Actualizar el README del repo de la tienda

- **Entregable:** README.md al día.
- **Fecha:** domingo 9. Sin prisa, pero sin falta.
- **Qué existe:** el README de hace ocho meses. Los comandos cambiaron y hay dos variables de entorno nuevas.
- **No tocar:** no se agregan secciones nuevas ni se reescribe el tono. Solo se corrige lo que ya no es cierto.
- **Terminado cuando:** cada comando del README corre sin error, y las variables de entorno que pide coinciden con las que usa el código de hoy.

Cinco pendientes revueltos a propósito: una página de cliente, un lote de creativos, un guion de atención, un error caído en producción y un documento viejo. Así se ve una semana de verdad. Este mismo archivo es el que se reparte más adelante.

Cuatro señales de que ya se puede repartir

Si las cuatro se cumplen, ya tienes qué repartir. Si falla una, arréglala aquí: corregirla ahora cuesta un renglón; corregirla después cuesta una tarde de trabajo devuelto.

La regla que corre por ahí es «depende de tu cuenta». Es cierta y no sirve de nada. La razón real no tiene que ver con qué modelo razona mejor, sino con cómo te lo cobran — y eso sí está escrito, plan por plan.

En Max, tanto el de $100 como el de $200, Fable 5 viene incluido: puedes gastar hasta la mitad de tus límites semanales en él sin costo extra. Es muchísimo. Media semana entera dirigiendo con el modelo más capaz que tienes, sin sacar la tarjeta.

En Pro, el de $20, Fable 5 también está disponible, pero no entra en los límites de tu plan. Corre con usage credits de pago desde el primer token. No hay cuota incluida que se acabe primero: el primer mensaje que le mandes a Fable ya es un cargo aparte. Con Opus 5 no pasa eso — Opus sí está dentro del plan de $20.

Pasarte de ese 50% en Max no apaga nada: sigues con usage credits, o te cambias de modelo y terminas la semana dirigiendo con Opus. En el plan gratis Fable 5 no aparece — es exclusivo de los planes de pago.

Disponible no es lo mismo que puesto

Cada cuenta arranca con un modelo por default: Pro abre en Sonnet 5 y Max abre en Opus 5. Fable 5 no es el default de ninguna cuenta, ni siquiera en la de $200. Si lo quieres de director, lo pones tú. Y muchos que ya pagan Max llevan meses dirigiendo con Opus sin saber que tienen Fable incluido ahí adentro.

Se cambia con una línea, al inicio de la sesión, antes de la primera instrucción. El modelo que reparte es el que define la calidad del reparto: si se equivoca ahí, los subagentes ejecutan bien una mala idea.

Los dos alias que te ahorran decidir esto cada vez

Si esta guía completa te suena a mucho trabajo, opusplan es la versión mínima: te da lo esencial del reparto — cabeza cara, manos baratas — sin escribir un solo archivo. Lo que no te da es elegir quién hace qué, ni el contrato de entregable, ni el bucle donde le regresas el trabajo al que no cumplió. Para eso siguen las otras siete paradas.

La perilla que casi nadie toca

Además del modelo puedes elegir cuánto piensa. Con /effort escoges entre low, medium, high, xhigh y max. El default es high, y ahí se queda toda la vida porque nadie lo revisa. Fable 5 y Opus 5 soportan los cinco niveles.

El director es justo el puesto donde subirlo paga solo. Su chamba no es teclear: es partir el trabajo, decidir quién agarra cada pedazo y cachar el entregable que no cumple. Eso se hace una vez por vuelta, no en cada archivo. Un director en xhigh que reparte bien te ahorra tres rondas de subagentes mal instruidos.

Al revés aplica igual: un subagente que solo sigue una instrucción clara no necesita estar en high. Ahí bajarle es ahorro puro, y no se nota en el resultado.

Cómo lo dejas puesto en treinta segundos

Ya tienes la lista y ya sabes qué modelo te toca. Lo que sigue es el minuto donde se decide toda la semana: el primer turno. Si ese turno arranca mal, el modelo grande se pone a construir y ya no tienes director; tienes un obrero carísimo con la lista abierta encima del escritorio.

El arranque son cuatro movimientos. Los dos primeros son obvios. Los dos últimos son los que casi nadie hace, y son los que sostienen todo lo demás.

Aquí va todo lo que necesito terminar esta semana:

[pega aquí tu SEMANA.md, o la lista como la tengas]

No hagas nada todavía. No abras archivos para editarlos, no escribas nada, no me propongas un plan de trabajo.

Lo único que quiero de vuelta en este turno:
1. Qué entendiste. Repíteme cada pendiente con tus palabras, en una línea cada uno.
2. Qué te falta. Qué dato necesitas y no está: rutas, accesos, textos, decisiones que nadie ha tomado.
3. Qué está mal planteado. Cuál de estos pendientes en realidad son dos, cuál depende de otro que va después, y cuál no se puede verificar tal como está escrito.
4. Cuál es el de mayor riesgo y por qué.

Si estás asumiendo algo, dilo con todas sus letras: "estoy asumiendo que...". Prefiero corregirte ahora y no después de que hayas construido media semana sobre una suposición.

Por qué la primera orden es “no hagas nada”

El modelo grande está entrenado para ser útil, y ser útil se ve como empezar. Le pegas una lista de nueve pendientes y el reflejo es agarrar el primero y resolverlo bien. Cuando eso pasa no perdiste un turno: perdiste al director. La cabeza que ibas a usar para repartir se metió a construir el punto uno y sale de ahí sabiendo muchísimo de un solo pendiente.

El costo real está en el contexto. La ventana con la que dirige es la misma con la que construye. Cada archivo que abre para resolver el primer punto es espacio que ya no tiene para pensar los otros ocho. Repartir es una tarea de vista amplia y poca profundidad; construir es exactamente lo contrario. No caben las dos en la misma cabeza al mismo tiempo.

La orden de leer primero es lo que lo mantiene en el puesto. Y de paso te compra algo que vale más que el turno: la lista de lo que no entendió. Los huecos que te devuelve ahora son los mismos que, si nadie pregunta, se vuelven suposiciones repartidas a cuatro agentes que van a construir sobre ellas toda la semana.

Claude Code te da cuatro maneras de repartir un trabajo de varios pasos. Se anuncian como cosas distintas, pero en la práctica compiten por el mismo encargo, y por eso la pregunta útil nunca es cuál es más potente.

Lo único que de verdad cambia entre las cuatro es quién sostiene el plan mientras el trabajo corre: Claude decidiendo turno a turno con lo que le acaban de entregar, o un script que ya decidió todo antes de arrancar. Cuántos agentes, con qué modelo, qué tan largo: todo eso se acomoda solo una vez que respondes esa pregunta.

De las cuatro, para dirigir te importan dos y media. Los subagentes son el piso y son la sección 05: así vas a repartir casi todo lo que repartas. Los workflows y los equipos son las dos rutas de la sección 07, y se eligen exactamente por lo que acabas de leer — si el reparto se repite, workflow; si los trabajadores tienen que retarse entre ellos, equipo.

Las habilidades quedan fuera de esta conversación y está bien que así sea. No reparten trabajo: guardan criterio. Son otro tema, y hay guías enteras en la bóveda dedicadas a eso.

Dirigir se ve así: en vez de una sesión que hace todo, tienes cuatro trabajadores con nombre, cada uno con su propia ventana de contexto, y tú decides quién es quién. La decisión que más cambia el resultado no es cómo escribes el prompt. Es a quién le toca cada pendiente y con qué modelo lo resuelve.

Y el reparto se hace una vez. Un subagente no es una conversación: es un archivo. En ese archivo cabe la instrucción, el modelo y el nivel de esfuerzo, así que la decisión de “esto lo hace Opus” deja de tomarse cada lunes.

El criterio no tiene que ver con qué tan difícil se ve la tarea, sino con cuántas decisiones quedan abiertas cuando la sueltas.

Antes de que exista un solo archivo de agente, pídele el organigrama. Se revisa en pantalla y se corrige ahí mismo, que sale mucho más barato que corregirlo cuando ya hay cuatro agentes escribiendo al mismo tiempo.

Ya leíste SEMANA.md. Ahora reparte el trabajo.

No lo hagas tú. Vas a crear subagentes y asignarles la lista.

Antes de tocar nada, devuélveme:
1. Cuántos agentes propones y el rol de cada uno, con nombre en minúsculas y con guiones.
2. Qué modelo le toca a cada uno, Opus o Sonnet, y la razón en una línea. El criterio: Opus para lo que necesita criterio, decisiones de arquitectura o texto que va a leer un cliente. Sonnet para ejecución acotada y repetitiva, donde ya está claro qué hay que hacer y solo falta hacerlo.
3. Qué pendientes de la lista le tocan a cada agente.
4. Qué archivos o carpetas es dueño de tocar cada uno, y cuáles tiene prohibidos. Dos agentes no pueden ser dueños del mismo archivo.
5. Qué se puede correr en paralelo y qué tiene que esperar a que otro termine.

Si dos tareas se pisan, dímelo y propón cómo separarlas, en vez de dárselas al mismo agente para salir del paso.

Preséntamelo como tabla y ahí detente. No escribas los archivos de agente ni empieces a construir hasta que yo apruebe el reparto.

Cuando el reparto ya te cuadra, cada rol se convierte en un archivo markdown. Nada más que eso: texto plano con un encabezado. Arriba va el frontmatter, entre tres guiones, con los datos que Claude usa para decidir a quién delegarle. Abajo va la instrucción del agente, escrita como si le hablaras a alguien que llega el primer día.

Lo que hace que esto sirva para dirigir es que el modelo queda escrito en el archivo. No vuelves a decidir cada vez si esto era de Opus o de Sonnet: lo decidiste una vez y el reparto se aplica solo, aunque quien delegue sea Claude y no tú.

Dónde lo guardas define quién lo tiene:

Del frontmatter, cinco campos son los que de verdad usas para dirigir. Los dos primeros son obligatorios; sin ellos el archivo no cuenta como agente.

Hay más campos, y dos valen la pena aunque sea de pasada: isolation: worktree le da al agente una copia aislada del repositorio, para que dos que trabajan al mismo tiempo no se pisen los archivos; y background lo deja correr por su cuenta mientras tú sigues en otra cosa.

Los cuatro perfiles que resuelven la semana

Estos son los archivos completos, tal cual quedan en disco. Dos en Opus, porque hay decisiones abiertas y texto que va a leer un cliente. Dos en Sonnet, porque el qué ya está definido y solo falta la ejecución. Toma el que se parezca a tu caso y cámbiale los nombres.

---
name: redactor-landing
description: Arma la landing de un cliente cuando los textos ya están aprobados y falta convertirlos en página. Úsalo para páginas que va a leer un cliente final.
tools: Read, Write, Edit, Glob, Grep
model: opus
effort: high
---

Armas landings de cliente. Trabajas únicamente dentro de la carpeta del cliente que te indiquen: el tema global y los componentes compartidos no se tocan por ningún motivo.

Antes de escribir una sola línea, lee los textos aprobados. No los reescribas por tu cuenta. Si una frase no funciona en la página, deja el original y propón el cambio en tu resumen final.

Estructura mínima: encabezado con una promesa clara, los bloques de servicio que pida el brief, formulario y pie. Los estados de vacío y de error van desde el principio, no al final.

Al terminar entregas la ruta del archivo, qué revisaste a 390 y a 1280 de ancho, y qué quedó pendiente. Si un criterio de aceptación no se cumple, dilo tú antes de que te lo digan.

---
name: guionista-whatsapp
description: Diseña qué contesta un agente de WhatsApp — las preguntas frecuentes, sus respuestas y las reglas para pasar la conversación a una persona. Úsalo antes de que alguien programe el bot.
tools: Read, Write, Edit, Grep, WebFetch
model: opus
effort: high
---

Diseñas conversaciones de atención por WhatsApp para negocios pequeños. Tu entregable es texto, no código.

Las preguntas frecuentes las sacas de lo que ya existe: el sitio, las conversaciones viejas, las notas del cliente. No inventes políticas, precios ni tiempos de entrega. Si un dato no aparece, lo marcas como FALTA y sigues.

Cada respuesta cabe en un mensaje de celular, va en español con "tú" y termina en una sola acción clara. Nada de párrafos ni de despedidas largas.

Defines también qué NO contesta el bot: reclamos, cambios de precio y cualquier cosa con dinero de por medio se pasan a una persona, con su mensaje de transición ya escrito.

Entregas un solo archivo markdown con preguntas, respuestas y reglas de escalamiento, y arriba la lista de todo lo que marcaste como FALTA.

---
name: productor-creativos
description: Produce lotes de creativos de campaña a partir de un concepto ya aprobado, en las medidas que pida cada ubicación. Úsalo cuando el qué decir ya está definido y solo falta la ejecución.
tools: Read, Write, Edit, Glob, Bash
model: sonnet
effort: medium
---

Produces creativos de campaña en lote. El concepto y el copy llegan aprobados: tú no los cambias.

Trabajas por lista. Por cada pieza: la medida exacta, el texto que lleva encima y el archivo de salida con nombre predecible. Nada de nombres tipo final-v2 ni copia-de.

Si una pieza no cabe en su medida sin cortar algo importante, no la fuerces: la marcas y sigues con las demás.

Al terminar entregas la tabla de qué generaste, en qué medida y en qué ruta quedó cada archivo, más la lista de las que marcaste como problema.

---
name: mantenedor-repo
description: Resuelve pendientes acotados de mantenimiento — un error con síntoma claro y reproducible, o documentación que quedó vieja. Úsalo cuando ya se sabe qué está mal y solo falta hacerlo.
tools: Read, Edit, Grep, Glob, Bash
model: sonnet
effort: medium
---

Atiendes pendientes de mantenimiento que ya vienen con síntoma claro.

Si es un error: primero reprodúcelo y escribe en una línea qué observaste, luego busca la causa, y hasta entonces edita. Un error, un cambio. No aproveches el viaje para reacomodar otras cosas.

Si es documentación: comparas lo que dice el archivo contra lo que hace el código de hoy y corriges solo lo que ya no es cierto. No agregas secciones nuevas ni cambias el tono.

No creas archivos nuevos y no tocas configuración ni dependencias. Si el arreglo requiere alguna de esas dos cosas, te detienes y lo reportas.

Entregas cuatro cosas: qué estaba mal, qué cambiaste, en qué archivos, y cómo se comprueba que ya quedó.

A un agente ya hecho lo llamas nombrándolo. No hay comando ni menú: lo escribes en tu mensaje y Claude lanza esa ventana de contexto aparte.

El agente trabaja solo, con su propio contexto, y de vuelta te llega nada más el resumen. Eso es lo que te deja dirigir cuatro frentes sin que tu sesión se sature: el detalle se queda del otro lado. También quiere decir que los subagentes no se hablan entre ellos — todo lo que uno necesita saber del otro pasa por la sesión principal. Si el pendiente 2 depende del 1, encadénalos tú.

La gente no se decepciona de los subagentes porque trabajen mal. Se decepciona porque nunca les dijo qué era «bien». Un agente sin criterio de aceptación siempre entrega algo defendible: existe, tiene forma, se ve razonable. Y tú te quedas viéndolo con la sensación de que no era eso, sin poder explicar en una frase por qué.

Ahí es donde se cae el reparto. Si el criterio no quedó escrito antes, la revisión se vuelve cuestión de gusto, y el gusto no se puede delegar. Te quedas sin la única herramienta que te hace director: la de regresar el trabajo. «No me convence» no es una devolución, es una queja. «El criterio pedía cinco secciones y hay cuatro» sí es una devolución, y el agente sabe exactamente qué hacer con ella.

El contrato son cuatro campos por tarea. Con menos, algo queda a interpretación. Con más, nadie lo escribe.

No los escribas tú a mano. Le pasas la lista al director y le pides los cuatro campos por tarea. La línea que de verdad trabaja es la última: pídele que te diga cuáles de sus propios criterios le parecen débiles. Ahí es donde caen los criterios de mentira, antes de llegar a un agente.

Antes de repartir, escribe el contrato de cada tarea.

Por cada tarea de SEMANA.md quiero cuatro campos, ni uno más:

1. ENTREGABLE — la ruta exacta del archivo que va a existir cuando esa tarea termine. Si son varios, los listas todos.
2. FORMATO — qué tiene adentro ese archivo. Una página, un documento markdown con tales secciones, imágenes de tal medida, lo que aplique.
3. ACEPTACIÓN — cómo se comprueba que está bien. Tiene que ser verificable, no opinable: "el build pasa", "el archivo tiene las cinco secciones", "el formulario manda el correo de prueba y llega". Nada de "que quede bien" ni "que se vea profesional".
4. PROHIBIDO — qué archivos, carpetas o configuraciones no puede tocar el agente de esa tarea.

Si un criterio de aceptación no lo puedes comprobar tú mismo leyendo un archivo o corriendo algo, no sirve: reescríbelo hasta que sí.

Devuélvemelo como una tabla, una fila por tarea. Debajo de la tabla, dime cuáles criterios te parecen débiles y cómo los apretarías.

No crees agentes ni repartas nada hasta que yo apruebe estos contratos.

Así se ve aplicado sobre la semana de ejemplo. Cuatro pendientes distintos entre sí — una página, un lote de piezas, un documento y un error en producción — y aun así los cuatro caben en la misma tabla. Fíjate en la tercera columna: ninguna de esas celdas se puede discutir en una llamada.

Hasta aquí repartiste a mano. Tú pediste el organigrama, tú aprobaste los contratos, tú mandaste cada tarea y tú recibiste cada entrega. Es la forma que más control te da y la que menos gasta, y aguanta perfectamente una semana normal.

El problema llega con el tamaño. Cuando el reparto pasa de unas cuantas tareas por turno, el cuello de botella eres tú: cada agente que termina se queda parado esperando a que le contestes. Ahí se abren dos caminos, y no son el mismo con distinto nombre. En uno, el plan se convierte en un programa que corre solo. En el otro, contratas colegas.

Ninguno de los dos viene encendido. Cada uno se prende con una línea, y esa línea es la mitad de la razón por la que casi nadie los usa.

Las dos líneas que las prenden

Una es un interruptor dentro de Claude Code; la otra es una variable de entorno. Si intentas usar cualquiera de las dos rutas sin esto, no falla con un error claro: simplemente no pasa nada y crees que la función no existe.

Regla corta para no darle vueltas: si el reparto lo vas a repetir, workflow. Si necesitas que se revisen entre ellos y que tú apruebes o rechaces cada plan antes de que alguien toque un archivo, equipo.

El caso largo: una app repartida por capas

Aquí es donde los equipos ganan de calle. Una app tiene capas con dueño natural: interfaz, servidor y datos, pruebas. Si le das una capa completa a cada compañero, dos agentes nunca editan el mismo archivo — el conflicto desaparece por diseño, no por suerte.

Y como se hablan, la capa de pruebas le dice a la de servidor qué se rompió sin pasar por tu bandeja. A ti te queda la única decisión que importa: aprobar el plan o regresarlo.

Vamos a construir esto:

[dos líneas: qué hace la app y para quién]

No lo hagas en una sola cabeza. Repártelo por capas, con un dueño por capa, para que dos agentes nunca editen el mismo archivo:

1. INTERFAZ — pantallas, componentes y los estados de vacío, carga y error. Dueño de la carpeta de componentes y de las páginas. No toca el servidor.
2. SERVIDOR Y DATOS — rutas, modelo de datos, validación y manejo de errores. Dueño de la carpeta del servidor. No toca componentes.
3. PRUEBAS — comprueba lo que entregan los otros dos: el caso feliz, los casos borde y qué pasa cuando algo falla a media operación. Dueño de la carpeta de pruebas. No arregla el código de nadie: reporta.
4. ABOGADO DEL DIABLO — no construye nada. Busca dónde se rompe esto con gente real usándolo: dos personas al mismo tiempo, el proveedor que no responde, el dato que se pierde a la mitad. Entrega una lista de riesgos ordenada por gravedad.

Antes de arrancar, enséñame dos cosas: qué modelo le pones a cada capa y por qué, y el mapa de qué carpeta es de quién.

Cuando terminen, tú revisas las cuatro entregas contra su contrato antes de pasármelas. Si la capa de pruebas encuentra algo, se lo regresas al dueño de esa capa. No lo arregles tú.

El puesto de director no termina cuando reparte. Termina cuando revisa.

Y aquí es donde se cae casi todo el mundo. Los agentes entregan, el director te manda un resumen bonito, tú lo lees y das todo por bueno. El detalle es que ese resumen lo escribió el mismo que hizo el trabajo. Cada subagente corre en su propia ventana de contexto y de vuelta solo regresa su reporte: ni tú ni el director vieron el archivo, vieron lo que el agente dice del archivo.

Revisar es abrir el entregable. Todo lo demás es confiar.

Hay tres maneras de cerrar el ciclo, y cambian en una sola cosa: qué tanto quieres que corra sin ti.

Ya te entregaron los subagentes. Ahora revisa. No me pases el trabajo todavía.

Para cada entregable:
1. Ábrelo y compáralo contra su contrato: entregable, formato, criterio de aceptación y zona prohibida.
2. Comprueba lo que se pueda comprobar corriéndolo o leyéndolo. No te fíes del resumen que te mandó el agente: los resúmenes siempre dicen que quedó bien.
3. Dame un veredicto de una palabra por entregable, PASA o NO PASA, y abajo el porqué, con el punto concreto que falla.

Al que no pase, regrésaselo al mismo agente. En el mensaje de vuelta ponle tres cosas: qué criterio no cumplió, qué encontraste exactamente y qué tiene que quedar distinto. Nada de "mejóralo" ni "dale otra vuelta".

Repite hasta que todos pasen. Si un agente falla dos veces por lo mismo, no lo mandes una tercera: dime tú qué está mal planteado en el contrato.

No me entregues nada hasta que todos los entregables tengan veredicto PASA. Cuando llegues ahí, mándame la tabla final con una línea por entregable y su ruta.

Quiero dejar esto corriendo hasta que de verdad esté terminado, usando /goal.

Antes de fijar nada, escríbela tú. Toma la lista de SEMANA.md y los criterios de aceptación de cada contrato, y conviértelos en UNA sola condición de terminado que se pueda comprobar sin opinar.

Reglas de la condición:
- Todo lo que menciones se tiene que poder verificar leyendo un archivo o corriendo un comando.
- Nombra los archivos por su ruta, no por su idea.
- Incluye también el estado negativo: qué NO debe quedar. Ningún pendiente marcado, ningún archivo vacío, ningún texto de relleno.
- Que quepa en dos o tres renglones. Si necesitas más, son dos metas y hay que partirlas.

Lo que no acepto como condición: "que la semana quede lista", "que todo funcione bien", "que esté presentable".

Devuélveme la condición propuesta y espera mi visto bueno. Cuando la apruebe, dime la línea exacta que tengo que escribir. No la fijes tú.

La revisión es lo que separa a un director de alguien que nada más lanzó agentes.

Sueltas la corrida y de golpe no tienes nada entre manos. Ahí es donde la mayoría se levanta por un café y vuelve veinte minutos después a un montón de trabajo mal hecho, ya pagado.

Mientras los agentes construyen, tú tienes puesto, y tiene dos mitades: mirar el tablero y cuidar la cuenta. Las dos se hacen desde la misma pantalla.

Mirar

El comando /workflows abre la vista de progreso de la corrida. No es una barra de carga: es el desglose por fase, y cada fase te dice cuántos agentes tiene trabajando, cuántos tokens lleva gastados y cuánto tiempo lleva corriendo. Entras a una fase y ves a los agentes uno por uno, con lo que le tocó a cada quien.

Los equipos de agentes no salen ahí: viven en el panel que aparece debajo del input, con cada compañero y su estado. Te mueves con las flechas, entras con Enter y le escribes directo a ese compañero, no al líder. Esa es la diferencia práctica entre las dos rutas: a un workflow lo pausas, a un compañero le hablas.

Pagar

Los topes, sin adornos: hasta 16 agentes en paralelo — menos si tu máquina tiene pocos núcleos, porque ese límite lo pone tu hardware y no tu plan — y hasta 1000 agentes en una sola corrida. El segundo número no lo vas a tocar nunca. El que sí vas a tocar es el de tu cuenta.

Cuando una corrida se proyecta arriba de 25 agentes o de 1.5 millones de tokens, Claude Code te avisa con un “Large workflow”. Léelo con calma: el aviso no detiene nada. Solo te apunta a /workflows para que vayas a ver. Si te llegó y no abriste el tablero, ese aviso no sirvió de nada.

Las tres palancas del gasto