• — obrigatório; caminho relativo ou absoluto (aceita-se@docs/... ).
• --lang — variante de idioma do revisor; o padrão é auto (detectado a partir do projeto).
• --scope — limita as etapas exibidas; o padrão é all.
• --dry-run — exibe apenas a decomposição e a justificativa da cadeia; não exibe solicitações finais.

Formato oficial do /orchestrate (não se desvie)

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

Onde {ORCH_CMD} é determinado na Fase 0 (veja abaixo). A sequência de comando na saída emitida sempre usa uma forma concreta — nunca ambas, nunca um espaço reservado.

• custom é uma cadeia sequencial; o HANDOFF de cada agente alimenta o seguinte.
• Lista de agentes separada por vírgulas. É preferível não usar espaços; um espaço é tolerado.
• Não existem sinalizadores --mode / --gate / --agents=... — nunca os invente.
• Os nomes dos agentes provêm do catálogo desta skill. As aspas duplas embutidas na descrição da tarefa são escapadas como \".

Formato de instalação do ECC e espaços de nomes

Dois formatos de instalação determinam o prefixo tanto no comando de barra quanto em cada nome de agente. Os dois DEVEM permanecer sincronizados — um formato por saída, nunca misturados:

Seja denote o diretório raiz do Claude Code: ~/.claude no macOS/Linux, %USERPROFILE%\.claude no Windows. Resolva-o da mesma forma que a plataforma hospedeira resolve o diretório raiz do usuário (não codifique ~).

Por que isso é importante: na instalação via plug-in, os agentes são registrados como everything-claude-code:tdd-guide. Nomes simples forçam a correspondência aproximada, o que falha intermitentemente em chamadas paralelas. Na instalação legada, as formas com prefixo não são registradas e falham imediatamente.

Catálogo de agentes disponíveis (é preciso escolher entre estes)

Geral:

• planner — reformulação de requisitos, decomposição de riscos, planejamento de etapas
• architect — arquitetura, projeto de sistema, propostas de refatoração
• tdd-guide — escrever testes → implementar → cobertura de 80% ou mais
• revisor de código — revisão genérica de código
• revisor de segurança — auditoria de segurança, OWASP, vazamento de informações confidenciais
• limpador de refatoração — código morto, duplicatas, limpeza de classes knip
• atualizador de documentação — documentação, mapa de código, README
• docs-lookup — consultas à API de bibliotecas de terceiros (Context7)
• e2e-runner — orquestração de testes de ponta a ponta
• database-reviewer — esquema do PostgreSQL, migração, desempenho
• harness-optimizer — configuração do harness do agente local
• loop-operator — loops autônomos de longa duração
• chief-of-staff — triagem multicanal (raramente adequado para etapas do plano)

Resolvedores de erros de compilação:

• 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

Um nome de agente com erro ortográfico faz com que o /orchestrate falhe. Verifique esta lista antes de emitir.

Como funciona

Fase 0 — Detectar o modo ECC + linguagem

1. Leia . Se estiver ausente ou vazio, gere um relatório e interrompa.

2. Detecte o formulário de instalação do ECC uma vez e fixe-o em ECC_MODE. Algoritmo (execute na ordem, pare na primeira correspondência):

   1. Se /plugins/marketplaces/everything-claude-code/ existir → ECC_MODE=plugin.
   2. Caso contrário, se /agents/ existir e contiver pelo menos um arquivo de agente ECC (por exemplo, tdd-guide.md, code-reviewer.md) → ECC_MODE=legacy.
   3. Caso contrário → o padrão é ECC_MODE=legacy e é exibido um aviso de uma linha no início da saída: > Aviso: não foi possível detectar a instalação do ECC; usando o formato legado como padrão. Se você usar a instalação do plugin, edite os prefixos manualmente.
   4. Se ambos os marcadores existirem (instalação mista), o plug-in prevalece — o namespace do plug-in é o único que resolve nomes de agentes sem correspondência aproximada.

   A partir deste ponto, cada linha emitida usa o prefixo correspondente tanto no comando de barra quanto em cada nome de agente. Nunca emita ambas as formas na mesma saída.

3. Resolva --lang. Quando estiver em “auto”, execute uma detecção compatível com várias linguagens:

   • Marcadores de sondagem: pyproject.toml / uv.lock / requirements.txt → python; package.json → typescript; go.mod → go; Cargo.toml → rust; CMakeLists.txt ou *.cpp de nível superior → cpp; pom.xml / build.gradle (Java) → java; build.gradle.kts ou Kotlin de nível superior → kotlin; pubspec.yaml → flutter.
   • Desempate em casos de poliglotismo: se mais de um marcador corresponder, escolha a linguagem cujos arquivos-fonte sejam mais numerosos do que os das outras (conte usando git ls-files, excluindo vendor/, node_modules/, dist/, build/, .venv/, arquivos gerados e fixtures de teste óbvios). Em caso de empate ou quando nenhuma linguagem exceder 60% dos arquivos-fonte, defina lang=unknown.
   • Nenhum marcador correspondeu → defina lang=unknown.
   • lang=unknown é um sentinela — não é um nome de agente. As regras 4 e 5 da Fase 2 o transformam em revisor de código / solucionador de erros de compilação no momento da composição da cadeia.

4. Detecte um subperfil PyTorch: quando lang=python e qualquer um dos arquivos pyproject.toml / requirements.txt / uv.lock declarar uma dependência do torch, defina pytorch=true. Isso afeta apenas a seleção da cadeia de compilação (regra da Fase 2 abaixo); o revisor continua sendo python-reviewer.

5. Normalize quaisquer nomes de agentes declarados no plano: se o texto do plano referenciar agentes por meio de sua forma com prefixo de plug-in (por exemplo, everything-claude-code:tdd-guide), remova o prefixo para obter o nome puro do catálogo antes de validar ou compor cadeias. A reaplicação do prefixo ocorre apenas no momento da saída, de acordo com o ECC_MODE (Fase 4). Nunca permita que um nome com prefixo pré-aplicado entre na composição da cadeia — isso resultaria em um prefixo duplo no modo plugin.

Fase 1 — Decompor etapas

Identifique “unidades de etapa” em ordem de prioridade:

1. Numeração explícita: ## Etapa N / ### Fase N / ## N. ... / lista ordenada de nível superior.
2. Uma coluna “Etapa” em uma tabela.
3. ----blocos separados por títulos que começam com um verbo.
4. Caso contrário, trate cada H2 como uma etapa.

Por etapa, extraia o ID (com base em 1), o título (≤ 80 caracteres), a intenção (1–3 frases) e as tags.

Fase 2 — Etiquetagem e seleção de cadeia

Marque por intenção (é permitido usar várias tags; a cadeia é construída a partir da tag principal + tags secundárias empilhadas):

As palavras-chave abaixo são comparadas sem distinção de maiúsculas e minúsculas. Planos multilíngues são suportados pela correspondência dos radicais das palavras em qualquer idioma, desde que o significado esteja alinhado com as palavras-chave em inglês listadas.

Regras de composição de cadeias:

1. Seleção da tag primária: quando uma etapa corresponde a várias tags, a primeira na ordem da tabela (topo da tabela = prioridade mais alta) é a primária; as demais são secundárias. As regras de composição 2 e 3 abaixo tratam explicitamente combinações específicas de várias tags; caso contrário, acrescente cadeias secundárias na ordem da tabela de tags.
2. impl + security → tdd-guide,-reviewer,security-reviewer.
3. impl + db → tdd-guide,database-reviewer,-reviewer.
4. Desduplique a cadeia resultante (preserve a primeira ocorrência). Por exemplo, review + lang=unknown resultaria em code-reviewer,code-reviewer após a regra 5; a desduplicação reduz isso a code-reviewer.
5. -reviewer resolve como code-reviewer quando lang=unknown.
6. -build-resolver é resolvido como build-error-resolver quando lang=unknown. Caso especial: se a Fase 0 definir pytorch=true, use pytorch-build-resolver para cadeias de compilação, independentemente de . Não existe python-build-resolver; --lang=python sem pytorch=true resulta em build-error-resolver.
7. Etapas sem tag: se nenhuma palavra-gatilho corresponder, defina a cadeia como code-reviewer e registre “nenhuma tag correspondente”; cadeia padrão apenas para revisão conforme “Fundamentação da cadeia”.
8. Comprimento da cadeia ≤ 4 após a deduplicação. Se excedido, descarte a tag mais fraca (procura e documentação primeiro).
9. Não emparelhe o planejador e o arquiteto em uma cadeia de implementação (desperdício de tokens). Emparelhe-os apenas em etapas de projeto.
10. Etapas marcadas com impl, refactor ou migration terminam com um agente da classe reviewer — qualquer um d-reviewer, code-reviewer, security-reviewer ou database-reviewer. O revisor mais específico do domínio ocupa a posição final (por exemplo, a etapa “impl+security” da regra 2 termina com “security-reviewer”; a etapa “impl+db” da regra 3 termina com “-reviewer”, pois o “database-reviewer” já controla a migração anteriormente na cadeia). As etapas de teste e compilação são controladas por seus próprios validadores (e2e-runner e o resolveador de compilação, respectivamente) e não exigem um revisor adicional.

Fase 3 — Compactar a descrição da tarefa

Cada deve:

• Ser autônoma (o primeiro agente não precisa ter o documento do plano aberto).
• Começar com [Plano: #step-].
• Incluir de 1 a 3 critérios de aceitação verificáveis.
• Incluir uma restrição de escopo (Fora do escopo: ...) somente se o plano declarar uma para esta etapa. Herdar literalmente. Se o plano não tiver nenhuma declaração de fora do escopo, omitir a cláusula por completo — não inventar uma.
• Tenha de 200 a 600 caracteres; uma linha; caracteres “” escapados como \; sem quebras de linha literais.

Fase 4 — Saída

Gere Markdown usando o formato determinado por ECC_MODE. A saída utiliza um único formato em todo o texto — cada {ORCH_CMD} e cada nome de agente é renderizado com o prefixo correspondente da Fase 0. Não emita os dois formatos; não inclua instruções do tipo “este é o formato do plugin” / “remova o prefixo” na saída renderizada.

Regras concretas de renderização:

• {ORCH_CMD} = /everything-claude-code:orchestrate no plugin, /orchestrate no legado.
• {AGENT(nome)} = everything-claude-code: no plugin, em “legacy”.
• A coluna “Chain” da tabela de visão geral usa a mesma renderização {AGENT(name)}.
• Os blocos bash por etapa contêm apenas o comando executável. Não há comentários do tipo # plugin form ou # legacy form — o formato é implícito e uniforme em toda a saída.

Estrutura da saída:

# Resultado de Plan-Orchestrate 
**Plano**: ``
**Linguagem**: ``
**Modo ECC**: ``
**Etapas**: 
**Escopo**: 

## Visão geral das etapas

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

---

## Etapa 1 —