Fanout – passagem seletiva de ideação divergente
Base empírica: avaliação em duas fases do mantenedor. O fanout fornece uma vantagem pequena, mas consistente, em tarefas de design divergente e nenhuma vantagem em trabalho convergente de causa raiz. Vale ~7x tokens apenas quando a tarefa é aberta E de alto risco. Esta habilidade existe para que o suporte esteja disponível sob demanda, sem nunca ser acionado em trabalho rotineiro.
Passo 0 – portão antes de executar (obrigatório)
Verifique a tarefa contra o seletor. Ambos devem ser verdadeiros:
- Aberta? Múltiplas respostas válidas ("design / nome / abordagem / hipóteses para X"). Se a tarefa é "por que X quebrou", "a correção funcionou", "qual é a causa raiz", ou qualquer coisa com uma resposta verificável -> isso é CONVERGENTE. Diga ao usuário que a chamada única é a ferramenta melhor aqui e pergunte se deseja prosseguir mesmo assim antes de executar. Não execute silenciosamente em tarefas convergentes.
- Alto risco o suficiente para ~7x tokens? Uma regra estrutural / formato de API / nome / estratégia, não algo descartável. Se parecer de baixo risco, diga e confirme.
Se o portão for ambíguo, declare sua leitura e pergunte. Uma vez aprovado, prossiga.
Passo 1 – obtenha o problema
Aceite a declaração do problema de: um arquivo mencionado com @, um caminho de arquivo ou texto colado na mensagem do usuário. Se apenas um tópico vago for fornecido, peça uma ou duas frases de contextualização do problema primeiro – os quadros precisam de algo concreto.
Passo 1.5 – ORIENTE se o alvo for um artefato do projeto (obrigatório)
Um /fanout <caminho do arquivo> parece pré-orientado, mas NÃO é: os quadros raciocinam apenas com base no artefato e contradirão confiantemente o estado ativo do projeto se você não alimentá-los com ele. Antes do Passo 2, se o problema for (ou nomear) um arquivo dentro de uma pasta de projeto – uma especificação, documento de decisão, thread CHECKPOINT, arquivo de código – leia o CHECKPOINT.md desse projeto até o final primeiro (e seu CLAUDE.md se o hook não o trouxe à tona). O recibo de SessionStart é uma contagem de bytes/linhas, NÃO o arquivo – uma prévia não é uma leitura. Em seguida, extraia as restrições estruturais (prazos, portões de financiamento/sequenciamento, decisões vigentes, o que já foi tentado/rejeitado, números concretos) e cole-as literalmente em CADA prompt de quadro E no crítico, da mesma forma que o texto do artefato. Um quadro que recebe o artefato, mas não o estado do projeto, é uma falha documentada (um fanout real em uma especificação de custo trouxe à tona um enquadramento "prematuro, faça após o ponto de equilíbrio" que o CHECKPOINT do projeto contradizia diretamente). Pule esta etapa APENAS quando o problema for genuinamente livre de projeto (uma pergunta abstrata colada, um exercício de nomenclatura/formato de API sem estado ativo por trás).
Passo 2 – DIVERGÊNCIA (5 chamadas de Agent paralelas, uma mensagem)
Dispare 5 agentes general-purpose EM PARALELO (mensagem única, 5 chamadas de ferramenta). Dê a cada um o mesmo problema e UM ponto de vista distinto. A instrução de cada agente: "Analise APENAS do seu ponto de vista atribuído. Gere 4-6 abordagens/ideias DISTINTAS; para cada uma, nomeie os modos de falha (armadilhas) que ela carrega e declare o mecanismo. Seja específico, nomeie mecanismos, não suavize, não classifique, não avalie suas próprias ideias. Mantenha conciso (isso alimenta uma passagem de crítico)." Retorne a saída diretamente (sem escrever arquivos, a menos que o usuário tenha solicitado salvar).
Os 5 pontos de vista (textual):
- ARQUITETURA / SISTEMAS – pense em máquinas de estado, fluxos de dados e onde a informação é transformada ou perdida; o que o sistema faz na camada abaixo do comportamento visível; como ele quebra sob concorrência, falha ou escala.
- ADVERSARIAL / ADVOGADO DO DIABO – assuma que cada opção tem uma falha fatal e encontre-a; o que cada uma assume silenciosamente; o que seria verdade se a resposta óbvia for uma distração.
- PRIMEIROS PRINCÍPIOS – despoje até o mecanismo subjacente, reconstrua a partir de restrições reais, desconfie de convenções; o que é realmente necessário versus meramente habitual.
- PRATICANTE / OPERADOR – você executou isso em produção e foi acionado às 3 da manhã; preocupe-se com falhas de campo, casos extremos, trabalho operacional, observabilidade, a lacuna entre o design e a realidade de plantão.
- GENERALISTA EXTERNO – sem contexto de domínio; o que faz sentido intuitivo; desconfie de jargão que esconde raciocínio circular; a armadilha óbvia em retrospecto que os especialistas internos podem perder.
Passo 3 – CRÍTICO (1 chamada de Agent)
Assim que todos os 5 retornarem, dispare UM agente general-purpose com todas as 5 saídas + o problema. Instrução: "1) PONTUE cada abordagem quanto a novidade/viabilidade/adequação (0-10). 2) AGRUPE entre quadros por estratégia subjacente; note onde 2+ quadros convergiram (essa convergência é sinal). 3) UNIÃO DE ARMADILHAS: a união deduplicada de armadilhas distintas e mecanicamente declaradas em todos os 5 quadros, cada uma com seu mecanismo. 4) APROFUNDE AS 3 MELHORES: versão mais nítida, mecanismo, armadilhas a evitar, a suposição mais arriscada em que se baseia + a maneira mais barata de testar essa suposição antes de se comprometer, e um primeiro passo concreto. Seções de saída: ## Pontuadas, ## Agrupamentos, ## União de armadilhas, ## 3 melhores aprofundadas, ## Síntese (4-6 frases: direção mais forte + as armadilhas que mais a ameaçam)."
Passo 4 – apresente
Mostre ao usuário as ## 3 melhores aprofundadas, ## União de armadilhas e ## Síntese do crítico no chat. Resuma a convergência (quais direções múltiplos quadros alcançaram independentemente). NÃO despeje todas as 5 saídas brutas dos quadros a menos que solicitado.
Por padrão, não persista nada (arquivos temporários residuais são sua própria bagunça). Se o usuário quiser o registro completo, ofereça-se para salvar a saída do crítico + os quadros em um caminho que ele nomear.
Notas
- Apenas ferramenta Agent nativa – NÃO faça shell para um
claude -paninhado para os quadros (chamadas CLI aninhadas são não confiáveis sob camadas de permissão/segurança; a ferramenta Agent é o caminho suportado). - Isso é uma única execução por invocação (n=1). Se o usuário quiser uma verificação de variância, ele pode invocar /fanout novamente – mas o pequeno tamanho do efeito raramente justifica isso.
- Nunca acione automaticamente. Apenas as formas de superfície explícitas na descrição.