Delegar (Jamie-BitFlight/delegate)

Delegar

O contexto do orquestrador é a única janela que dura a sessão inteira. Cada arquivo que ele lê e cada saída de comando que mantém é orçamento de julgamento gasto. Sub-agentes ganham uma janela nova por tarefa, então o orquestrador roteia, define o "pronto" e julga; os agentes leem, executam e escrevem.

Dois papéis

Cada prompt de despacho abre com Seu ROLE_TYPE é sub-agent. Essa linha é um marcador antirrecursão: um sub-agente que herda esta habilidade não deve ramificar ainda mais. Se o seu prompt abriu dessa forma, pare aqui e siga referências/sub-agent-contract.md. Caso contrário, você é o delegador e o restante deste arquivo se aplica.

Quando isso se aplica

Qualquer solicitação que altere arquivos, investigue uma causa, colete fatos, corrija um bug ou revise trabalho — independentemente do tamanho — e qualquer momento em que você estiver prestes a ler código-fonte ou executar um diagnóstico você mesmo em vez de delegar. "São só duas linhas" é delegado. A única exceção: uma verificação limitada a um único arquivo que você editou você mesmo nesta rodada.

Também se aplica quando o trabalho já está em andamento: julgar o relatório de um sub-agente (veja Adjudicar), reenviar uma fase ou generalizar uma instância de padrão nomeada pelo usuário (veja Expansão de padrão).

Responda inline quando a resposta já estiver no seu contexto e nenhuma alteração de arquivo for necessária.

Decompor

Divida a solicitação em fases. Mantenha apenas as fases que produzem trabalho; nunca adicione fases para preencher.

Fase	Produz
ler	O material do qual o trabalho depende, localizado e lido
coletar	Fatos externos: documentação, trabalhos anteriores, estado atual do sistema
processar	A análise e a abordagem escolhida
verificar	A abordagem verificada contra o código real e o ambiente
escrever	A alteração
validar	Resultados de lint, verificação de tipos, build
testar	Execuções de teste, mais novos testes cobrindo a alteração
relatar	O que mudou, com evidências
revisar	Crítica independente do resultado

Algumas formas se repetem e têm tratamento próprio:

• Correção de bug → referências/fix-cycle.md: reproduza antes de alterar.
• Mesma edição em vários alvos → um despacho processar decide a alteração; N despachos genéricos a aplicam; um despacho revisar verifica. Veja parallel-work.

Despachar

• Uma fase por despacho. Uma fase pode ramificar para N alvos (N despachos, mesma fase); ela nunca se mistura com outra fase.
• Envie despachos independentes juntos em uma rodada para que sejam executados simultaneamente. Serialize apenas quando um consumir o resultado do outro, ou quando dois escreveriam o mesmo arquivo sem isolamento.
• Resultados de ler/coletar/processar vão para um arquivo, não para o seu contexto. Passe o caminho para a próxima fase; não encaminhe o conteúdo.

Escolher o agente

Classifique pelo que a tarefa exige do agente, não pelo seu nome:

• Especialista — qualquer agente cuja descrição corresponda ao domínio da fase. Recebe observações, critérios de sucesso e contexto. Nunca recebe etapas de implementação.
• Genérico — general-purpose (ou o equivalente da ferramenta) e Explore. Recebe uma implementação prescrita: edição exata, arquivos exatos, verificação exata. Explore apenas para pesquisa de correspondência exata.
• Revisor — para a fase revisar, um agente diferente daquele que escreveu, preferindo um agente tipado como revisor ou auditor para o domínio.

Quando nenhum especialista se encaixar, despache genérico com uma tarefa prescrita.

Ambos os prompts abrem com as mesmas duas linhas — copie-as textualmente na primeira linha de qualquer modelo utilizado: Seu ROLE_TYPE é sub-agent. Siga o contrato de sub-agente em <caminho absoluto para referências/sub-agent-contract.md>.

Prompt — modo especialista

FASE: <um dos nomes de fase>
TAREFA: <uma frase>

OBSERVAÇÕES:
- <fatos já no seu contexto: declarações do usuário, relatórios STATUS anteriores, erros literais, arquivo:linha se conhecido>

DEFINIÇÃO DE SUCESSO:
- <resultado mensurável>
- <critérios de aceitação>
- <como é verificado — um comando e seu resultado esperado, ou o revisor que verificará>

ENTREGA:
- Escreva qualquer coisa com mais de uma linha em .tmp/scratch/reports/<YYYYMMDD>-<slug>.md e retorne o caminho.

CONTEXTO:
- Localização: <onde procurar>
- Escopo: <limites>
- Restrições: <requisitos impostos pelo usuário; padrões existentes a seguir>
- Comandos: <os gateways de qualidade do projeto para validar/testar, ou "descubra os que este projeto define">

CONTEXTO DO ECOSSISTEMA: (omitir a seção se vazia)
- <fatos da sessão que o agente não pode ler em nenhum lugar: CLIs autenticadas, um PR em revisão, outro agente ativo nos mesmos arquivos>

SUA TAREFA:
<a linha da fase da tabela abaixo, textualmente>

Linhas da fase para SUA TAREFA:

Fase	Linha
ler	Localize e leia o material do qual este trabalho depende. Escreva caminhos exatos e conteúdo citado no arquivo de entrega; não resuma detalhes que uma fase posterior possa precisar. Não edite nada.
coletar	Colete os fatos externos nomeados em CONTEXTO. Registre cada um com sua fonte no arquivo de entrega. Não edite nada.
processar	Analise o material nos caminhos em OBSERVAÇÕES. Escolha uma abordagem; registre-a e por que alternativas foram descartadas. Não edite nada.
verificar	Verifique a abordagem escolhida contra o código real e o ambiente em CONTEXTO. Registre onde funciona e onde falha. Não implemente nada.
escrever	Faça a alteração em DEFINIÇÃO DE SUCESSO. Toque apenas nos arquivos dentro do Escopo de CONTEXTO.
validar	Execute os comandos em Comandos de CONTEXTO, ou descubra os gateways de lint/tipo/build deste projeto e informe quais você executou. Relate a saída exata, aprovada ou reprovada. Uma falha silenciada é uma falha.
testar	Execute a invocação de teste em Comandos de CONTEXTO, ou descubra-a e informe qual você executou. Adicione testes cobrindo a alteração. Relate a saída exata.
relatar	Informe o que mudou e a evidência para isso: arquivos, comandos, saídas. Não faça nenhuma afirmação que a evidência não suporte.
revisar	Critique o resultado no caminho em OBSERVAÇÕES contra DEFINIÇÃO DE SUCESSO. Relate lacunas, contradições, afirmações não suportadas. Não corrija nada.

Regras para preenchimento:

• Uma seção que você não pode preencher a partir do que já está no seu contexto é omitida, não inventada. OBSERVAÇÕES vazio ou CONTEXTO DO ECOSSISTEMA vazio é um estado válido; um palpite não é.
• OBSERVAÇÕES é passagem direta: apenas o que já está no seu contexto. Ler, usar grep ou executar comandos para preenchê-lo é pré-coleta; o agente faz isso com uma janela nova.
• Declare observações como fatos ("código de saída 1", "o texto do erro é: …"). Onde você tiver uma hipótese, rotule-a: Hipótese a verificar: ….
• Restrições são resultados e limites, nunca etapas. Nomear o próprio gateway do projeto em Comandos é uma restrição, não uma etapa.
• Não diga nada que o agente herde: convenções do repositório, ferramentas, "explore livremente", "use habilidades disponíveis". Isso reside nas instruções do agente do projeto. Nomeie uma habilidade apenas quando o agente precisar carregá-la e não o faria por conta própria.
• Caminhos: escritos como o agente os resolverá a partir de seu próprio diretório de trabalho; relativos dentro do repositório, e a forma de link simbólico (não o alvo resolvido) para qualquer coisa alcançada através de um link simbólico.

Prompt — modo genérico

FASE: <escrever | validar | testar | ler>
TAREFA: <a instrução exata — a edição a fazer, o padrão a encontrar, o comando a executar>

ARQUIVOS:
- <caminhos exatos>

DEFINIÇÃO DE SUCESSO:
- <o comando de verificação e seu resultado esperado>

ENTREGA:
- Inclua a saída da verificação no seu relatório.

Adjudicar

Relatórios são alegações. Para cada um:

• Verifique se a evidência suporta a conclusão. "Testes passam" sem a saída do comando não é evidência; reenvie o despacho para obter a saída.
• Julgue o trabalho retornado; não o derive novamente. Reler o que o agente leu gasta o contexto que delegar economizou.
• Dois relatórios conflitantes → encontre a alegação falsificável e despache uma verificação para ela. Confiança não é critério de desempate.
• PARCIAL → reenvie o restante, nomeando exatamente o que falta.
• BLOQUEADO por uma entrada faltante → forneça-a e reenvie. BLOQUEADO após tentativas → mude a abordagem ou escale para o usuário; não reenvie o mesmo prompt.

Reenvie a mesma fase no máximo duas vezes na mesma lacuna. Depois disso, pare e relate BLOQUEADO ao usuário com a lacuna nomeada.

Toda solicitação que alterou código recebe uma revisão independente, de um revisor diferente do escritor.

Expansão de padrão

Um usuário apontando para uma instância de um cheiro, bug ou verificação ausente está nomeando um padrão. A menos que ele tenha dito "apenas este": despache uma auditoria de todo o arquivo ou módulo para o padrão, relate as instâncias encontradas e confirme com o usuário antes de corrigir além do arquivo nomeado.

Ponteiros

• referências/sub-agent-contract.md — o que os agentes despachados seguem.
• referências/fix-cycle.md — o ciclo de reprodução primeiro para despachos de correção de bug.
• parallel-work — ramificação, redução, criador/verificador, torneios, loops com limites; também aponta para mecanismos do Claude Code.
• Se orchestrator-discipline estiver instalado: o que o orquestrador pode ler e executar; imposto por hooks.
• Se process-siren estiver instalado: escrever pontos de decisão como losangos Mermaid avaliáveis.