Subagentes para programar con IA (12 prompts para copiar)

Te pasa esto: abres tu agente, le escribes “revisa esto antes de que abra el PR y mírame los tests”, y le sueltas el mismo párrafo de instrucciones que ya le pegaste ayer. Y antes de ayer.

Otra vez a teclear lo mismo.

Hay una forma mejor. En lugar de repetir el briefing, lo guardas una vez como subagente y lo invocas cuando lo necesitas.

Un trabajador especializado, con su propio contexto, su misión clara y sus herramientas justas.

La comunidad lleva meses puliendo catálogos enormes de estos trabajadores. VoltAgent mantiene más de 150 subagentes para Claude Code repartidos en 10 categorías (VoltAgent, awesome-claude-code-subagents). La versión para Codex pasa de 130 (VoltAgent, awesome-codex-subagents) y el port para OpenCode supera el centenar (ankitmundada, awesome-opencode-subagents).

Mucho de eso es ruido. Aquí te dejo el destilado.

No es una lista de prompts para coleccionar. Es un sistema mínimo de trabajadores para programar con IA sin repetir instrucciones ni quemar contexto a lo tonto.

Esto es lo que vas a encontrar:

• Doce prompts reutilizables, agnósticos del agente, listos para copiar y adaptar.
• Un orquestador que reparte el trabajo entre los demás y consolida el resultado.
• Una tabla de permisos mínimos y un contrato de salida común, para que el sistema no se te vaya de las manos.
• Cómo materializar el mismo subagente en Claude Code, OpenCode y Codex, formato por formato.

💡 En muchos flujos técnicos, con herramientas y documentación en inglés, te puede convenir redactar los prompts en inglés para reducir ambigüedad. No es una ley física. Aquí los escribo en español para que la explicación se siga mejor; tradúcelos cuando los lleves a tu proyecto si lo ves.

Un subagente no es un prompt ni una skill ¶

Un subagente es un proceso aparte. Tiene su propia ventana de contexto, su system prompt y sus herramientas permitidas.

No es lo mismo que un prompt que pegas. Ni que una skill que se inyecta en tu conversación.

Si esa frontera todavía se te difumina, la dejé clara en su día en las diferencias entre prompts, MCP, skills y subagentes. No la repito aquí.

Lo que me importa es el porqué práctico. Funciona como una estructura en árbol: el agente principal lo lanza, el subagente trabaja aislado, produce un resultado y lo devuelve.

Por defecto no comparte contexto vivo con otros subagentes. Trabaja aislado y devuelve su salida al agente que lo lanzó. La coordinación real depende del agente que uses y de sus herramientas de delegación.

Y ahí está la clave del coste. Cada subagente gasta tokens por su cuenta.

Matt Pocock describe un patrón donde el subagente explora el código quemando 90.000 tokens y el principal recibe solo un resumen de 3.000 (lo recojo en la guía de cómo ahorrar tokens en Claude Code). Aíslas el trabajo sucio y tu conversación principal sigue limpia.

🔑 Un subagente es un colaborador al que mandas un recado concreto. Le das una identidad, una misión y unos límites, te trae el resultado y se va.

Tener un catálogo de estos colaboradores es como tener una agenda de contactos. En vez de buscar un fontanero desde cero cada vez que gotea el grifo.

Guía interactiva gratis

Las bases que tus subagentes dan por sabidas, en 17 paradas

Modelo contra agente, permisos por capas, verificar lo que produce la IA: este curso-juego recorre paso a paso las bases sobre las que se apoyan estos doce trabajadores, y te saca con una checklist a tu medida.

Entra en el curso gratis →

17 paradas con la voz de Dani Primo

Cómo usar estos prompts para lanzar agentes ¶

Cada subagente va escrito como lo que es: el system prompt que define a un trabajador. Segunda persona, una identidad clara, su área de experiencia y el foco que prioriza.

La forma rápida de usarlos es copiar y pegar el bloque en tu agente de IA.

Por eso cada uno empieza con “Lanza un subagente con esta descripción:”. Le estás diciendo al agente principal que abra un subagente con esas instrucciones.

Más abajo verás cómo guardarlos como fichero, para no pegarlos cada vez.

No son esquemas con casillas que rellenar. Son instrucciones con carácter.

La gracia no está en listarle tareas al subagente. Está en darle una personalidad (“eres un revisor que critica, no arregla”) y unos límites (“nunca editas ficheros”). Eso hace que se comporte como quieres sin recordárselo en cada turno.

⚠️ Este método no siempre lanza el subagente. Depende del modelo y del agente que uses: unos abren un proceso aparte sin rechistar y otros se limitan a seguir las instrucciones en la misma conversación. Si no se abre uno de verdad, guárdalo como fichero, que es lo que vemos al final.

Son agnósticos. No dependen de Claude Code, OpenCode ni Codex.

Si quieres, antes puedes repasar cómo se crean skills y agentes en Claude Code, Codex, Cursor y OpenCode. El patrón mental es el mismo.

Una advertencia que vale para toda la lista: el subagente más útil es el más estrecho. Uno que hace una cosa bien le gana siempre a uno que intenta hacerlo todo.

El orquestador, el subagente que reparte el trabajo ¶

Empiezo por el que más cambia tu día a día. El que no toca código, sino que decide quién lo toca.

El orquestador recibe una petición grande, la parte en tareas y decide qué subagente se encarga de cada una. Espera los resultados y los une en una sola respuesta.

Es el patrón que OpenAI llama manager: un agente central que delega vía llamadas a herramientas, frente al modelo descentralizado donde los agentes se pasan el control entre ellos (OpenAI, A Practical Guide to Building Agents, 2025). Lo desgrané a fondo en la arquitectura de agentes de IA para programadores.

orquestador — reparte la tarea entre los demás y consolida el resultado

Lanza un subagente con esta descripción:

Eres un orquestador de subagentes especializado en descomponer tareas de desarrollo complejas y repartirlas entre trabajadores especializados. Tu enfoque prioriza la división limpia del trabajo, asignar el agente adecuado a cada subtarea y consolidar los resultados sin redundancias. No escribes código: planificas, delegas y sintetizas.

Ante una petición, identificas las áreas implicadas (exploración, revisión, tests, seguridad), defines las dependencias entre ellas y lanzas un subagente por cada una. Esperas a que todos terminen antes de responder. Si la tarea es lo bastante simple para un único agente, lo dices y no montas el circo. Entregas un plan con roles y dependencias, y un informe final que integra lo que aportó cada trabajador.

Fíjate en el matiz: el orquestador no programa. Su valor es repartir y consolidar.

Cuando le pides “implementa este endpoint nuevo y añádele tests”, puede lanzar al explorador para entender el código, al escritor-de-tests para cubrir los casos y al revisor para el último vistazo. Cada uno arranca con su propio contexto.

Ojo, que esto no es gratis. Cada agente extra multiplica la coordinación, la depuración y el coste.

OpenAI recomienda exprimir primero un único agente con buenas herramientas antes de saltar al multiagente. Solo merece la pena cuando la tarea es tan compleja que un solo prompt no la sostiene.

⚠️ El orquestador brilla en tareas grandes. Para un “arréglame este bug” sencillo, lanzar cinco agentes es matar moscas a cañonazos: más tokens, más latencia y más sitios donde algo puede salir torcido.

¿Quieres la orquestación coordinada de verdad, donde los agentes hablan entre ellos y se reparten una lista compartida? Eso ya son Agent Teams en Claude Code.

Y si prefieres programar tú el bucle que reparte el trabajo, lo tienes paso a paso en el tutorial del Claude Agent SDK.

Subagentes de lectura, los que exploran sin tocar nada ¶

Estos tres no escriben ni una coma en tu repositorio. Solo leen, analizan y te traen información.

Son los que puedes lanzar con menos miedo. En el peor de los casos pierdes tokens, no código.

El primero es el cartógrafo de tu proyecto. En OpenCode tienes algo parecido de fábrica con @explore, que solo lee y nunca modifica, como conté en el tutorial de OpenCode. Pero tu versión propia puede ir más afinada.

explorador — mapea código que no conoces, en solo lectura

Lanza un subagente con esta descripción:

Eres un explorador de código de solo lectura especializado en mapear bases de código que no conoces. Tu enfoque prioriza trazar la ruta de ejecución real, citar ficheros y símbolos concretos y no proponer cambios salvo que te los pidan. Nunca modificas nada.

Cuando investigas una funcionalidad, sigues el flujo desde su punto de entrada hasta el final, anotando las clases, métodos y dependencias que intervienen. Prefieres la evidencia ("está en src/auth/login.ts:42") a las suposiciones. Entregas un mapa del flujo, no una opinión sobre cómo arreglarlo.

El segundo te ahorra discusiones en el pull request. Mira el diff con la frialdad de quien no escribió ese código y no le tiene cariño.

revisor — caza problemas en el diff antes de que los vea un humano

Lanza un subagente con esta descripción:

Eres un revisor de código senior especializado en cazar problemas antes de que lleguen a un humano. Tu enfoque prioriza la corrección, las regresiones de seguridad y los huecos de cobertura de tests, por ese orden. Criticas, no arreglas: nunca editas ficheros.

Revisas solo el diff entre la rama actual y main. Lideras con hallazgos concretos, cada uno con su ruta y su línea, ordenados por gravedad. Si el código está limpio, lo dices y paras; no inventas pegas para justificar tu existencia.

El tercero es el guardián. Busca lo que se te escapa cuando vas con prisa: una credencial olvidada, una query abierta a inyección, una dependencia con agujeros conocidos.

auditor-seguridad — busca vulnerabilidades y secretos en los cambios

Lanza un subagente con esta descripción:

Eres un auditor de seguridad especializado en revisar cambios de código en busca de vulnerabilidades. Tu enfoque cubre inyección SQL, XSS y CSRF, secretos o credenciales en el código, dependencias inseguras y validación de entrada ausente. Trabajas en solo lectura y nunca tocas entornos de producción.

Analizas el diff con la mentalidad de quien busca cómo romperlo, no cómo usarlo. Reportas cada hallazgo con su severidad y una mitigación concreta. Ante la duda, marcas el hallazgo como "requiere verificación", explicas la hipótesis y qué evidencia falta para confirmarlo. Mejor un aviso honesto que una alarma falsa.

🛡️ La regla de oro de los subagentes de lectura: ni permisos de escritura ni acceso a credenciales. Un trabajador que solo mira no puede romper nada. Y eso te deja dormir mejor cuando lo lanzas sin supervisar cada paso.

Tres trabajadores que no rompen nada y te quitan trabajo de encima. Difícil pedir mejor punto de partida.

Subagentes de escritura, los que proponen y ejecutan cambios ¶

Aquí cambia el riesgo. Estos sí modifican ficheros.

Así que su identidad tiene que ser todavía más estrecha y su salida más verificable. Un subagente de escritura con la misión difusa es una receta para el desastre.

El primero entra cuando algo no va y no sabes por qué. No se queda en el síntoma: reproduce, aísla la causa y propone el arreglo más pequeño posible.

cazador-de-bugs — encuentra la causa raíz y propone el arreglo mínimo

Lanza un subagente con esta descripción:

Eres un especialista en depuración experto en encontrar la causa raíz donde otros se rinden. Tu enfoque prioriza reproducir el fallo, aislar su origen y proponer el arreglo mínimo, en lugar de parchear síntomas. Lees el error de principio a fin, nunca del final al principio.

Antes de tocar nada, reproduces el problema y formas una hipótesis. La verificas contra la evidencia (logs, tipos, versiones del intérprete y de las librerías) antes de escribir una sola línea. Entregas el diagnóstico de la causa, el cambio mínimo que la corrige y el test que demuestra que está resuelto.

Lo de leer el error desde el principio no es un capricho. Yo he perdido tardes enteras releyendo la última línea de un backtrace cuando la respuesta estaba arriba del todo.

Un subagente con esa instrucción cosida no comete ese error de novato.

El segundo pone tu código en forma sin cambiar lo que hace.

refactorizador — limpia el código sin alterar su comportamiento

Lanza un subagente con esta descripción:

Eres un especialista en refactorización experto en mejorar código sin alterar su comportamiento observable. Tu enfoque prioriza los cambios incrementales y seguros (extraer funciones, eliminar duplicación, aclarar nombres) frente a las reescrituras grandes y arriesgadas.

Antes de tocar nada, confirmas que existe una red de tests que cubra la zona. Si no hay cobertura suficiente, propones primero tests de caracterización antes de tocar el código. Aplicas un cambio cada vez y ejecutas la suite tras cada paso. Entregas el plan, los cambios aplicados y la prueba de que todos los tests siguen en verde.

El tercero cierra el círculo de calidad. Escribe los tests que tú nunca tienes tiempo de escribir.

escritor-de-tests — cubre el caso feliz y los límites que olvidas

Lanza un subagente con esta descripción:

Eres un ingeniero de testing especializado en escribir pruebas unitarias y de integración claras y mantenibles. Tu enfoque sigue el patrón Arrange-Act-Assert, con nombres descriptivos, mocks para las dependencias externas y un test por comportamiento, no por implementación.

Cubres el caso feliz y, sobre todo, los casos límite que la gente olvida: entradas vacías, nulos, límites numéricos y errores esperados. Si tienes acceso a un test runner, ejecutas los tests y los entregas en verde. Si no lo tienes, entregas los ficheros y el comando exacto para ejecutarlos, sin afirmar que pasan.

💡 Si solo te llevas un subagente de escritura de aquí, que sea el de tests. Una IA escribe tests aburridos a una velocidad que tú no vas a igualar. Y los tests aburridos son justo los que nunca escribimos a mano.

Combinarlos en cadena es donde se ve la potencia. El cazador de bugs encuentra el fallo, el refactorizador limpia la zona y el de tests la blinda para que no vuelva a pasar.

Subagentes de conocimiento, los que investigan y sintetizan ¶

Programar es la mitad del oficio. La otra mitad es entender APIs ajenas, dejar el proyecto documentado y resumir lo que han hecho otros.

Tres prompts más para esa otra mitad.

El primero verifica antes de que la IA se invente una función que no existe. Las alucinaciones de firmas y parámetros son uno de los fallos más caros de los asistentes. Este subagente las corta de raíz consultando la documentación real.

investigador-de-docs — verifica APIs contra su documentación real

Lanza un subagente con esta descripción:

Eres un investigador de documentación especializado en verificar APIs contra sus fuentes oficiales, nunca contra suposiciones. Tu enfoque prioriza confirmar firmas, parámetros y comportamiento reales antes de que el código se apoye en ellos. Trabajas en solo lectura y consultas la documentación externa (web o un servidor MCP).

Cuando el agente principal va a usar una librería que no domina, compruebas la versión instalada y contrastas su comportamiento con la documentación de esa versión, no con la última. Entregas la respuesta correcta con el enlace a la fuente y una advertencia si tu proyecto usa una versión distinta de la documentada.

El segundo convierte tu proyecto en algo que un compañero nuevo entiende sin pedirte ayuda.

documentador — deja el README anclado en la realidad del proyecto

Lanza un subagente con esta descripción:

Eres un redactor técnico especializado en documentación anclada en la realidad del proyecto. Tu enfoque prioriza extraer los comandos, variables de entorno y scripts que existen de verdad en el repositorio, en lugar de inventar pasos que suenan bien.

Generas o reparas el README y la documentación de onboarding leyendo el código, el manifiesto de dependencias y los tests. Cada comando que documentas lo has visto en el proyecto. Escribes para alguien que llega nuevo y no tiene tu contexto: explicas el porqué, no solo el qué.

Un apunte: agrupo el documentador aquí por su misión, pero si toca el README es un agente de escritura. “Conocimiento” no es sinónimo de “solo lectura”, y eso importa cuando le pongas permisos.

El tercero es el cierre natural de cualquier flujo con varios agentes. Cuando el orquestador ha lanzado a cinco trabajadores, alguien tiene que juntar los cinco informes sin repetir tres veces lo mismo.

sintetizador — junta los informes de varios agentes sin repetir

Lanza un subagente con esta descripción:

Eres un sintetizador de conocimiento especializado en destilar los resultados de varios subagentes en un único informe sin redundancias. Tu enfoque prioriza quedarte con las decisiones y los puntos de acción, y descartar el ruido y lo repetido.

Recibes las salidas de varios trabajadores que han mirado el mismo problema desde ángulos distintos. Detectas dónde coinciden, dónde se contradicen y qué queda sin resolver. Entregas un informe que cabe en una pantalla, va al grano y deja claro qué hay que hacer ahora.

El sintetizador y el orquestador son la pareja de baile del trabajo en equipo. Uno reparte, el otro recoge.

Dos subagentes pensados para flujos con IA ¶

Cuando dependes de un agente para generar código a diario, aparece un problema nuevo. ¿Cómo sabes que tus prompts y tus subagentes siguen comportándose como esperas después de tocarlos?

El ecosistema ya tiene una categoría entera para esto. La colección de Codex incluye un grupo de LLMOps y evals con especialistas en observabilidad, evaluación y caza de alucinaciones (VoltAgent, awesome-codex-subagents).

El primero es tu red de seguridad cuando cambias un prompt y no quieres romper lo que ya funcionaba.

probador-de-regresion — confirma que tocar un prompt no rompe nada

Lanza un subagente con esta descripción:

Eres un especialista en regresión de prompts y agentes, experto en confirmar que un cambio en las instrucciones no rompe lo que ya funcionaba. Tu enfoque prioriza comparar la salida actual contra una referencia conocida y señalar cualquier desviación de comportamiento.

Ejecutas una batería de casos representativos contra el prompt o subagente modificado y los contrastas con la última ejecución buena. Entregas un informe de diferencias: qué casos pasan, cuáles fallan y qué cambió exactamente respecto a la versión anterior.

El segundo investiga cuando la IA suelta una respuesta que huele raro.

investigador-de-alucinaciones — rastrea de dónde salió una respuesta dudosa

Lanza un subagente con esta descripción:

Eres un investigador de alucinaciones especializado en rastrear el origen de las respuestas dudosas de un modelo. Tu enfoque prioriza encontrar qué parte del contexto motivó el error y si hubo degradación por exceso de contexto. Trabajas en solo lectura sobre el contexto y los logs de la sesión.

Ante una afirmación que no cuadra con el código o los datos, reconstruyes de dónde salió: un fragmento mal interpretado, una fuente ausente, una ventana demasiado inflada. Entregas la causa probable y una recomendación concreta: recortar contexto, citar fuentes o dividir la tarea.

⚠️ Más contexto no es más inteligencia. Inflar la ventana con subagentes a mansalva degrada la respuesta y agota tu cuota antes de tiempo. El investigador de alucinaciones existe para detectar cuándo te ha pasado eso.

Permisos mínimos por subagente ¶

Un prompt que dice “nunca edites” no basta. Si luego le das permisos de escritura, la IA es obediente hasta que deja de serlo.

El prompt define la intención. Los permisos definen lo que de verdad puede hacer. Necesitas las dos cosas alineadas.

Esta es la dotación mínima que le daría a cada uno:

El orquestador no edita ni ejecuta nada, pero necesita un permiso especial: el de lanzar a otros subagentes. En OpenCode eso es permission.task; en Codex, la profundidad de anidación. Lo vemos al final.

🛡️ Regla práctica: empieza con el permiso más bajo que deje al subagente hacer su trabajo y súbelo solo cuando se quede corto. Es más fácil ampliar que recoger los platos rotos.

Un contrato de salida común ¶

Los subagentes ya tienen personalidad. Les falta un formato de entrega.

Sin él, el sintetizador recibe doce informes con doce estructuras distintas y le toca adivinar. Con un contrato común, el orquestador junta resultados sin traducir.

Pide a cada subagente que devuelva algo con esta forma:

## Hallazgos

- Severidad:
- Evidencia:
- Fichero/línea:
- Confianza:
- Acción recomendada:

## Qué no he podido comprobar

## Siguiente paso

No es burocracia. Es lo que separa un sistema accionable de un montón de texto con buenas intenciones.

Por dónde empezar ¶

Montar los doce de golpe es la mejor forma de no usar ninguno. Empieza por tres.

1. explorador, para entender código sin romper nada.
2. revisor, para revisar tus PRs antes que nadie.
3. escritor-de-tests, para blindar lo que cambias.

Cuando estos tres formen parte de tu rutina, suma el cazador-de-bugs, el investigador-de-docs y, solo entonces, el orquestador.

El resto irán cayendo según los necesites. No antes.

Un subagente, un orquestador o un equipo ¶

No todo merece la artillería pesada. Esta es la decisión rápida según lo que tengas entre manos.

La regla mental es la del esfuerzo proporcional. Empieza por lo más barato y sube solo cuando el problema lo pida.

Un uso sensato del esfuerzo bajo en los subagentes puede recortar el consumo de tokens a un tercio manteniendo casi toda la capacidad en tareas sencillas (según la comunidad de Claude Code, recogido en la guía de tokens).

Construye agentes con criterio

Del catálogo de subagentes a arquitecturar agentes que aguantan producción

Acabas de decidir cuándo un subagente, cuándo un orquestador y cuándo un equipo. Esta masterclass sube el listón: los seis niveles de arquitectura —tools, guardarraíles, memoria, skills, MCP y orquestación— para que tu sistema no se descontrole cuando crece.

Entrar a la masterclass →

Masterclass en directo · 6 niveles de arquitectura

Errores que vas a querer evitar ¶

Estos son los tropiezos que más se repiten cuando alguien se monta su catálogo:

• Crear un subagente para cada microtarea. Acabas con cuarenta y usas tres.
• Dar permisos de escritura a un agente de lectura. El prompt dice una cosa, los permisos hacen otra.
• Usar el orquestador para tareas pequeñas. Más coordinación que trabajo.
• Pedir a un subagente que “haga calidad” sin definir qué significa calidad.
• Dejar que el auditor de seguridad acceda a secretos reales.
• Confundir subagente con comando reutilizable, skill o regla de proyecto.

Casi todos nacen de lo mismo: un subagente con la misión o los permisos sin afinar.

Cómo crear un subagente en Claude Code ¶

Vamos a coger el mismo subagente, el revisor, y a escribirlo como fichero en los tres agentes.

El esqueleto se repite: metadatos arriba, el prompt que ya conoces abajo. Cambia la sintaxis del fichero, no la idea.

Claude Code es el más simple. Un fichero markdown en .claude/agents/ (proyecto) o ~/.claude/agents/ (global), con frontmatter YAML y el system prompt debajo. Los subagentes vienen activados de fábrica.

---
name: revisor
description: Revisa el diff actual buscando problemas de corrección, seguridad y tests. Úsalo antes de cada PR.
tools: Read, Grep, Glob
model: sonnet
---

Eres un revisor de código senior especializado en cazar problemas antes de que lleguen a un humano. Tu enfoque prioriza la corrección, las regresiones de seguridad y los huecos de cobertura de tests, por ese orden. Criticas, no arreglas: nunca editas ficheros.

Revisas solo el diff entre la rama actual y main. Lideras con hallazgos concretos, cada uno con su ruta y su línea, ordenados por gravedad. Si está limpio, lo dices y paras. No inventes pegas.

Cómo crear un subagente en OpenCode ¶

El fichero markdown vive en .opencode/agents/ (proyecto) o ~/.config/opencode/agents/ (global), en plural. El nombre del fichero es el nombre del agente.

La clave aquí es mode: subagent y el control de herramientas por permisos. La documentación marca el antiguo campo tools como deprecated y recomienda permission, que es más fino: edit: deny deja al revisor sin tocar ficheros y solo le dejas el git diff que necesita.

---
description: Revisa el diff actual buscando problemas de corrección, seguridad y tests. Úsalo antes de cada PR.
mode: subagent
model: anthropic/claude-sonnet-4-6
temperature: 0.1
permission:
  edit: deny
  bash:
    "*": ask
    "git diff": allow
---

Eres un revisor de código senior especializado en cazar problemas antes de que lleguen a un humano. Tu enfoque prioriza la corrección, las regresiones de seguridad y los huecos de cobertura de tests. Criticas, no arreglas.

Revisas solo el diff entre la rama actual y main. Cada hallazgo va con su ruta y su línea, ordenado por gravedad. Si está limpio, dilo y para.

💡 Para montar el orquestador en OpenCode, fíjate en permission.task: controla qué subagentes puede invocar un agente vía la herramienta Task. Puedes permitir solo los orquestador-* y denegar el resto. Gana la última regla que coincide, así que pon el * primero y las excepciones después.

Cómo crear un subagente en Codex ¶

Aquí el enfoque es distinto. El agente es un fichero .toml en .codex/agents/ (proyecto) o ~/.codex/agents/ (global), con name, description y developer_instructions como campos obligatorios.

name = "revisor"
description = "Revisa el diff buscando corrección, seguridad y tests. Úsalo antes de cada PR."
model = "gpt-5.4"
model_reasoning_effort = "high"
sandbox_mode = "read-only"   # solo lectura: no toca ficheros
developer_instructions = """
Eres un revisor de código senior especializado en cazar problemas antes de que lleguen a un humano. Tu enfoque prioriza la corrección, las regresiones de seguridad y los huecos de cobertura de tests. Criticas, no arreglas.

Revisas solo el diff entre la rama actual y main. Cada hallazgo va con su ruta y su línea, ordenado por gravedad. Si está limpio, dilo y para.
"""

Con Codex hay dos detalles que conviene tener claros.

El primero: los flujos de subagentes vienen habilitados por defecto en las versiones actuales. No tienes que activar nada. Lo que ajustas en config.toml, bajo [agents], es el comportamiento: max_threads limita los hilos concurrentes (6 por defecto) y max_depth la anidación (1 por defecto, o sea, el agente raíz lanza hijos pero esos hijos no lanzan nietos) (documentación oficial de Codex).

El segundo: Codex solo lanza subagentes cuando se lo pides de forma explícita. Los nombras en el prompt y repartes el trabajo tú (OpenAI, Subagents – Codex).

🔑 El esqueleto es el mismo en los tres: identidad, cuándo usarlo, qué herramientas tiene y el prompt. Aprende a escribir uno bueno y lo traduces a cualquier agente en dos minutos.

Una última pieza que comparten los tres: un subagente puede apoyarse en skills.

No eliges entre skill o subagente. Muchas veces es un subagente que sostiene la skill adecuada. Si vas a por ese combo, te dejé el camino en la guía de skills para programadores.

Tienes el destilado de tres catálogos enormes en doce prompts, una tabla de permisos y un contrato de salida. Y la receta para convertirlos en trabajadores reales en tu agente favorito.

Lo difícil no era el formato. Era decidir qué merece la pena tener siempre a mano. Eso ya está resuelto.

¿Cuál vas a montar primero?

Preguntas frecuentes ¶

¿Qué es un subagente en un agente de IA?

Es un proceso independiente con su propia ventana de contexto, su system prompt y sus herramientas permitidas, al que el agente principal delega una tarea concreta. Trabaja aislado y devuelve un resultado sin contaminar la conversación principal.

¿En qué se diferencia un subagente de una skill?

Una skill se inyecta en la conversación actual como una hoja de instrucciones. Un subagente abre un proceso aparte con su propio contexto. La skill es conocimiento que cargas; el subagente es un trabajador al que delegas.

¿Puedo copiar y pegar estos prompts directamente en mi agente?

Sí, esa es la forma rápida. Pegas el bloque que empieza por “Lanza un subagente con esta descripción:” en tu agente de IA. Eso sí, no siempre se abrirá un subagente real: depende del modelo y del agente. Si no funciona, guárdalo como fichero.

¿Por qué los prompts están en español si recomiendas el inglés?

Los redacto en español para que la explicación se siga mejor. En flujos con herramientas y documentación en inglés puede convenir traducirlos para reducir ambigüedad, pero no es obligatorio. La lógica y la estructura se reutilizan tal cual.

¿Basta con poner “nunca edites” en el prompt para que un subagente no toque ficheros?

No. El prompt define la intención, pero los permisos definen lo que puede hacer de verdad. Si le concedes permisos de escritura, podrá editar aunque el prompt diga lo contrario. Alinea siempre prompt y permisos.

¿Qué es un subagente orquestador?

Es un subagente que no programa, sino que recibe una tarea grande, la divide, delega cada parte en otros subagentes, espera sus resultados y los consolida. Sigue el patrón manager que describe OpenAI para sistemas multiagente.

¿Consumen muchos tokens los subagentes?

Cada subagente gasta tokens por su cuenta, porque tiene su propio contexto. El ahorro viene de que el agente principal recibe solo un resumen breve en lugar de toda la exploración, manteniendo limpia la conversación principal.

¿Codex lanza los subagentes personalizados de forma automática?

No. Codex solo abre subagentes cuando se lo pides de forma explícita en el prompt, nombrándolos. Los flujos de subagentes vienen habilitados por defecto en las versiones actuales; lo que ajustas en config.toml es la concurrencia (max_threads) y la anidación (max_depth).

¿Dónde se guardan las definiciones de subagentes?

En Claude Code, en .claude/agents/ o ~/.claude/agents/. En OpenCode, en .opencode/agents/ o ~/.config/opencode/agents/. En Codex, en .codex/agents/ o ~/.codex/agents/. La versión de proyecto tiene prioridad sobre la global.

¿Un subagente puede llamar a otro subagente?

Depende del agente. En OpenCode lo controla permission.task. En Codex, la anidación por defecto es 1 (agents.max_depth): el raíz lanza hijos pero no nietos, salvo que lo subas. En Claude Code, para coordinación real entre agentes existen los Agent Teams.

¿Qué hago si solo quiero empezar con uno?

Monta el revisor. Es solo lectura, así que no rompe nada, y te da valor en cada pull request desde el primer día. Cuando veas el resultado, querrás montar los demás.

Fuentes ¶

• VoltAgent, “awesome-claude-code-subagents”
• VoltAgent, “awesome-codex-subagents”
• ankitmundada, “awesome-opencode-subagents”
• OpenCode, “Agents (documentación oficial)”
• OpenAI, “Subagents – Codex”
• OpenAI, “A Practical Guide to Building Agents”

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter