Subagentes com escalonamento para Codex
Coordenador recomendado: gpt-6.1-sol com esforço baixo. Mantenha o modelo selecionado do pai; esta skill não o altera. O agente principal orquestra: escolher o nível, definir critérios de aceitação, instruir trabalhadores, verificar entregas, fazer triagem e relatar. Ele nunca edita código de produção. Comece com relatórios compactos (no máximo 30 linhas), escopo de diffs e caminhos de evidência; inspecione mais código ou execute verificações quando a evidência estiver faltando, for contestada ou insuficiente para risco do nível D. Não repita verificações mecanicamente em um patch inalterado.
Trabalhadores executam um estágio atribuído e nunca delegam ou invocam esta skill. Respeite as permissões do host e o modo de colaboração; o modo Planejamento não permite implementação ou descoberta que produza mutações.
Níveis
Nomeie o nível na primeira linha de progresso. Qualquer estágio pode promovê-lo; nunca rebaixe. Na promoção, retenha contadores, use o orçamento total do nível superior e revise os critérios para cada trabalhador afetado. Para D, eleve Descobrir/Validar para pelo menos o degrau 3; nunca abaixe um degrau existente. Execute a descoberta recém-exigida antes da implementação adicional.
| Nível | Trabalho | Fluxo | Degrau inicial |
|---|---|---|---|
| A | Edição trivial, totalmente especificada e de baixo risco com uma verificação concreta | Implementar; entrega substitui Validar | 1 |
| B | Mudança clara que se beneficia de delegação | Implementar → Validar | 1 para ambos |
| C | Bug incerto ou funcionalidade substancial; padrão | Descobrir → Implementar → Validar | 1 para todos |
| D | Autenticação, isolamento de locatários, migrações, fila/sincronização, mudanças em dados de produção | Descobrir → Implementar → Validar | Descobrir/Validar 3; Implementar 1 |
Estágios e verificações
- Critérios de aceitação - pai: defina "Feito significa" antes de despachar. A/B derivam verificações e resultados esperados da solicitação; C/D refinam o rascunho após a Descoberta. Implementar e Validar recebem critérios idênticos e a solicitação original.
- Descobrir - C/D: confirme o escopo ou reproduza o problema. Sem edições no produto; arquivos de reprovação/teste explicitamente de propriedade são permitidos. Relate causa/escopo com locais, evidência, critérios propostos e perguntas em aberto. Para descoberta somente leitura, proíba edições no repositório na instrução e verifique o escopo; não invente uma configuração de sandbox por agente.
- Implementar: altere apenas arquivos de propriedade; relate edições, comandos, status de saída e trabalho incompleto.
- Validar - B/C/D: um agente novo que não implementou verifica o patch integrado em relação à solicitação, especificações e critérios. Sem edições no repositório ou novos testes de regressão; proponha testes faltantes para Implementar. Relatórios de rascunho e artefatos de teste normais são permitidos. Relate evidência por critério e áreas não testadas.
Pré-requisitos de teste antes de confirmar comandos. Prefira alternativas viáveis apenas quando sua cobertura for equivalente. Nunca substitua testes de unidade por evidência de integração, ponta a ponta, visual ou de dispositivo necessária apenas para obter PASS. Carregue verificações obrigatórias bloqueadas no resultado final; não presuma que qualquer executor de teste específico possa ser executado na sandbox. Repita falhas ambientais somente após uma correção concreta.
Descobrir/Implementar retornam FEITO, PARCIAL ou BLOQUEADO. Validar retorna PASS, FALHA, BLOQUEADO ou INCONCLUSIVO. Orçamentos de tempo por chamada: A/B 10 minutos; C/D 25 minutos. No limite, retorne PARCIAL ou INCONCLUSIVO com trabalho concluído, evidência, verificações pendentes e o próximo passo.
Escada e despacho
| Degrau | Modelo | reasoning_effort |
|---|---|---|
| 1 | gpt-6-luna | medium |
| 2 | gpt-6-luna | medium |
| 3 | gpt-6.1-sol | low |
| 4 | gpt-6.1-sol | medium |
| 5 | gpt-6.1-sol | high |
O degrau 2 é uma nova tentativa do Luna com evidência de correção concreta. Sol low é Light no aplicativo, não um degrau adicional.
Para uma omissão concreta ou instrução mal lida, avance um degrau; o degrau 2 é a única repetição por omissão antes do modelo mais forte. Para uma falha de raciocínio confirmada nos degraus 1 ou 2, pule diretamente para o degrau 3. Nos degraus 3 ou acima, avance um degrau. "Escalonar" abaixo significa esta regra. Pare quando o trabalho inadequado esgotar o degrau 5. Continuações produtivas e falhas ambientais corrigidas não avançam degraus. Não repita a mesma abordagem com falha sem uma correção concreta; em vez disso, escale. Isso não proíbe continuações produtivas.
Use o esquema exposto do Codex: spawn_agent com um task_name único, instrução completa em message, model explícito, reasoning_effort e fork_turns: "none" onde suportado. Não use um fork de histórico completo para substituições. Relate controles incompatíveis em vez de alterar a configuração global ou contorná-los com uma CLI aninhada. Use followup_task para continuações no mesmo degrau e um novo spawn para mudanças de modelo/esforço. Chamadas de espera/escuta/direcionamento não criam atribuições extras gratuitas. Interrompa trabalhadores atrasados e garanta que as gravações parem antes de continuar.
Registre as configurações efetivas solicitadas e observáveis; use unavailable quando os valores efetivos não forem expostos. Nunca substitua silenciosamente modelos ou configurações indisponíveis. Mantenha caminhos de evidência nas instruções em vez de copiar transcrições. As instruções de repetição nomeiam a correção/hipótese e dizem continue o patch ou substitua esses trechos.
Contabilidade e triagem
Rastreie total de chamadas, chamadas por estágio e degrau por estágio/item de trabalho separadamente. Cada nova atribuição de trabalho, repetição ou continuação custa uma chamada; mensagens de status e esperas não custam nada. Trabalhadores paralelos e trabalhadores de teste de linha de base contam individualmente. Quando suportado, crie uma entrada de lista de tarefas em tempo de execução por atribuição ou continuação despachada; atualizá-la não custa chamada. Um FALHA correta de Validar é uma validação bem-sucedida, não um motivo para escalonar o validador. Diagnostique a falha antes de escolher uma linha.
| Constatação | Próxima ação | Conta como |
|---|---|---|
| Trabalho inadequado | Escalone o estágio responsável com evidência | chamada + avanço/salto de degrau |
| PARCIAL com abordagem sólida e progresso | Continue no mesmo degrau | chamada |
| Segundo PARCIAL no mesmo degrau, ou nenhuma evidência de progresso | Escalone esse estágio | chamada + avanço/salto de degrau |
| Diagnóstico errado | Escalone Descobrir; revise a instrução de implementação depois | chamada + avanço/salto de degrau (Descobrir) |
| FALHA de Validar está errada | Pai corrige com evidência registrada, ou escala Validar; não altere Implementar | nenhum para correção; chamada + avanço/salto de degrau para revalidação |
| FALHA de Validar identifica corretamente implementação inadequada | Escalone Implementar, depois novo Validar no seu degrau atual | chamada + avanço/salto de degrau (Implementar), chamada (Validar) |
| Validar atinge tempo limite com verificações concluídas listadas | Continue no seu degrau atual nas verificações pendentes | chamada |
| Falha de ambiente ou pré-requisito ausente | Corrija dentro da autorização, depois repita uma vez; pare se não resolvido | chamada para repetição; nenhuma mudança de degrau |
| Ambiguidade bloqueadora muda "feito" ou risco do nível D | Pergunte ao usuário; nomeie o bloqueador | nenhum |
Correção do pai não dispensa verificações: a aceitação requer evidência para cada critério. Continue a validação no mesmo agente apenas se ele nunca implementou e o patch está inalterado. Após um reparo, use um novo validador. Uma FALHA correta no degrau 5 não esgota o validador; faça a triagem da implementação.
Orçamentos: A 3 chamadas; B 4; C/D 8. Verifique antes de despachar: as chamadas restantes devem cobrir todos os trabalhadores propostos mais um Validar final quando seu trabalho assim o exigir. O próprio Validar precisa apenas de sua própria chamada. Um restante + Validar final é permitido; dois restantes + Implementar é permitido; dois restantes + dois Implementar não é. Reduza um lote apenas se todo o trabalho necessário ainda couber. Reserve implementação e validação após a descoberta. Reexecute a verificação após a promoção.
A última chamada permitida pode concluir a tarefa com sucesso. Caso contrário, pare antes de trabalho não acessível, na falha do degrau final, ou para bloqueadores não resolvidos. Nunca omita silenciosamente trabalho necessário ou reivindique conclusão com validação necessária pendente. Escolhas comuns de implementação não precisam de pergunta ao usuário; registre-as.
Snapshots e entregas
O pai sozinho executa o script de snapshot Bash/Git incorporado abaixo. Nenhum arquivo complementar é necessário. Com umask 077, crie ${TMPDIR:-/tmp}/escalating-subagents/, depois um diretório task.XXXXXX único lá usando mktemp -d. Extraia o bloco marcado com este comando, nunca digitando-o novamente (SKILL é o caminho absoluto deste documento, TASK é o diretório da tarefa):
sed -n '/^<!-- agent-snapshot:start -->$/,/^<!-- agent-snapshot:end -->$/p' SKILL | sed '1,/^```bash$/d;/^```$/,$d' > TASK/agent-snapshot.sh
Seu SHA-256 (shasum -a 256 ou sha256sum) deve ser ddc6cd474ae00cb7fc7613deefb4a9f5ff959f6b641abf041f1a7e26d7d8ca95; uma incompatibilidade é um bloqueador. Use <task>/state separadamente para snapshots. Não coloque o script dentro do diretório de estado inicialmente vazio. Execute-o com Bash, nunca o carregue.
Registre os caminhos absolutos do repositório, auxiliar e estado no ledger pai; passe-os explicitamente em cada invocação, sem depender do estado do shell entre comandos. Trabalhadores nunca executam o auxiliar ou recebem seus caminhos de controle. Inicialize com sucesso antes de qualquer despacho; relate erros de inicialização e pare, identificando bloqueadores de sandbox apenas quando permissões os causaram. Palavras em maiúsculas abaixo são espaços reservados; cite caminhos reais:
bash HELPER init REPO STATE
bash HELPER capture STATE base
bash HELPER capture STATE pre-1
bash HELPER capture STATE post-1
bash HELPER diff STATE pre-1 post-1 names0
bash HELPER diff STATE pre-1 post-1 stat
bash HELPER diff STATE base post-1 patch
Capture base uma vez, pre-N imediatamente antes de cada despacho/lote, e post-N depois que todos os seus trabalhadores e gravações terminarem. Armazene a saída do patch integrado na evidência de rascunho. Snapshots nomeados são imutáveis. O estado persiste IDs de árvore e índices/objetos temporários; o banco de dados real de índice/objeto permanece inalterado. Arquivos ignorados rastreados e arquivos não rastreados não ignorados são incluídos. Não use git diff HEAD como substituto.
Falhas do auxiliar são bloqueadores. Ele rejeita gravações concorrentes; não exclua um bloqueio a menos que seu processo registrado seja confirmado como parado. Capturas interrompidas não publicadas não podem substituir snapshots nomeados. Mantenha o estado até que o relatório e qualquer acompanhamento pretendido terminem.
Use caminhos alterados delimitados por NUL para verificações de escopo, stat para resumos e o patch integrado para Validar. Edições fora do escopo são rejeitadas, a menos que o pai estenda explicitamente a propriedade para uma dependência legítima. Preserve o trabalho não relacionado; nunca redefina, limpe, armazene ou reverta automaticamente.
Despache trabalhadores Implementar disjuntos juntos dentro da capacidade disponível. Para cada lote, compare com a união da propriedade; relatórios fornecem atribuição individual, não prova de autoria. Aguarde o lote inteiro antes de verificar o escopo ou validar. Serialize arquivos/infraestrutura compartilhados e escritores concorrentes não relacionados que contaminariam os snapshots.
Verifique resultados de comandos, caminhos de evidência, locais citados e relevância do estado do arquivo nas entregas. Novas edições invalidam verificações afetadas. Trabalho aceito avança; trabalho rejeitado retorna para triagem. Rastreie comandos de longa duração até a conclusão e pare gravações pendentes antes de criar snapshots; lançamento em segundo plano não é conclusão.
Restrições do repositório e instruções
Leia o AGENTS.md aplicável, instruções com escopo, especificações e orientações de design. Use o gerenciador de pacotes, bloqueio, versão de dependências, migração e políticas de documentação do repositório. Carregue restrições de dados de produção explicitamente nas instruções relevantes do trabalhador, incluindo requisitos de dados ao vivo e somente aditivos quando aplicável; não confie que os trabalhadores os descubram indiretamente.
Trabalhadores nunca confirmam, enviam, implantam ou realizam gravações externas não relacionadas. O pai pode realizar ações explicitamente solicitadas apenas quando as regras do repositório e do host as permitirem.
Cada instrução inclui: tarefa, nível, solicitação original, caminhos absolutos do repositório/instrução/evidência, modelo/esforço, critérios na íntegra, propriedade, timeouts de comando, orçamento de tempo de parede, restrições de dados de produção e "não delegue, invoque esta skill ou execute o auxiliar de snapshot."
- Descobrir: caminhos relevantes, relatório anterior se repetindo; não possui nada, exceto arquivos de reprovação/teste explicitamente autorizados. Sem edições no produto ou instalações. Relate resultado, causa/escopo, locais, evidência, critérios propostos, pontos em aberto, próximo estágio e mudanças de nível, se houver.
- Implementar: propriedade de arquivo; os critérios de aceitação na íntegra; comandos e resultados esperados; instruções de correção/hipótese em caso de repetição; e "não mute, não adicione dependências sem análise, não introduza segredos ou credenciais."
- Validar: critérios de aceitação e solicitação original; caminhos relevantes de evidência e rascunho; lista de verificação por critério com resultados esperados e comandos de teste; "nenhuma suposição de comandos bem-sucedidos; verifique cada resultado." Relate FALHA imediatamente na primeira quebra.
Checklist do pai
- Nomeie o nível na primeira linha de progresso.
- Verifique se as chamadas restantes cobrem todos os trabalhadores e o Validar final; pare se insuficiente.
- Defina critérios de aceitação antes de cada despacho. A/B derivam diretamente; C/D refinam após a Descoberta.
- Instruções incluem: trabalho, nível, caminhos, modelo/esforço, orçamento de tempo, critérios, propriedade, restrições de dados de produção, sem delegação/invocação/auxiliar.
- Capture o estado antes do despacho (
pre-N) e depois (post-N). - Verifique o escopo (somente arquivos de propriedade). Rejeite edições fora do escopo, a menos que estendido.
- Verifique os resultados (status de saída, evidência, localizações).
- Aplique regras de triagem para cada resultado do trabalhador.
- Trabalho aceito → próximo estágio; rejeitado → triagem (repetir, escalonar, bloquear).
- Nunca pule a validação para B/C/D; nunca deixe a validação faltante não resolvida.
- Relate o resultado final: resumo da solicitação original, nível final, contagens de chamadas por estágio e degraus, e estado de cada critério.
- Inclua caminhos de evidência ou explique por que não estão disponíveis.
(Conteúdo do script de snapshot não traduzido, mantido como está para integridade técnica)
#!/usr/bin/env bash
set -euo pipefail
# ... (snapshot script logic)
Nota: O conteúdo acima foi truncado para fins de tradução, mas a skill original contém o script de snapshot Bash completo entre as tags
agent-snapshot.