# Kit de orquesta — los siete prompts y los cuatro perfiles Este archivo es la parte copiable de la guía **Orquesta con Claude**: los siete prompts que van en orden, y los cuatro perfiles de subagente del ejemplo largo. Nada de esto es código. Todo se pega tal cual en Claude Code, en español, y funciona igual si tú no programas. Cómo se usa: abres Claude Code en la carpeta del proyecto, entras en modo plan y vas de arriba hacia abajo. Primero escribes el documento (prompt 1), luego lo lees con Claude sin dejarlo tocar nada (prompt 2), luego repartes (prompt 3) y le exiges contrato a cada tarea (prompt 4). Los prompts 5 y 6 cierran el ciclo: revisas lo que te entregaron y le regresas el trabajo al que no cumplió. El prompt 7 es el caso largo, cuando lo que repartes es una app entera. Los corchetes `[así]` son huecos que tú llenas antes de mandar el mensaje. --- ## Cuándo usar cada prompt | # | Prompt | Cuándo lo usas | Qué te deja | |---|---|---|---| | 1 | El prompt que te entrevista | Antes de repartir nada, cuando la semana solo existe en tu cabeza | El archivo `SEMANA.md` | | 2 | Solo léelo y dime qué entendiste | Primer turno de la sesión de dirección | Lo que entendió, lo que le falta y lo que está mal planteado | | 3 | Reparte la lista y asígnale modelo a cada quien | Cuando el documento ya está aprobado | La tabla del reparto: agentes, modelos y dueños de archivo | | 4 | El contrato de entregable | Antes de que nadie empiece a construir | Cuatro campos por tarea: entregable, formato, aceptación y prohibido | | 5 | Al que no cumpla, regrésaselo | Cuando los subagentes ya entregaron | Un veredicto PASA / NO PASA por entregable, y la devolución | | 6 | Convierte el plan en una condición verificable | Cuando quieres irte y que siga solo con `/goal` | La condición de terminado que sí se puede comprobar | | 7 | Una app repartida por capas | Cuando lo que repartes es un proyecto entero | Un dueño por capa, más el que solo busca dónde se rompe | --- ## 1 · El prompt que te entrevista Para armar el documento que después se reparte. Pégalo en una sesión nueva y deja que te pregunte; sale un archivo `SEMANA.md`. ``` 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. ``` --- ## 2 · Solo léelo y dime qué entendiste El primer turno de la sesión de dirección. Antes de que reparta nada, quieres saber si entendió lo mismo que tú y qué le falta. ``` 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. ``` --- ## 3 · Reparte la lista y asígnale modelo a cada quien Aquí dejas de construir y empiezas a dirigir. Le pides el organigrama antes de que exista una sola línea de trabajo. ``` 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. ``` --- ## 4 · El contrato de entregable Sin esto no puedes rechazar nada: cuando el trabajo regresa, no hay contra qué compararlo. Cuatro campos por tarea, ni uno más. ``` 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. ``` --- ## 5 · Al que no cumpla, regrésaselo El bucle completo, a mano. El director revisa contra el contrato y devuelve el trabajo que no pasa. A ti no te llega nada hasta que todo pasó. ``` 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. ``` --- ## 6 · Convierte el plan en una condición verificable Antes de fijar una meta con `/goal`, que Claude te la escriba. La mitad del valor está en descubrir que tu definición de terminado no se podía comprobar. ``` 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ú. ``` --- ## 7 · Una app repartida por capas El caso largo. Un dueño por capa para que dos agentes nunca editen el mismo archivo, y un cuarto que solo busca dónde se rompe. ``` 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ú. ``` --- # Los cuatro perfiles de subagente Cada perfil es un archivo markdown dentro de `.claude/agents/`. No los escribes tú a mano si no quieres: le pasas el contenido a Claude Code y le pides que cree el archivo en esa ruta. Dos van en `opus` (criterio y texto que lee un cliente) y dos en `sonnet` (ejecución acotada). ## `.claude/agents/redactor-landing.md` — modelo `opus` Para el pendiente de la landing: lo lee un cliente y hay decisiones de estructura que nadie tomó todavía. ```markdown --- 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. ``` ## `.claude/agents/guionista-whatsapp.md` — modelo `opus` Para el guion del agente de WhatsApp: cada respuesta la va a leer un cliente, y hay que decidir qué no contesta el bot. ```markdown --- 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. ``` ## `.claude/agents/productor-creativos.md` — modelo `sonnet` Para los creativos de campaña: el concepto ya está aprobado, es la misma pieza repetida en dos medidas. ```markdown --- 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. ``` ## `.claude/agents/mantenedor-repo.md` — modelo `sonnet` Para el error con síntoma claro y el documento viejo: ya se sabe qué está mal, solo falta hacerlo. ```markdown --- 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ó. ``` --- ## Los comandos que salen en la guía | Comando | Para qué | |---|---| | `/model opus` · `/model fable` | Elegir quién dirige la sesión, según tu plan | | `/effort xhigh` | Subirle el esfuerzo mientras planeas y repartes | | `/workflows` | Ver los workflows dinámicos y qué están haciendo | | `/goal` | Fijar la condición de terminado; `/goal clear` la apaga | | `/config` | Prender la fila de workflows dinámicos | | `/agents` | El panel donde ves y editas tus subagentes | La guía completa, con las nueve paradas y el porqué de cada decisión: https://tododeia.com/community/orquesta-con-claude