🎯 Por que o prompt do Condutor define tudo
O Condutor é o modelo que transforma seu objetivo vago em um briefing preciso. Otimizar o prompt do Condutor tem o maior retorno de qualquer ajuste no sistema — um briefing de qualidade reduz as iterações do loop Worker-Crítico em 60–80%.
O que é
O prompt do Condutor é a instrução que define como o primeiro modelo do Triad — Claude Opus — interroga o usuário, formula o briefing e valida o resultado final. É o elemento com maior impacto na qualidade de todo o output do sistema.
🔗 A cadeia de qualidade
💡 Por que aprender
Otimizar o prompt do Condutor tem o maior retorno de qualquer ajuste no sistema. Um briefing de qualidade reduz as iterações do loop Worker-Crítico em 60–80%. É o ponto de alavanca número um do Triad.
🔑 Conceitos-chave
A qualidade do briefing multiplica a qualidade de todo o output do sistema
O Crítico precisa de critérios testáveis para aplicar SHIP/REVISE objetivamente
O que não fazer, formatos inaceitáveis, informações que não podem ser assumidas
60–80% menos iterações no loop quando o briefing é de alta qualidade
📋 Estrutura do briefing ideal — o que não pode faltar
Um briefing eficaz tem cinco elementos obrigatórios. Se algum estiver faltando, o briefing está incompleto — e você pode auditar isso antes de despachar ao Worker.
O que é
Um briefing ideal é o documento de uma página produzido pelo Condutor que contém cinco elementos obrigatórios: objetivo sem ambiguidade, critérios de sucesso mensuráveis, restrições explícitas, contexto relevante e ângulos sugeridos para exploração paralela.
Objetivo em uma frase sem ambiguidade
Uma única frase que define o resultado esperado sem margem para interpretação. "Analise o mercado" é vago. "Identifique os 3 nichos de mercado local com ticket médio acima de $3.000 e urgência de compra alta" é objetivo.
Critérios de sucesso mensuráveis
Como você saberá que o resultado é bom. Testáveis, não subjetivos. O Crítico usa esses critérios para aplicar SHIP/REVISE objetivamente.
Restrições explícitas
O que não fazer, formatos inaceitáveis, informações que não podem ser assumidas sem dados. Previne trabalho inútil antes de começar.
Contexto relevante
Informações que o Worker precisa mas não tem acesso. Dados de mercado, histórico de decisões anteriores, restrições operacionais específicas.
3–5 ângulos sugeridos para exploração paralela
Direções que o Worker deve explorar simultaneamente. Cada ângulo deve partir de uma premissa fundamentalmente diferente — não apenas linguagem diferente.
🔑 Conceitos-chave
Objetivo, critérios, restrições, contexto e ângulos — todos obrigatórios
Verificar os cinco elementos antes de despachar ao Worker evita iterações desnecessárias
Premissa fundamentalmente diferente, não apenas reformulação da mesma ideia
O Crítico aplica SHIP/REVISE com base nesses critérios — precisam ser testáveis
📏 Como formular critérios de sucesso claros
Critérios vagos produzem outputs que parecem válidos mas são inúteis. Critérios específicos são testáveis — e são o que permite que o Crítico seja rigoroso de forma objetiva.
O que é
Um critério de sucesso claro é uma condição testável e verificável por qualquer observador — como "ticket médio acima de $3.000" ou "mínimo 3 competidores identificados com preço" — em contraste com critérios subjetivos como "boa análise" ou "resultado de qualidade".
✗ Critério vago (inútil)
- ✗"Boa análise de mercado"
- ✗"Análise profunda e detalhada"
- ✗"Resultado de alta qualidade"
- ✗"Insights relevantes para o negócio"
✓ Critério testável (válido)
- ✓"Identifica nichos com ticket médio acima de $3.000"
- ✓"Mercado local em raio de 50 milhas"
- ✓"Urgência de compra alta (perda financeira imediata)"
- ✓"Mínimo 3 competidores identificados com preço"
💡 Por que aprender
Critérios específicos são o que permite que o Crítico seja rigoroso de forma objetiva em vez de subjetiva. Sem eles, o sistema produz qualidade inconsistente — o Crítico aprova ou reprova por intuição, não por critério.
🔑 Conceitos-chave
Um critério é testável se pode ser verificado de forma objetiva por qualquer observador
Definir "urgência" como "perda financeira imediata se não resolvido" é testável
O Crítico usa os critérios do briefing como base para SHIP/REVISE — sem eles, é subjetivo
Critérios específicos produzem qualidade consistente entre diferentes execuções
🔀 Instruções para o Worker — ângulos, volume, paralelismo
O Worker sem instruções claras de paralelismo produz variações superficiais do mesmo ângulo. A instrução de premissa diferente é o que força diversidade real — não apenas linguagem diferente.
O que é
As instruções no system prompt do Worker que controlam a diversidade dos ângulos — incluindo quantos explorar (3–5), a exigência de premissa fundamentalmente diferente, raciocínio visível e o mecanismo de inversão de premissa quando o mesmo problema aparece duas vezes.
📝 O que incluir no system prompt do Worker
- •Quantos ângulos explorar: geralmente 3–5. Mais de 5 dilui o esforço; menos de 3 limita a diversidade.
- •Premissa fundamentalmente diferente: cada ângulo deve partir de uma premissa distinta, não reformulação do mesmo argumento com palavras diferentes.
- •Raciocínio visível: o Worker mostra seu raciocínio (não apenas a conclusão). O Crítico avalia a lógica, não só o resultado.
- •Sem julgamento de valor: o Worker não decide qual ângulo é melhor. Isso é papel do Crítico.
- •Inversão de premissa: "se o Crítico retornar REVISE com o mesmo problema pela segunda vez, inverta a premissa central do ângulo".
🔑 Conceitos-chave
A diferença que garante exploração genuína, não reformulação superficial
O Crítico avalia a lógica do raciocínio, não apenas a conclusão final
Quando o mesmo problema aparece duas vezes, inverter a premissa central força nova abordagem
3–5 ângulos com premissas distintas maximizam as chances de encontrar a melhor solução
⚡ Calibrando o Crítico — o que "brutalmente criticar" significa
Um Crítico vago faz o Worker girar sem melhorar. Um Crítico específico converte cada iteração em melhoria mensurável — localizando o problema, explicando por que é um problema, e mostrando como seria diferente se corrigido.
O que é
A calibragem do Crítico é o ajuste do system prompt do papel Crítico para exigir feedback específico — identificando qual é o problema, onde ele aparece no draft e como seria diferente se corrigido — em vez de avaliações vagas como "poderia ser mais detalhado".
✗ Crítica vaga (não usar)
- ✗"Poderia ser mais detalhado"
- ✗"Faltam mais exemplos"
- ✗"A análise é superficial"
- ✗"Precisa de mais profundidade"
✓ Crítica específica (usar)
- ✓"X assume Y, mas isso falha quando Z"
- ✓"No parágrafo 3, a afirmação A não é verificável — precisaria de dado B"
- ✓"A premissa central do ângulo 2 ignora o fator C — se considerado, a conclusão inverteria"
- ✓"O critério de sucesso #2 não foi atendido porque..."
📋 Três elementos de uma crítica válida
🔑 Conceitos-chave
Especificidade é o que converte crítica em instrução de melhoria
O Worker precisa saber onde corrigir, não só que algo está errado
Para tarefas estratégicas, o Crítico questiona a premissa central se não for verificável
Cada iteração deve produzir melhoria mensurável — crítica vaga não permite isso
🛟 Fallbacks no prompt — "se tokens acabarem, default para X"
Sem fallbacks explícitos, o modelo trunca silenciosamente no limite de contexto — e o Crítico avalia trabalho incompleto como se fosse completo. Fallbacks tornam as falhas visíveis e recuperáveis.
O que é
Fallbacks no prompt são instruções explícitas que definem o que o Worker e o Crítico devem fazer quando atingem o limite de contexto — como emitir um sinal PARTIAL_DELIVERY em vez de truncar silenciosamente o trabalho.
📝 Fallbacks para o Worker
"Se você atingir o limite de tokens antes de completar todos os ângulos:
- Entregue os ângulos que você completou integralmente
- Sinalize PARTIAL_DELIVERY: [X ângulos completos de Y]
- NÃO truncue ângulos no meio — um ângulo incompleto é inútil"
📝 Fallbacks para o Crítico
"Se receber um PARTIAL_DELIVERY do Worker:
- Avalie apenas os ângulos completos que foram entregues
- Sinalize no seu veredicto quantos ângulos estão faltando
- Não aplique FUNDAMENTAL FLAW por ângulos faltantes — essa é uma limitação de execução, não de qualidade"
🔑 Conceitos-chave
Todo modelo tem um limite de tokens — tarefas longas podem atingi-lo antes de completar
Um sinal nomeado que torna a falha visível e permite recuperação controlada
Truncamento silencioso é muito mais perigoso que um sinal explícito de falha parcial
Com PARTIAL_DELIVERY, você pode retomar de onde parou em vez de reiniciar do zero
📈 Iterando os prompts — como medir e melhorar
Iterar sem medir é girar em círculos. Com métricas simples — número de iterações e tipo de reprovação mais frequente — você transforma otimização em processo sistemático.
O que é
O processo de melhoria contínua dos prompts do Triad — registrando as últimas 5 execuções, identificando o padrão de reprovação mais frequente do Crítico, adicionando instrução específica para cobrir o gap e comparando com uma tarefa de referência.
Manter um log das últimas 5 execuções
Registre para cada execução: tarefa, resultado (SHIP/FUNDAMENTAL FLAW), número de iterações do loop, e tipo de reprovação mais frequente do Crítico.
Identificar o padrão de reprovação mais frequente
O padrão de reprovação do Crítico indica um gap específico no briefing do Condutor. Se o Crítico sempre reprova por "premissa não verificável", o briefing não está exigindo evidências.
Adicionar instrução específica para cobrir o gap
Uma instrução específica no briefing do Condutor que endereça diretamente o padrão de reprovação identificado.
Executar com a mesma tarefa de referência e comparar
Use a mesma tarefa de referência para comparar o número de iterações antes e depois do ajuste. Melhora real = menos iterações para a mesma tarefa.
🎯 Benchmark: bom sistema
Menos de 3 iterações no loop Worker-Crítico para tarefas de complexidade média. Se você consistentemente precisar de 5+ iterações, o briefing do Condutor precisa de ajuste.
🔑 Conceitos-chave
As últimas 5 execuções como base de dados para identificar padrões
O tipo de reprovação mais frequente mapeia diretamente para o gap no briefing
A mesma tarefa usada para comparar desempenho antes e depois do ajuste
Benchmark para tarefas de complexidade média — acima disso, o briefing precisa de ajuste
✅ Resumo do Módulo
Próximo Módulo:
3.2 — Controle de custos e gestão de rate limits