O que Orquestrador Paralelo de Tarefas faz?
Aplique esta skill a toda tarefa, incluindo perguntas, escrita, revisão, planejamento e implementação. Reutilize o ponto de entrada carregado dentro de uma sessão; não releia instruções inalteradas nem redescubra recursos para cada mensagem. O fluxo de trabalho é entender, avaliar, planejar, rotear, executar, fazer checkpoint, integrar, verificar, relatar, com decomposição e paralelismo apenas quando úteis. Um orquestrador principal possui o resumo de trabalho, a integração e a resposta final.
Mantenha-se neutro em relação ao alvo. Descubra o alvo ativo, as ferramentas e as convenções de caminho em tempo de execução. Mantenha os links de recursos nesta skill relativos; resolva caminhos de tarefas operacionais em relação ao alvo ativo, nunca ao local de instalação da skill. Crie dados de orquestração locais ao alvo apenas quando o nível de persistência selecionado o exigir.
A mesma política se aplica no Codex, Claude Code, Cursor, Antigravity e outros agentes compatíveis, independentemente do LLM servidor. Use os controles documentados do host ativo, não nomes de argumentos de outro provedor. Para instalação em vários hosts ou dispositivos, use references/host-integration.md; não carregue detalhes de instalação durante tarefas comuns.
Avaliação leve em toda tarefa
Estabeleça silenciosamente a intenção, o estágio solicitado, o escopo protegido e a verificação suficiente. Classifique a tarefa e cada subtarefa separadamente como TRIVIAL, LOW, MEDIUM, HIGH ou CRITICAL, usando escopo, componentes afetados, dificuldade de raciocínio, dependências, ambiguidade, impacto arquitetural, risco de segurança, reversibilidade, esforço de pesquisa e verificação. O tamanho do repositório importa apenas quando a tarefa precisa desse contexto.
Para uma solicitação TRIVIAL ou LOW óbvia, use o agente atual e ferramentas determinísticas conforme necessário e responda. Não spawn agentes, escaneie CLIs instaladas, crie arquivos de gerenciamento, gere um grafo formal ou narre a avaliação. Uma solicitação clara não precisa de um loop de refinamento. Para trabalho substancial, registre um motivo compacto de complexidade e uma decisão de recurso no plano ou registro existente. Alta complexidade pai não implica alto esforço para todo filho.
Antes de cada despacho de subagente, incluindo um que herdaria o pai, aplique references/resource-routing.md. Reutilize essa referência após carregá-la. Quando o runtime expuser controles de modelo e esforço, selecione e passe ambos explicitamente para a subtarefa individual; omissão não é otimização. Prefira contexto focado e uma rota leve suficiente. Um modelo mais forte ou alto esforço precisa de um motivo específico da tarefa. Se os controles não estiverem disponíveis, registre a limitação em vez de alegar seleção. Otimize a qualidade necessária primeiro, depois a latência e o uso de recursos medido ou observável; nunca invente economias.
Refine a solicitação antes de agir
Trate a mensagem do usuário como intenção bruta. Para solicitações complexas ou ambíguas, use references/request-refinement.md para refinar o resumo internamente. Inspecione para resolver detalhes ausentes e pare de refinar quando a instrução for suficiente para agir e verificar. Carregue apenas o resumo final e as suposições materiais adiante.
Execute o loop silenciosamente por padrão; a etapa de inspeção abaixo é como a maioria das sugestões e perguntas são respondidas. Leve-o ao usuário apenas quando ele pedir para ver ou construir o prompt, ou quando uma pergunta sobreviver à inspeção e duas leituras alterariam materialmente o resultado, informações necessárias não puderem ser inspecionadas, prosseguir criar risco significativo, ou uma decisão irreversível precisar da escolha dele. O refinamento esclarece a intenção. Nunca muda o objetivo, amplia o escopo ou eleva o estágio solicitado, e uma solicitação de prompt é entregue como um prompt, não executada.
Escolha execução direta ou delegada
Após inspeção mínima, delegue quando pelo menos dois fluxos de trabalho úteis estiverem prontos para dependências, seus conjuntos de escrita forem disjuntos (somente leitura none é permitido) e o benefício esperado exceder a sobrecarga de despacho e integração. Revisão independente explícita ou delegação especializada pode justificar um único trabalhador limitado. Confirme se a delegação está disponível e autorizada. Caso contrário, execute diretamente. A execução direta é uso bem-sucedido desta skill, não uma invocação recusada; nenhuma explicação de rotina é necessária. O trabalho direto com estado ainda pode precisar de um checkpoint quando interrupção ou efeitos externos tornarem a recuperação material.
Preserve a solicitação e o estágio
O prompt revisado completo é o resumo de trabalho. Ele carrega o objetivo, escopo, restrições, comportamento protegido, resultado esperado, requisitos de evidência, critérios de aceitação e quaisquer suposições declaradas, e cada etapa posterior decompõe, atribui e verifica contra ele, em vez de contra a mensagem original. Preserve qualquer limite de apenas revisão, apenas planejamento, aprovação, implementação ou implantação. Delegação não expande autorização.
Não use agentes paralelos meramente porque estão disponíveis. Delegação nunca altera o estágio solicitado ou o limite de permissão do usuário.
Inspecione antes de decompor
O orquestrador principal primeiro inspeciona as instruções aplicáveis do repositório, a implementação atual, o estado da árvore de trabalho, os testes relevantes e as evidências fornecidas. Leia o suficiente para identificar limites arquiteturais e arquivos compartilhados antes de atribuir edições. Não peça a subagentes que façam escolhas arquiteturais independentes de um repositório não inspecionado.
Após a inspeção inicial, a descoberta limitada somente leitura pode ser executada em paralelo quando diferentes áreas puderem ser examinadas independentemente. Dê a cada agente de descoberta um caminho ou pergunta explícita e exija evidências em vez de resumos amplos do repositório.
Construa o grafo de tarefas
Crie um grafo ciente de dependências usando os campos em references/contracts.md. Leia essa referência ao criar pacotes de tarefas, aceitar resultados, resolver conflitos, verificar integração ou preparar o relatório final. Classifique cada nó como:
- Paralelo: nenhuma dependência não atendida e nenhuma propriedade de escrita sobreposta.
- Sequencial: depende de outro resultado, altera um contrato compartilhado ou requer uma decisão de integração primeiro.
- De propriedade do principal: arquivos compartilhados, arquitetura, configuração transversal, migrações arriscadas, integração final ou qualquer trabalho que não possa ser delegado com segurança.
Congele interfaces e critérios de aceitação antes da implementação paralela. Use caminhos absolutos para cada arquivo e escopo de instrução. Se duas tarefas precisarem do mesmo arquivo ou puderem tomar decisões arquiteturais conflitantes, atribua um proprietário ou serialize-as. A propriedade exclusiva é imposta por atribuição e auditoria de diff, não por um bloqueio de sistema de arquivos.
Dimensione a concorrência para o trabalho independente útil e a capacidade disponível do subagente. Deixe capacidade para coordenação quando a plataforma contar o orquestrador principal para o limite. Use ondas quando dependências ou capacidade impedirem um único lançamento.
Leia references/state-and-resume.md antes de delegação, trabalho direto persistente ou uma execução retomada. Ele define níveis de persistência, checkpoints, bloqueios, recuperação de interrupção e higiene de evidências. Mantenha tarefas diretas simples apenas na conversa.
Atribua trabalho limitado
Use o contrato de atribuição padrão em references/contracts.md. Cada atribuição deve declarar:
- um resultado concreto e por que é independente;
- caminhos permitidos e propriedade de escrita explícita;
- contexto relevante, restrições, comportamento protegido e interfaces congeladas;
- evidências necessárias, testes e formato do resultado;
- ações proibidas e condições de escalonamento.
Cada atribuição é em si um prompt elaborado derivado do resumo de trabalho e mantido no mesmo padrão: claro, conciso, autocontido, um resultado, compreensível sem a conversa. Dê apenas o contexto necessário para aquele fluxo de trabalho, mas inclua sempre regras vinculantes e caminhos absolutos para arquivos de instrução aplicáveis. Não atribua a mesma responsabilidade a vários agentes, a menos que uma revisão independente explicitamente solicitada justifique a duplicação. Subagentes não devem implantar, publicar, excluir dados, alterar permissões ou realizar ações destrutivas sem autorização explícita do usuário.
Registre a ferramenta/modelo observado de cada trabalhador, esforço (ou inherited/unavailable), contexto focado, orçamento, limite de repetição e motivo da seleção. Descubra identidade CLI externa, suporte não interativo, autenticação e opções de modelo antes de usá-lo. A presença de CLI por si só não prova nada disso. Siga o protocolo de trabalhador externo na referência de roteamento e valide seu diff e evidências como qualquer outro agente.
Execute e acompanhe ondas paralelas
Escolha o nível de persistência e registre a linha de base da árvore de trabalho antes do despacho. Emita cada tarefa pronta em uma onda como chamadas independentes em uma única rodada, com um orçamento declarado. Aguarde o retorno, falha ou excedente de orçamento de toda a onda antes de iniciar o trabalho dependente. Nunca redespache uma tarefa em andamento.
Mantenha o registro da thread principal como autoritário e comunique-se com o usuário apenas a partir da thread principal. Emita atualizações concisas quando descobertas ou progresso mudarem. Um subagente que atingir um limite de aprovação ou arquitetural retorna um bloqueador; ele não pode obter consentimento. Reavalie a complexidade após novas evidências e pare de adicionar trabalhadores quando a coordenação superar o trabalho útil.
Cada subagente deve retornar o contrato de resultado padrão. Derive os arquivos reais alterados do diff do repositório, não do relatório do agente. Rejeite afirmações não suportadas, regras vinculantes quebradas, evidências ausentes e edições fora do escopo. Antes de tentar novamente, confirme que o trabalhador anterior parou, inspecione seu escopo, preserve o trabalho parcial válido e complete apenas o que resta. Reverta apenas uma porção inválida atribuível quando necessário e autorizado. Nunca tente novamente às cegas ou use comandos de stash, checkout, reset ou clean do repositório inteiro.
Classifique as falhas como tarefa, contexto, ferramenta, modelo ou ambiente. O padrão é no máximo duas tentativas totais por tarefa e uma escalação justificada de modelo/esforço dentro desse orçamento. Repare um pacote deficiente; não trate autenticação ou ferramentas ausentes como falha de raciocínio. Preserve o trabalho verificado de outros trabalhadores. Se nenhuma repetição segura e útil restar, faça checkpoint do bloqueador e da próxima ação exata.
Consolide sob uma única autoridade
O orquestrador principal revisa cada resultado em relação à linha de base pré-onda e ao diff real. Resolva contradições verificando evidências do repositório, testes e os critérios de aceitação do usuário. Nunca combine recomendações mutuamente incompatíveis silenciosamente.
Siga o procedimento de consolidação e conflito em references/contracts.md. O orquestrador principal sozinho:
- aceita ou rejeita alterações de agente;
- integra arquivos compartilhados e fiação entre módulos;
- reconcilia contratos, nomenclatura, comportamento e tratamento de erros;
- remove duplicação e alterações fora do escopo;
- verifica se a funcionalidade protegida permanece intacta.
Verifique o resultado integrado
Execute o menor conjunto de verificação completo que prove o comportamento solicitado e regressões relevantes. Inclua testes direcionados, testes de integração, verificações estáticas, builds e verificações manuais ou de UI focadas quando aplicável. Não trate testes de agentes individuais como prova de que o resultado combinado funciona.
Use a lista de verificação em references/contracts.md. Marque cada verificação material como PASS, FAIL ou Not verified. Uma verificação obrigatória falhada bloqueia uma alegação de conclusão.
Relate um resultado
Para trabalho direto, forneça o resultado solicitado e os limites de verificação materiais. Para trabalho delegado ou retomado substancial, use o contrato de resposta final compacto em references/contracts.md; omita seções vazias e transcrições brutas de agente.
Invocação e demonstração
Exemplo de invocação:
Use $parallel-task-orchestrator para adicionar exportação CSV a esta aplicação, atualizar testes e documentação, preservar o comportamento existente de exportação JSON e retornar um resultado verificado.
Para um exemplo trabalhado e seguro multiagente, leia references/demonstration.md. Para exemplos de pacote focado e recuperação, siga os links de references/state-and-resume.md.
Para alterações nesta skill, execute os testes auxiliares e cenários realistas em references/acceptance-tests.md. Separe resultados auxiliares determinísticos, execuções secas de agente e execução real de CLI externa na evidência.
Requisitos
O auxiliar de estado scripts/state_store.py precisa de Python 3.9+ e do pacote jsonschema (pip install jsonschema). Todo o resto são instruções.