• — obligatorio; ruta relativa o absoluta (se acepta@docs/... ).
• --lang — variante de idioma del revisor; el valor por defecto es «auto» (detectado a partir del proyecto).
• --scope — limita los pasos emitidos; por defecto, «all».
• --dry-run — muestra solo la descomposición y la justificación de la cadena; no emite las indicaciones finales.

Formato oficial de /orchestrate (no se debe desviar)

{ORCH_CMD} custom ",,...," ""

Donde {ORCH_CMD} se determina en la Fase 0 (véase más abajo). La cadena de comando en la salida emitida siempre utiliza una forma concreta: nunca ambas, nunca un marcador de posición.

• «custom» es una cadena secuencial; el HANDOFF de cada agente alimenta al siguiente.
• Lista de agentes separados por comas. Se prefiere que no haya espacios; se tolera un espacio.
• No existen los indicadores --mode / --gate / --agents=...; nunca los inventes.
• Los nombres de los agentes proceden del catálogo de esta habilidad. Las comillas dobles incrustadas en la descripción de la tarea se escapan como \".

Formato de instalación de ECC y espacios de nombres

Dos formatos de instalación determinan el prefijo tanto del comando de barra como de cada nombre de agente. Ambos DEBEN estar sincronizados: un formato por salida, nunca mezclados:

Que denote el directorio de inicio de Claude Code: ~/.claude en macOS/Linux, %USERPROFILE%\.claude en Windows. Resuélvelo tal y como la plataforma anfitriona resuelve el directorio de inicio del usuario (no codifiques ~ de forma fija).

Por qué es importante: en la instalación mediante plugin, los agentes se registran como everything-claude-code:tdd-guide. Los nombres sin prefijo obligan a realizar una coincidencia aproximada, lo que falla de forma intermitente en llamadas paralelas. En la instalación heredada, las formas con prefijo no se registran y fallan directamente.

Catálogo de agentes disponibles (hay que elegir entre estos)

General:

• planificador — reformulación de requisitos, descomposición de riesgos, planificación de pasos
• architect — arquitectura, diseño del sistema, propuestas de refactorización
• tdd-guide — escribir pruebas → implementar → cobertura superior al 80 %
• revisor de código — revisión genérica del código
• revisor de seguridad: auditoría de seguridad, OWASP, fugas de información confidencial
• limpiador de refactorización: código muerto, duplicados, limpieza de clases «knip»
• actualizador de documentación — documentación, mapa de código, README
• docs-lookup — consultas a la API de bibliotecas de terceros (Context7)
• e2e-runner — orquestación de pruebas de extremo a extremo
• database-reviewer — esquema de PostgreSQL, migración, rendimiento
• harness-optimizer — configuración del entorno de pruebas de agentes locales
• loop-operator — bucles autónomos de larga duración
• chief-of-staff — clasificación multicanal (rara vez encaja en los pasos del plan)

Resolventes de errores de compilación:

• build-error-resolver (genérico) / cpp-build-resolver / go-build-resolver / java-build-resolver / kotlin-build-resolver / rust-build-resolver / pytorch-build-resolver

Revisores de código:

• python-reviewer / typescript-reviewer / go-reviewer / rust-reviewer / cpp-reviewer / java-reviewer / kotlin-reviewer / flutter-reviewer

Un nombre de agente mal escrito provoca un error en /orchestrate. Comprueba esta lista antes de enviarlo.

Cómo funciona

Fase 0: detección del modo ECC y del lenguaje

1. Leer . Si falta o está vacío, informar y detener el proceso.

2. Detectar el formulario de instalación de ECC una vez y fijarlo en ECC_MODE. Algoritmo (ejecutar en orden, detenerse en la primera coincidencia):

   1. Si existe /plugins/marketplaces/everything-claude-code/ → ECC_MODE=plugin.
   2. En caso contrario, si existe /agents/ y contiene al menos un archivo de agente ECC (p. ej., tdd-guide.md, code-reviewer.md) → ECC_MODE=legacy.
   3. En caso contrario → se establece por defecto ECC_MODE=legacy y se muestra una advertencia de una línea al principio de la salida: > Advertencia: no se ha podido detectar la instalación de ECC; se utiliza por defecto el modo legacy. Si utilizas la instalación del plugin, edita los prefijos manualmente.
   4. Si existen ambos marcadores (instalación mixta), prevalece el complemento: el espacio de nombres del complemento es el único que resuelve los nombres de los agentes sin coincidencia aproximada.

   A partir de este momento, cada línea generada utiliza el prefijo correspondiente tanto en el comando de barra como en cada nombre de agente. Nunca se generarán ambas formas en la misma salida.

3. Resolver --lang. Cuando sea «auto», ejecutar una detección compatible con múltiples lenguajes:

   • Marcadores de detección: pyproject.toml / uv.lock / requirements.txt → python; package.json → typescript; go.mod → go; Cargo.toml → rust; CMakeLists.txt o archivos *.cpp de nivel superior → cpp; pom.xml / build.gradle (Java) → java; build.gradle.kts o Kotlin de nivel superior → kotlin; pubspec.yaml → flutter.
   • Desempate en caso de poliglotismo: si coincide más de un marcador, elige el lenguaje cuyos archivos fuente superen en número a los demás (cuéntalos mediante `git ls-files`, excluyendo `vendor/`, `node_modules/`, `dist/`, `build/`, `.venv/`, los archivos generados y los entornos de prueba evidentes). En caso de empate o cuando ningún lenguaje supere el 60 % de los archivos fuente, establece lang=unknown.
   • Si no coincide ningún marcador → establece lang=unknown.
   • lang=unknown es un indicador —no es un nombre de agente—. Las reglas 4 y 5 de la fase 2 lo convierten en revisor de código / resolutor de errores de compilación en el momento de la composición de la cadena.

4. Detectar un subperfil de PyTorch: cuando lang=python y cualquiera de los archivos pyproject.toml / requirements.txt / uv.lock declare una dependencia de torch, establece pytorch=true. Esto solo afecta a la selección de la cadena de compilación (regla de la Fase 2 más abajo); el revisor sigue siendo python-reviewer.

5. Normaliza cualquier nombre de agente declarado en el plan: si el texto del plan hace referencia a los agentes mediante su forma con prefijo de complemento (p. ej., everything-claude-code:tdd-guide), elimina el prefijo para obtener el nombre básico del catálogo antes de validar o componer cadenas. La reasignación del prefijo solo se produce en el momento de la salida según ECC_MODE (Fase 4). Nunca dejes que un nombre con prefijo previo entre en la composición de la cadena, ya que se produciría una doble asignación de prefijos en el modo plugin.

Fase 1 — Descomponer los pasos

Identifica las «unidades de paso» por orden de prioridad:

1. Numeración explícita: ## Paso N / ### Fase N / ## N. ... / lista ordenada de nivel superior.
2. Una columna «Paso» en una tabla.
3. ----bloques separados con encabezados que comienzan por un verbo.
4. En caso contrario, trata cada H2 como un paso.

Por paso, extrae el ID (a partir de 1), el título (≤ 80 caracteres), la intención (1-3 frases) y las etiquetas.

Fase 2 — Etiquetar y seleccionar la cadena

Etiqueta por intención (se permiten varias etiquetas; la cadena se construye a partir de la principal más las secundarias apiladas):

Las palabras clave que figuran a continuación se comparan sin distinguir entre mayúsculas y minúsculas. Se admiten planes multilingües al comparar las raíces de las palabras en cualquier idioma, siempre que el significado coincida con las palabras clave en inglés enumeradas.

Reglas de composición de cadenas:

1. Selección de la etiqueta principal: cuando un paso coincide con varias etiquetas, la primera en el orden de la tabla (la parte superior de la tabla = máxima prioridad) es la principal; el resto son secundarias. Las reglas de composición 2 y 3 que figuran a continuación tratan explícitamente combinaciones específicas de varias etiquetas; en los demás casos, se añaden cadenas secundarias en el orden de la tabla de etiquetas.
2. impl + security → tdd-guide,-reviewer,security-reviewer.
3. impl + db → tdd-guide,database-reviewer,-reviewer.
4. Elimina los duplicados de la cadena resultante (conserva la primera aparición). Por ejemplo, «review + lang=unknown» daría como resultado «code-reviewer,code-reviewer» tras aplicar la regla 5; la eliminación de duplicados lo reduce a «code-reviewer».
5. -reviewer se resuelve como code-reviewer cuando lang=unknown.
6. -build-resolver se resuelve como build-error-resolver cuando lang=unknown. Caso especial: si en la Fase 0 se establece pytorch=true, utilice pytorch-build-resolver para las cadenas de compilación independientemente de . No existe «python-build-resolver»; «--lang=python » sin «pytorch=true» se resuelve como «build-error-resolver».
7. Pasos sin etiqueta: si no coincide ninguna palabra desencadenante, establece la cadena en «code-reviewer» y escribe «no se ha encontrado ninguna etiqueta»; cadena predeterminada «solo revisión » según la «Justificación de la cadena».
8. Longitud de la cadena ≤ 4 tras la deduplicación. Si se supera, se descarta la etiqueta más débil (primero«lookup» y «docs» ).
9. No emparejes «planner» y «architect» en una cadena «impl» (desperdicio de tokens). Emparejalos solo en pasos de diseño.
10. Los pasos etiquetados como «impl», «refactor» o «migration» terminan con un agente de clase «reviewer »: cualquiera de los siguientes: «-reviewer», «code-reviewer», «security-reviewer» o «database-reviewer». El revisor más específico del dominio ocupa la última posición (por ejemplo, «impl+security» de la regla 2 termina con «security-reviewer»; «impl+db» de la regla 3 termina con «-reviewer», ya que «database-reviewer» ya controla la migración en una fase anterior de la cadena). Los pasos de prueba y compilación están controlados por sus propios validadores (e2e-runner y el resolutor de compilación, respectivamente) y no requieren un revisor adicional.

Fase 3 — Comprimir la descripción de la tarea

Cada debe:

• Ser autónoma (el primer agente no necesita tener abierto el documento del plan).
• Comenzar con [Plan: #step-].
• Incluir entre 1 y 3 criterios de aceptación verificables.
• Incluir una cláusula de alcance (Fuera de alcance: ...) solo si el plan declara una para este paso. Heredarla tal cual. Si el plan no contiene ninguna declaración de fuera de alcance, omitir la cláusula por completo; no inventar ninguna.
• Tenga entre 200 y 600 caracteres; una sola línea; el carácter «» debe escaparse como «\»; no incluya saltos de línea literales.

Fase 4 — Salida

Genera Markdown utilizando el formato determinado por ECC_MODE. La salida utiliza un único formato en todo momento: cada {ORCH_CMD} y cada nombre de agente se representa con el prefijo correspondiente de la Fase 0. No emitas ambos formatos; no incluyas instrucciones del tipo «esta es la forma del complemento» o «elimina el prefijo» en la salida generada.

Reglas concretas de representación:

• {ORCH_CMD} = /everything-claude-code:orchestrate en el plugin, /orchestrate en el modo heredado.
• {AGENT(nombre)} = everything-claude-code: en el plugin, en el modo heredado.
• La columna «Chain» de la tabla de resumen utiliza la misma representación {AGENT(name)}.
• Los bloques bash por paso contienen únicamente el comando ejecutable. No hay comentarios del tipo # plugin form ni # legacy form: el formato es implícito y uniforme en toda la salida.

Estructura de la salida:

# Resultado de Plan-Orchestrate 
**Plan**: ``
**Lenguaje**: ``
**Modo ECC**: ``
**Pasos**: 
**Ámbito**: 

## Resumen de los pasos

| # | Título | Etiquetas | Cadena |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |

---

## Paso 1 —