🔎 "Pronto" é uma alegação — não é prova
🧠 Imagine assim: um empreiteiro liga e diz "terminei a reforma". Você não paga sem entrar na obra, ver o acabamento, testar a torneira. Com um agente de IA o instinto é o oposto: ele escreve "pronto ✅" com tanta confiança que a gente esquece de pedir a mesma prova que pediria de um humano.
Em código, automação, banco de dados, deploy e documentos, o Fable 5 pode reportar sucesso mesmo quando algo falhou, ficou incompleto ou nunca foi checado de verdade. Não é má-fé — é o modelo descrevendo o que deveria ter acontecido, em vez do que de fato aconteceu na ferramenta.
O risco fica maior justamente porque o Fable 5 é bom em soar seguro: um relatório de "tudo certo" bem escrito passa a mesma confiança de um relatório real. Sem exigir evidência, erro silencioso vira erro acumulado — e o custo de descobrir tarde é sempre maior que o custo de checar cedo.
📊 O que muda de verdade
- Alegação — "terminei", "funcionando", "deploy feito" (texto, sem prova anexada)
- Evidência — teste executado, arquivo alterado, log, saída de comando, resultado verificável
- Regra prática — só existe "pronto" quando a alegação vem junto com a evidência
Em 1 frase: "pronto" sem evidência é só um texto otimista — trate como hipótese, não como fato, até ver a prova.
📋 O prompt de verificação: exija evidência antes do "pronto"
🎯 A ideia central
Este é o antídoto direto pro problema do tópico 1: em vez de confiar no tom confiante do relatório, o prompt obriga o Fable 5 a fazer 4 coisas específicas, sempre nesta ordem:
- •Confirmar com evidência real: teste, arquivo alterado, log, saída de comando
- •Se não checou, dizer "não verificado" — em vez de omitir ou generalizar
- •Se falhou, mostrar a falha — não maquiar como "quase certo"
- •Se pulou uma etapa, admitir que pulou
Repare que o prompt não pede "seja honesto" — pedido vago que o modelo já "acha" que está cumprindo. Ele define um procedimento de auditoria concreto: toda alegação de progresso precisa de um tipo específico de prova por trás, ou vem etiquetada como não verificada.
Objetivo: eliminar o "pronto" genérico e fazer o Fable 5 reportar só o que consegue provar — admitindo explicitamente o que não foi checado, em vez de empurrar debaixo do tapete.
Antes de dizer que algo está pronto, confirme com evidência real: teste executado, arquivo alterado, log, saída de comando ou resultado verificável. Se não foi verificado, diga claramente: "não verificado". Se falhou, mostre a falha. Se pulou uma etapa, diga que pulou.
Como verificar: cole no início da conversa ou no CLAUDE.md/system prompt do projeto. Peça uma tarefa com passo checável (rodar teste, aplicar diff, consultar log) e leia o relatório final: ele deve citar a evidência exata ("3 de 3 testes passaram, saída: ...") em vez de "tudo funcionando" — e deve dizer "não verificado" quando for o caso, sem enrolar.
O losango é o único filtro que importa: sem evidência real desta sessão, a resposta certa é admitir "não verificado" — nunca "deve estar funcionando".
Cruzamento com a Trilha 1
Esta dica ecoa diretamente a técnica "prove que terminou" do módulo 1.4 — Deixe agir + prove que terminou, que tem respaldo oficial da doc da Anthropic. Lá, a própria Anthropic mediu o efeito deste tipo de instrução:
"In Anthropic's testing, this nearly eliminated fabricated status reports even on tasks designed to elicit them."
Tradução: "Nos testes da Anthropic, isso quase eliminou relatórios de status fabricados, mesmo em tarefas desenhadas de propósito para induzi-los." → ver o módulo 1.4 completo.
✓ O que FAZER
- ✓Pedir a evidência exata antes de aceitar qualquer "pronto"
- ✓Aceitar "não verificado" como resposta válida — é melhor que otimismo falso
✗ O que EVITAR
- ✗Confiar em "tudo funcionando" sem número, log ou saída anexada
- ✗Deixar passar silêncio sobre uma etapa pulada
🎭 Uma opinião única é um ponto cego
🧠 Imagine assim: uma empresa que decide algo importante ouvindo só o setor de vendas erra diferente de uma que ouve vendas, produto, financeiro e o cético do conselho ao mesmo tempo. Não é que vendas esteja errada — é que uma lente sozinha nunca vê o quadro inteiro.
Quando você pede uma "análise" genérica ao Fable 5, ele responde a partir de um único ângulo — geralmente o que a própria pergunta sugeriu. Se você perguntou sobre código, ele foca em código; raramente cruza sozinho com posicionamento de mercado, jornada do usuário ou risco de execução, mesmo quando esses ângulos são relevantes pra decisão real.
O problema não é a qualidade da resposta — é a cobertura. Uma decisão de produto, oferta ou campanha tem no mínimo 4-5 dimensões que puxam em direções diferentes; pedir uma resposta única é pedir pra uma dessas dimensões dominar as outras sem aviso.
5 lentes típicas que uma resposta única costuma deixar de fora — o tópico 4 transforma isso num prompt.
Observação de quem usa isso todo dia: pedir "seja mais crítico" ou "veja por outros ângulos" quase nunca funciona — é vago demais pro modelo saber quais ângulos. Nomear os papéis explicitamente (próximo tópico) é o que realmente força a cobertura.
Em 1 frase: uma resposta só tem um ponto de vista embutido — pra avaliar ideia, oferta ou produto de verdade, você precisa nomear as lentes que quer ver.
🧭 O prompt do conselho: 5 subagentes, 5 lentes, 1 recomendação
Em vez de pedir uma opinião única, este prompt monta um conselho de 5 subagentes, cada um com uma especialidade fixa, e fecha pedindo consolidação em uma única recomendação com prioridades — o oposto de 5 relatórios soltos sem síntese.
Objetivo: avaliar ideias, ofertas, produtos, projetos ou campanhas por múltiplas lentes especializadas ao mesmo tempo — sem que nenhuma domine as outras por padrão.
Use uma estrutura de subagentes: Agente 1: analisa estratégia e posicionamento. Agente 2: analisa produto e jornada do usuário. Agente 3: analisa conteúdo e comunicação. Agente 4: analisa tecnologia e automação. Agente 5: atua como cético e procura falhas. Depois consolide tudo em uma recomendação única, com prioridades.
Como verificar: use em <isto voce troca> — troque o objeto de análise (ideia, oferta, produto, projeto, campanha) antes de colar. Confirme que a resposta final traz 5 blocos claramente separados por agente e termina numa seção de consolidação com prioridades — não numa lista solta sem hierarquia.
Cruzamento com a Trilha 1
O módulo 1.7 — Bônus: subagents, memória e send_to_user explica, com respaldo oficial da Anthropic, como delegar tecnicamente a subagents (assíncrono, contexto próprio). Este tópico aqui é sobre que estrutura de papéis usar dentro dessa delegação — os dois se completam.
"Claude Fable 5 dispatches parallel subagents more readily than prior models... prefer asynchronous communication between orchestrator and subagents over blocking until each subagent returns."
Tradução: "O Claude Fable 5 despacha subagents em paralelo com mais disposição do que os modelos anteriores... prefira comunicação assíncrona entre orquestrador e subagents em vez de bloquear a espera do retorno de cada um." → ver o módulo 1.7 completo.
5 caixas ciano = os 5 agentes especializados, cada um analisando em paralelo. A caixa azul à direita, com glow, é o ponto que fecha o prompt: consolidação em uma única recomendação.
🤝 As duas dicas juntas: o conselho que traz prova, não só opinião
🧠 Cenário: você está decidindo se lança um novo plano de preços. Pedir só "o que vocês acham?" pros 5 agentes gera 5 opiniões bem escritas — mas ainda são achismos. A dica 5 entra aqui: cada agente do conselho é obrigado a trazer evidência, exatamente como qualquer outra alegação de "pronto".
A dica 6 dá a estrutura (5 lentes, sem ponto cego). A dica 5 dá o rigor (nenhuma lente termina sem prova). Combinadas, viram uma regra só: cada agente do conselho precisa apontar uma evidência concreta antes de opinar — não "acho que o mercado responde bem", e sim o dado que sustenta isso.
Agente Estratégia
Analisa posicionamento vs. concorrência.
Evidência exigida: benchmark de preço/oferta de 3-5 concorrentes diretos, não "acho que está caro".
Agente Produto
Analisa jornada do usuário.
Evidência exigida: dado de churn, NPS ou funil que aponte onde o novo plano ajuda ou atrapalha.
Agente Comunicação
Analisa mensagem de valor.
Evidência exigida: teste A/B, pesquisa ou histórico de campanha — não "essa frase soa melhor".
Agente Tecnologia
Analisa viabilidade e automação.
Evidência exigida: estimativa de esforço e dependências reais do sistema de cobrança/billing.
Agente Cético
Procura falhas de propósito.
Evidência exigida: caso histórico ou cenário de risco onde uma mudança parecida deu errado.
🧾 A consolidação
Só depois que os 5 agentes trouxeram evidência (não opinião solta), o passo final do prompt — "consolide tudo em uma recomendação única, com prioridades" — vira uma síntese confiável. Consolidar 5 achismos ainda produz um achismo bem organizado; consolidar 5 evidências produz uma decisão.
Em 1 frase: se um agente do conselho não trouxer evidência, ele não terminou — é a mesma régua da dica 5, agora aplicada a cada uma das 5 lentes.
⚠️ Erros comuns dessas 2 dicas — e o checklist rápido
Os dois prompts deste módulo falham do mesmo jeito quando aplicados pela metade: vira teatro de rigor, sem mudar o resultado de verdade. Os erros mais comuns:
⚠️ Onde isso quebra na prática
- ✗Aceitar "tudo certo" sem pedir de volta a evidência exata (volta ao ponto cego do tópico 1)
- ✗Pedir só "seja mais crítico" em vez de nomear os 5 papéis explicitamente
- ✗Deixar o Agente Cético de fora "pra não travar o entusiasmo" — sem ele, o conselho vira câmara de eco otimista
- ✗Consolidar sem cobrar evidência de cada agente — 5 opiniões viram 5 achismos bem formatados
- ✗Rodar os 5 agentes mas pular o passo de consolidação — sobram 5 relatórios soltos, sem prioridade
✓ Checklist rápido
- ✓Toda alegação de "pronto" veio com teste, log, diff ou saída de comando?
- ✓Existe "não verificado" explícito onde não deu pra checar?
- ✓O conselho tem os 5 papéis nomeados, cético incluso?
- ✓Cada agente citou uma evidência, não só uma opinião?
- ✓Há uma consolidação final com prioridades — não 5 relatórios soltos?
💡 Combo pronto pra colar
Nas próximas sessões, tente colar os dois prompts deste módulo (tópicos 2 e 4) juntos, no mesmo pedido de análise, e observe se o resultado final tem 5 blocos com evidência + 1 consolidação — não texto solto.
Isso é literalmente o exemplo do tópico 5, aplicado ao seu próprio projeto.
Em 1 frase: verificação e conselho só funcionam completos — pela metade, os dois viram teatro de rigor em vez de rigor de verdade.
🧾 Resumo do Módulo
Próximo módulo:
2.4 — Memória de projeto + continuar até concluir: como transformar decisões em memória persistente e evitar que o Fable 5 pare cedo demais em tarefas longas.