Orquestrar Plan

¿Qué hace Orquestrar Plan?

Conecta un documento de plan con /orchestrate custom emitiendo una invocación lista para pegar por cada paso. El skill es solo generativo — nunca ejecuta /orchestrate. El usuario pega cada línea cuando esté listo.

Cuándo activarlo

• El usuario tiene un documento de plan de varios pasos (PRD, RFC, plan de implementación) y quiere ejecutarlo mediante /orchestrate.
• El usuario dice "orquestra este plan", "dame instrucciones de orchestrate para cada paso", "compón cadenas para este plan".
• Existe un plan paso a paso pero el usuario no quiere seleccionar agentes manualmente por paso.

Omitir cuando:

• El trabajo es un paso ad hoc → llama a /orchestrate custom directamente.
• El plan es ilegible o está vacío. La falta de numeración explícita por sí sola no es una condición de omisión — consulte el caso extremo "Sin pasos claros" más abajo.

Entradas

<ruta-documento-plan> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:<n>|range:<a>-<b>] [--dry-run]

• <ruta-documento-plan> — obligatorio; ruta relativa o absoluta (se acepta @docs/...).
• --lang — variante de idioma del revisor; por defecto auto (detectado del proyecto).
• --scope — limita los pasos emitidos; por defecto all.
• --dry-run — imprime solo la descomposición y la justificación de la cadena; no emite las instrucciones finales.

Forma autorizada de /orchestrate (no desviarse)

{ORCH_CMD} custom "<agente1>,<agente2>,...,<agenteN>" "<descripción de la tarea>"

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

• custom es una cadena secuencial; el traspaso (HANDOFF) de cada agente alimenta al siguiente.
• Lista de agentes separada por comas. Sin espacios preferiblemente; se tolera un espacio.
• No existen banderas --mode / --gate / --agents=... — nunca inventarlas.
• Los nombres de los agentes provienen del catálogo de este skill. Las comillas dobles en la descripción de la tarea se escapan como \".

Forma de instalación de ECC y uso de prefijos

Dos formas de instalación determinan el prefijo tanto en el comando de barra como en cada nombre de agente. Las dos DEBEN mantenerse sincronizadas — una forma por salida, nunca mezcladas:

Sea <directorio-claude> el directorio home de Claude Code: ~/.claude en macOS/Linux, %USERPROFILE%\.claude en Windows. Resuélvelo como lo hace la plataforma anfitriona (no codifiques ~).

Forma	Detección	{ORCH_CMD}	Formato del nombre del agente
Instalación como plugin (2.0.0+)	<directorio-claude>/plugins/marketplaces/ecc/ existe	/ecc:orchestrate	ecc:<nombre>
Instalación heredada	Lo anterior ausente; archivos de agente bajo <directorio-claude>/agents/	/orchestrate	<nombre>

Por qué es importante: bajo la instalación como plugin, los agentes se registran como ecc:tdd-guide. Los nombres sin prefijo fuerzan coincidencias difusas, que fallan intermitentemente bajo llamadas paralelas. Bajo la instalación heredada, las formas con prefijo no están registradas y fallan directamente.

Catálogo de agentes disponibles (debe elegirse de estos)

Generales:

• planner — reformulación de requisitos, descomposición de riesgos, planificación de pasos
• architect — arquitectura, diseño de sistemas, propuestas de refactorización
• tdd-guide — escribir pruebas → implementar → cobertura del 80%+
• code-reviewer — revisión de código genérica
• security-reviewer — auditoría de seguridad, OWASP, fuga de secretos
• refactor-cleaner — código muerto, duplicados, limpieza tipo knip
• doc-updater — documentación, mapa de código, README
• docs-lookup — búsquedas de API de bibliotecas de terceros (Context7)
• e2e-runner — orquestación de pruebas de extremo a extremo
• database-reviewer — esquema PostgreSQL, migración, rendimiento
• harness-optimizer — configuración de entornos de agentes locales
• loop-operator — bucles autónomos de larga duración
• chief-of-staff — triaje multicanal (rara vez adecuado para pasos de plan)

Resolvedores 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 hace que /orchestrate falle. Verifique esta lista antes de emitir.

Cómo funciona

Fase 0 — Detectar modo ECC + idioma

1. Leer <ruta-documento-plan>. Si falta o está vacío, informar y detenerse.

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

   1. Si existe <directorio-claude>/plugins/marketplaces/ecc/ → ECC_MODE=plugin.
   2. Si no, y si existe <directorio-claude>/agents/ que contenga al menos un archivo de agente ECC (p. ej., tdd-guide.md, code-reviewer.md) → ECC_MODE=legacy.
   3. Si no → por defecto ECC_MODE=legacy y emitir una advertencia de una línea al principio de la salida: > Advertencia: no se pudo detectar la instalación de ECC; se usará la forma heredada. Si usas la instalación como plugin, edita los prefijos manualmente.
   4. Si existen ambos marcadores (instalación mixta), plugin gana — el espacio de nombres del plugin es el único que resuelve los nombres de los agentes sin coincidencias difusas.

   A partir de este punto, cada línea emitida usa el prefijo coincidente tanto en el comando de barra como en cada nombre de agente. Nunca emitir ambas formas en la misma salida.

3. Resolver --lang. Cuando sea auto, ejecutar una detección multilingüe:

   • Sondear marcadores: pyproject.toml / uv.lock / requirements.txt → python; package.json → typescript; go.mod → go; Cargo.toml → rust; CMakeLists.txt o *.cpp de nivel superior → cpp; pom.xml / build.gradle (Java) → java; build.gradle.kts o Kotlin de nivel superior → kotlin; pubspec.yaml → flutter.
   • Desempate multilingüe: si más de un marcador coincide, elegir el idioma cuyos archivos fuente superen en número a los demás (contar mediante git ls-files, excluyendo vendor/, node_modules/, dist/, build/, .venv/, archivos generados y fixtures de prueba evidentes). En caso de empate o cuando ningún idioma supere el 60% de los archivos fuente, establecer lang=unknown.
   • Sin marcador coincidente → establecer lang=unknown.
   • lang=unknown es un centinela — no es un nombre de agente. Las reglas 4 y 5 de la Fase 2 lo convierten en code-reviewer / build-error-resolver al componer la cadena.

4. Detectar un subperfil PyTorch: cuando lang=python y cualquiera de pyproject.toml / requirements.txt / uv.lock declara una dependencia de torch, establecer pytorch=true. Esto solo afecta la selección de la cadena build (regla de la Fase 2 a continuación); el revisor sigue siendo python-reviewer.

5. Normalizar cualquier nombre de agente declarado en el plan: si el texto del plan hace referencia a agentes por su forma con prefijo de plugin (p. ej., ecc:tdd-guide), eliminar el prefijo para obtener el nombre del catálogo simple antes de validar o componer cadenas. El re-prefijado ocurre solo en el momento de la salida según ECC_MODE (Fase 4). Nunca permitir que un nombre pre-prefijado fluya hacia la composición de la cadena — se duplicaría el prefijo en modo plugin.

Fase 1 — Descomponer pasos

Identificar "unidades de paso" en 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 por --- con encabezados que comienzan con verbo.
4. De lo contrario, tratar cada H2 como un paso.

Por paso, extraer id (basado en 1), title (máx. 80 caracteres), intent (1–3 oraciones), tags.

Fase 2 — Etiquetar y seleccionar cadena

Etiquetar por intención (se permiten múltiples etiquetas; la cadena se construye a partir de la primaria más las secundarias apiladas):

Las palabras desencadenantes a continuación coinciden sin distinción de mayúsculas/minúsculas. Los planes multilingües son compatibles al coincidir las raíces de las palabras en cualquier idioma siempre que el significado se alinee con las palabras desencadenantes en inglés listadas.

Etiqueta	Palabras desencadenantes	Cadena por defecto
design	architecture, design, choose, evaluate, RFC	planner,architect
plan	plan, breakdown, milestone	planner
impl	implement, build, add, create, port	tdd-guide,<lang>-reviewer
test	test, coverage, e2e, integration	tdd-guide,e2e-runner
refactor	refactor, cleanup, dedupe, split	architect,refactor-cleaner,<lang>-reviewer
migration	migrate, upgrade, rewrite, port	architect,tdd-guide,<lang>-reviewer
db	schema, migration, index, SQL, Postgres, alembic, sqlmodel	database-reviewer,<lang>-reviewer
security	encrypt, auth, secret, OWASP, PII	security-reviewer,<lang>-reviewer
build	build, compile, lint failure, CI	<lang>-build-resolver (cae en build-error-resolver)
docs	docs, readme, codemap, changelog	doc-updater
lookup	lookup, reference, API usage	docs-lookup
review	review, audit, verify	<lang>-reviewer,code-reviewer
loop	loop, autonomous, watchdog	loop-operator

Reglas de composición de cadenas:

1. Selección de etiqueta primaria: cuando un paso coincide con varias etiquetas, la primera en el orden de la tabla (arriba de la tabla = mayor prioridad) es la primaria; el resto son secundarias. Las reglas de composición 2 y 3 a continuación manejan combinaciones específicas de múltiples etiquetas explícitamente; de lo contrario, agregar cadenas secundarias en el orden de la tabla de etiquetas.
2. impl + security → tdd-guide,<lang>-reviewer,security-reviewer.
3. impl + db → tdd-guide,database-reviewer,<lang>-reviewer.
4. Desduplicar la cadena resultante (conservar la primera aparición). P. ej., review + lang=unknown produciría code-reviewer,code-reviewer después de la regla 5; la desduplicación lo reduce a code-reviewer.
5. <lang>-reviewer se resuelve a code-reviewer cuando lang=unknown.
6. <lang>-build-resolver se resuelve a build-error-resolver cuando lang=unknown. Caso especial: si la Fase 0 estableció pytorch=true, usar pytorch-build-resolver para las cadenas build independientemente de <lang>. No hay python-build-resolver; --lang=python sin pytorch=true se resuelve a build-error-resolver.
7. Pasos sin etiqueta: si no coincide ninguna palabra desencadenante, establecer la cadena en code-reviewer y escribir no se encontró etiqueta coincidente; cadena de solo revisión por defecto bajo "Justificación de la cadena".
8. Longitud de la cadena ≤ 4 después de la desduplicación. Si se excede, eliminar la etiqueta más débil (lookup y docs primero).
9. No emparejar planner y architect en una cadena impl (desperdicio de tokens). Emparejarlos solo en pasos design.
10. Los pasos etiquetados como impl, refactor o migration terminan con un agente de clase revisor — cualquiera de <lang>-reviewer, code-reviewer, security-reviewer o database-reviewer. El revisor más específico del dominio gana la posición final (p. ej., la regla 2 impl+security termina con security-reviewer; la regla 3 impl+db termina con <lang>-reviewer porque database-reviewer ya controla la migración antes en la cadena). Los pasos test y build están controlados por sus propios validadores (e2e-runner y el resolvedor de compilación respectivamente) y no requieren un revisor adicional.

Fase 3 — Comprimir descripción de la tarea

Cada <descripción de la tarea> emitida debe:

• Ser autocontenida (el primer agente no necesita tener el documento del plan abierto).
• Comenzar con [Plan: <ruta>#step-<id>].
• Incluir de 1 a 3 criterios de aceptación verificables.
• Incluir un guardia de alcance (Fuera de alcance: ...) solo si el plan declara uno para este paso. Heredar textualmente. Si el plan no tiene una declaración de fuera de alcance, omitir la cláusula por completo — no inventar una.
• Ser de 200 a 600 caracteres; una línea; comillas " escapadas como \"; sin saltos de línea literales.

Fase 4 — Salida

Emitir Markdown usando la forma determinada por ECC_MODE. La salida usa una sola forma en todo momento — cada {ORCH_CMD} y cada nombre de agente se representa con el prefijo coincidente de la Fase 0. No emitir ambas formas; no incluir instrucciones como "esta es la forma de plugin" / "elimina el prefijo" en la salida renderizada.

Reglas concretas de renderizado:

• {ORCH_CMD} = /ecc:orchestrate bajo plugin, /orchestrate bajo legacy.
• {AGENTE(nombre)} = ecc:<nombre> bajo plugin, <nombre> bajo legacy.
• La columna "Cadena" de la tabla de vista general usa el mismo renderizado {AGENTE(nombre)}.
• Los bloques bash por paso contienen solo el comando ejecutable. Sin comentarios # forma de plugin o # forma heredada — la forma es implícita y uniforme en toda la salida.

Estructura de salida:

# Resultado de Plan-Orquestrar

**Plan**: `<ruta>`
**Idioma**: `<detectado-o-dado>`
**Modo ECC**: `<plugin | legacy>`
**Pasos**: <N>
**Alcance**: <all | step:n | range:a-b>

## Vista general de pasos

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

---

## Paso 1 — <título>

**Intención**: <1–3 oraciones>
**Etiquetas**: <a, b>
**Justificación de la cadena**: <por qué esta cadena; qué agente cierra el bucle>

```bash
{ORCH_CMD} custom "{AGENTE(tdd-guide)},{AGENTE(database-reviewer)},{AGENTE(python-reviewer)}" "[Plan: docs/foo.md#step-1] <descripción de la tarea comprimida>; Aceptación: <1–3 elementos>; Fuera de alcance: <…>"
```

La notación {ORCH_CMD} y {AGENTE(...)} anterior describe la sustitución que realiza este skill en tiempo de ejecución. El Markdown emitido contiene las cadenas resueltas, nunca los marcadores de posición.

Agregar un bloque final de "Ejecución por lotes" que agregue el comando de cada paso en orden para que el usuario pueda pegarlos todos a la vez. Omitir el bloque de lote en modo solo vista general (consulte el caso extremo "Plan grande"): cuando solo se emite la tabla de vista general, no hay comandos por paso que agregar.

Fase 5 — Autocomprobación (ejecutar antes de emitir)

• Cada agente en cada cadena proviene del catálogo (después de eliminar cualquier prefijo ecc: que apareciera en el plan; consulte la Fase 0 paso 5).
• {ORCH_CMD} resuelto y cada {AGENTE(...)} resuelto usan la misma forma (plugin o legacy) — nunca mezclados en una salida.
• No quedan anotaciones # forma de plugin / # forma heredada ni instrucciones "elimina el prefijo" en la salida renderizada.
• No hay campos --mode / --gate / --agents=... inventados.
• Cada descripción de tarea es de una sola línea, entre comillas dobles, con comillas " escapadas.
• Cada descripción de tarea comienza con [Plan: <ruta>#step-<id>] e incluye Aceptación (1–3 elementos). La cláusula Fuera de alcance: está presente solo cuando se hereda del plan.
• No hay agente duplicado en ninguna cadena después de la desduplicación de la Fase 2.
• Longitud de la cadena ≤ 4.
• Los pasos etiquetados como impl/refactor/migration terminan con un agente de clase revisor