oil-oil/codex-team-mode

Modo Equipe

Lidere a tarefa no thread principal. Use o menor conjunto útil de subagentes para isolar trabalhos ruidosos, reduzir o contexto caro do agente principal, executar trabalhos independentes em paralelo ou obter uma revisão imparcial. Não transforme os papéis em uma pipeline obrigatória.

Portão de Despacho

Toda chamada spawn_agent deve passar explicitamente agent_type como exatamente um dos seguintes: Explorer, Executor, Complex Executor ou Reviewer.

• Nunca omita agent_type e nunca passe default. O perfil default é uma guarda de despacho com falha segura, não um agente funcional.
• Nunca use task_name para selecionar um perfil; ele apenas rotula o thread filho.
• Se o perfil customizado pretendido estiver indisponível, mantenha o trabalho no thread principal ou repare os perfis. Não use silenciosamente um filho genérico.
• Se um filho retornar a mensagem da guarda de despacho ou seu rastreamento mostrar default / subagent/unknown, rejeite sua saída e faça o novo despacho somente depois de selecionar explicitamente o perfil customizado pretendido.

Leia references/custom-agents.md somente ao instalar, reparar ou verificar os quatro perfis funcionais e a guarda default. O auto-teste controlado de integração descrito lá é a única vez que o Modo Equipe omite deliberadamente agent_type.

Integração Única

Não inspecione arquivos de agente, carregue instruções de integração ou repita explicações de configuração durante o roteamento normal do Modo Equipe. Trate as escolhas ativas de spawn_agent.agent_type e descrições como evidência de prontidão em tempo de execução. Quando todos os quatro perfis funcionais estiverem disponíveis e default for descrito como a guarda de despacho, pule a integração sem mencioná-la.

Leia references/custom-agents.md e inicie a integração somente quando um perfil ou guarda necessário estiver indisponível, ou quando o usuário pedir explicitamente para instalar, reparar, verificar, mover, desabilitar ou personalizá-los. Obtenha autorização antes de escrever configurações pessoais ou do projeto. Após uma configuração ou reparo bem-sucedido, informe ao usuário uma vez o que foi instalado, quais modelos foram atribuídos, que a guarda afeta os despachos de subagentes omitidos/padrão em seu escopo de instalação, quando uma reinicialização ou nova tarefa é necessária e como desabilitar ou restaurar apenas a guarda sem remover os quatro perfis funcionais.

Regras Obrigatórias

• Quando esta Habilidade for ativada, envie imediatamente uma breve atualização de comentário no idioma do usuário, prefixada com 👾. Para português, diga 👾 Modo Equipe ativado.; traduza naturalmente para outros idiomas. Anuncie uma vez por tarefa, não antes de cada chamada de subagente.
• Ativar o Modo Equipe não exige gerar nenhum subagente. Mantenha trabalhos claros, curtos e de baixo risco no thread principal quando a delegação ou revisão independente custar mais do que acrescentar. Não lance um Executor ou Revisor apenas para completar uma sequência de papéis.
• Antes de cada criação, identifique um benefício material: paralelismo útil, isolamento de contexto, execução limitada de menor custo ou julgamento independente. Conte briefing, inspeção, retrabalho e espera como custo de coordenação. Uma solicitação explícita de Modo Equipe ativa este guia de roteamento; por si só não torna uma criação válida.
• Mantenha todo o roteamento e dispersão no thread principal. No Modo Equipe padrão, os filhos nunca geram descendentes; eles retornam evidências, artefatos ou bloqueios ao pai. Trate uma solicitação explícita do usuário para delegação recursiva como uma expansão de escopo separada, com sua própria permissão, profundidade e decisão de uso.
• Use fork_turns="none" por padrão e sempre para um novo Reviewer.
• Mantenha decisões não resolvidas de intenção do usuário, produto, editorial, arquitetura e segurança, além da aceitação final, no thread principal.
• Mantenha um escritor por artefato compartilhado, árvore de trabalho ou sistema mutável. Escritores paralelos exigem alvos isolados ou propriedade estável e disjunta.
• Inspecione os artefatos reais, fontes, diffs e saída de verificação antes de aceitar trabalho delegado.
• Se um filho errar, expirar ou for interrompido, inspecione artefatos compartilhados e evidências de rastreamento antes de tentar novamente. Repita uma falha transitória no máximo uma vez e somente quando nenhum resultado utilizável existir; caso contrário, recupere no thread principal ou reescopte o trabalho restante.
• Trate o modo de permissão ativo da tarefa pai como a permissão efetiva do filho. Não infira isolamento somente leitura do TOML sozinho; use a integração ou verificação de diagnóstico na referência quando as permissões precisarem de confirmação.

Quando o usuário pedir para avaliar o próprio Modo Equipe, comparar modelos ou esforço de raciocínio, ou medir se a delegação valeu a pena, leia references/evaluation.md antes de projetar o teste.

Contrato de Despacho

Antes de cada criação, torne o briefing auto-contido com estes campos rotulados:

• Resultado: o resultado finalizável de forma independente que o filho deve retornar.
• Benefício: a vantagem material sobre manter esta fatia no thread principal.
• Fontes: todo caminho, URL, conjunto de dados ou artefato bruto necessário para o trabalho factual.
• Escopo: leituras ou gravações permitidas, propriedade, exclusões e autoridade de ação externa.
• Verificações: critérios de aceitação e validação que o filho possui.
• Parar quando: a conclusão limitada, bloqueador ou limite de evidência que encerra o turno.
• Retorno: o formato conciso de relatório ou artefato esperado pelo pai.

Não crie enquanto Resultado, Benefício, Fontes necessárias, Verificações ou Parar quando estiver faltando. Mantenha a fatia no thread principal quando não for finalizável de forma independente ou quando o ganho esperado não exceder o briefing, espera, inspeção e possível retrabalho.

Para um Reviewer, também nomeie um Risco não resolvido concreto, a Evidência exata a inspecionar, Verificações já aprovadas e Não repetir. Peça descobertas a partir desse pacote primeiro e exija um veredito parcial utilizável se a condição de parada chegar antes da revisão exaustiva.

Roteie o Trabalho

• Explorer (Luna Médio): use para descoberta somente leitura não trivial. Dê a Exploradores separados fatias de evidência independentes e não repita o trabalho deles no thread principal.
• Executor (Luna Alto): use para trabalho claro, limitado e de baixo risco com verificações determinísticas. Mantenha o trabalho no thread principal quando o custo de transferência for maior do que fazê-lo diretamente.
• Executor Complexo (Terra Alto): use para implementação convencional substancial após o thread principal ter fixado a arquitetura, escopo e verificações. O thread principal ainda inspeciona e aceita o resultado.
• Thread principal: mantenha a fatia crítica quando precisar de arquitetura nova, verificação fraca ou visual, design de exportação/compilador, julgamento de segurança ou reversão, ou quando um falso sucesso plausível seria custoso.
• Reviewer (Sol Alto): use apenas para um risco concreto não resolvido que se beneficie de julgamento independente novo. Não torne a revisão uma segunda passagem automática.

Após a descoberta, deixe o thread principal escolher se continua diretamente ou delega. Delegue apenas quando execução limitada, isolamento de contexto, menor custo, paralelismo útil ou julgamento independente criar valor claro.

Coordene o Trabalho

• Comece com o número mínimo útil de agentes. Paralelize apenas exploração, análise, testes, triagem, produção ou revisão genuinamente independentes; não crie trabalho duplicado apenas para manter os agentes ocupados.
• Antes da execução, declare claramente qual deve ser o resultado, o que pode ser tocado, o que deve permanecer inalterado e como a conclusão será verificada. Revise esses requisitos se novas evidências entrarem em conflito com eles.
• Verifique na proporção do risco. Use revisão independente para resultados complexos, consequentes ou difíceis de verificar, em vez de para toda tarefa.
• Reutilize verificações aprovadas como evidência. Não peça a outro Agente para repetir validação ampla, a menos que a integridade ou relevância dessas verificações seja em si o risco não resolvido.

Contexto e Reutilização

• Dê a cada novo subagente um briefing compacto e auto-contido contendo apenas o objetivo, fontes ou caminhos relevantes, escopo, autoridade, exclusões, resultado pretendido, verificações necessárias e formato de retorno. Nunca copie credenciais nele.
• Com fork_turns="none", assuma que o filho não sabe nada da conversa pai. Nomeie todo artefato de fonte necessário para afirmações factuais; se uma fonte estiver faltando, forneça seu caminho, restrinja o filho a coletar essa evidência ou mantenha a fatia dependente da fonte no thread principal.
• Reutilize um Explorer ou executor existente quando novo trabalho pertencer à mesma tarefa, tópico, área de negócio, subsistema, artefato ou fluxo de trabalho e seu contexto anterior permanecer útil. Envie apenas o novo objetivo e restrições alteradas.
• Comece do zero quando o contexto anterior estiver desatualizado ou ruidoso, o papel ou autoridade mudar, ou o julgamento independente for importante.
• Reutilize um Reviewer apenas para esclarecer seu relatório existente. Use um Reviewer novo para uma nova revisão ou para verificar trabalho revisado.
• Não dê a um Explorer uma conclusão esperada. Não conte a um Reviewer o debate anterior, autor, suspeitas de descobertas ou veredito desejado.

Lidando com Descobertas

• Valide as descobertas em relação às fontes subjacentes, artefato e resultado pretendido antes de agir.
• Deixe o thread principal aplicar reparos aceitos diretamente ou delegá-los de acordo com escopo, contexto, custo e risco.
• Quando a avaliação de risco exigir revisão independente após reparos consequentes, use um Reviewer novo com apenas o artefato atualizado e requisitos neutros.
• Se um Reviewer ultrapassar sua condição Parar quando sem um retorno utilizável, solicite um veredito parcial uma vez e então interrompa-o. Inspecione o rastreamento e evidências existentes; não inicie automaticamente outro Reviewer.

Inspecione Uso Local

Quando o usuário pedir consumo de modelo ou subagente, execute python3 scripts/usage_by_model.py. Para a tarefa ativa use --task-id current --by-agent --by-session; para histórico mais amplo use --days N ou --all, com --json quando a saída estruturada ajudar. Relate tokens processados mais entrada não armazenada em cache, entrada em cache, saída, saída de raciocínio e créditos estimados; não esconda os totais de tokens atrás dos créditos. Trate raciocínio como um subconjunto da saída e tokens processados como entrada mais saída, de modo que nem tokens em cache nem de raciocínio sejam contados duas vezes. Nunca apresente uma conversão universal de créditos para tokens: use a tabela de preços fornecida porque cada modelo e tipo de token tem uma taxa diferente, e rotule o valor observado de tokens processados por crédito como específico da carga de trabalho. Este é um diagnóstico sob demanda, não parte do roteamento normal. Relate que logs locais excluem sessões remotas efêmeras ou indisponíveis, créditos configurados assumem velocidade Padrão e /usage do Codex permanece autoritativo para limites de conta.

Diretrizes

• Preserve trabalho não relacionado do usuário e obedeça às instruções aplicáveis do projeto, domínio e ferramenta.
• Delegação não expande autoridade. Não commite, publique, implante, envie mensagens, mude estado externo ou manipule dados sensíveis além da solicitação do usuário.
• Para pesquisa atual ou factual, prefira fontes primárias, registre datas relevantes, cite evidências e distinga fato de inferência.
• Mantenha a exploração de dados privados restrita e retorne apenas a evidência mínima necessária.
• Resolva alegações conflitantes contra a evidência mais forte disponível e retorne um resultado coerente ao usuário.