🔄 Mais contexto é melhor? Não com o Fable 5
🧠 Imagine assim: prompt engineering clássico é feito como contrato blindado de advogado — cada cláusula prevendo uma exceção, "sempre faça X", "nunca faça Y", "se acontecer Z então W". Isso protegia contra um modelo que esquecia regras no meio do caminho. Com um modelo que já segue instrução de sobra, o mesmo contrato vira burocracia que ninguém lê até o fim.
A convenção que você provavelmente já aprendeu diz: quanto mais contexto, mais regras explícitas, melhor o resultado. Isso fazia sentido enquanto o seguimento de instruções (instruction following) era inconsistente — enumerar cada comportamento era a única forma de garantir que o modelo não deixasse passar nada importante.
Com o Claude Fable 5 essa premissa muda. O seguimento de instruções ficou forte o bastante pra uma instrução breve e bem escolhida já guiar o comportamento certo, sem precisar listar regra por regra. Enumerar tudo deixou de ser proteção e virou ruído: cada regra extra compete por atenção com as que de fato importam, infla o prompt e pode até puxar o estilo da resposta pro mesmo tom prolixo do próprio prompt.
Legenda: à esquerda, cada regra enumerada disputa atenção e o resultado sai diluído; à direita, uma única instrução breve chega nítida — instruction-following forte não precisa de lista.
⚠️ Não confunda com cortar informação
"Diga menos, não mais" não é sobre remover contexto que muda o resultado — é sobre remover a redundância de regras que o modelo já cumpriria sozinho. Informação de intenção continua tão importante quanto sempre (o tópico 5 detalha por quê).
Em 1 frase: modelos fracos precisavam de lista; o Fable 5 precisa de direção clara — enumerar tudo virou ruído, não proteção.
🎯 Strong instruction following — o prompt oficial
🧠 Imagine assim: é a diferença entre treinar um estagiário novo (que precisa de manual passo a passo) e dar uma diretriz a um sênior (que já sabe preencher os detalhes). O Fable 5 já chegou perto do "sênior" — trate-o assim.
A doc oficial "Prompting Claude Fable 5" é direta sobre isso: o seguimento de instruções melhorou o suficiente pra você guiar a maioria dos comportamentos com uma instrução breve, em vez de enumerar cada comportamento pelo nome. É mudança de estratégia, não só de estilo de escrita.
Instruction-following is improved enough that you can steer most behaviors with a brief instruction rather than enumerating each behavior by name.
O seguimento de instruções melhorou o bastante pra você guiar a maioria dos comportamentos com uma instrução breve, em vez de enumerar cada comportamento pelo nome.
Na prática: se seu system prompt tem uma lista de 15 bullets tentando cobrir todo comportamento possível ("sempre faça X", "nunca faça Y", "em caso Z faça W"...), o Fable 5 provavelmente já responde bem a uma frase que capture a intenção central. Teste removendo metade da lista antes de considerar adicionar mais uma regra.
✓ O que FAZER
- ✓Escrever 1-2 frases que capturam a intenção e o resultado esperado.
- ✓Confiar que comportamentos padrão (formatação, tom, cuidado com edge cases óbvios) já vêm embutidos.
- ✓Adicionar uma regra nova só quando o comportamento padrão realmente falhar num teste real.
✗ O que NÃO fazer
- ✗Copiar e colar a mesma lista de 20 regras que você usava pra modelos mais antigos.
- ✗Repetir a mesma instrução de formas diferentes "só pra garantir".
- ✗Tratar cada exceção hipotética como se precisasse virar regra permanente.
Em 1 frase: uma instrução breve e bem mirada substitui a lista — o modelo já segue instrução de sobra.
✂️ Lead with the outcome — legível ≠ conciso
🧠 Imagine assim: pense numa manchete de jornal. Ela não é curta porque as palavras foram cortadas ao meio — é curta porque alguém decidiu, com cuidado, o que realmente importa contar primeiro.
A doc oficial também dá a receita pra saída final: comece pelo resultado ("lead with the outcome"). A primeira frase depois de terminar deve responder "o que aconteceu" ou "o que você encontrou" — o que o usuário pediria se dissesse "só me dá o resumo". Detalhe e raciocínio vêm depois.
Objetivo: fazer o agente abrir qualquer resposta longa pelo resultado, e só depois justificar — sem comprimir a saída em fragmentos ilegíveis.
Lead with the outcome. Your first sentence after finishing should answer "what happened" or "what did you find": the thing the user would ask for if they said "just give me the TLDR." Supporting detail and reasoning come after. Being readable and being concise are different things, and readability matters more. The way to keep output short is to be selective about what you include (drop details that don't change what the reader would do next), not to compress the writing into fragments, abbreviations...
Comece pelo resultado. Sua primeira frase depois de terminar deve responder "o que aconteceu" ou "o que você encontrou": a coisa que o usuário pediria se dissesse "só me dá o resumão". O detalhe de apoio e o raciocínio vêm depois. Ser legível e ser conciso são coisas diferentes, e legibilidade importa mais. A forma de manter a saída curta é ser seletivo sobre o que incluir (cortar detalhes que não mudam o que o leitor faria a seguir), não comprimir o texto em fragmentos, abreviações…
Como verificar: cole isso no fim do seu CLAUDE.md ou system prompt e observe a próxima resposta longa. A primeira frase já deveria contar o resultado — sem "deixa eu explicar o que fiz primeiro" antes de chegar lá.
🔍 Distinção-chave: legível ≠ conciso
- Legibilidade — o leitor entende de primeira, sem precisar decodificar. Importa mais.
- Brevidade — menos palavras. Só importa quando não custa legibilidade.
- Manter curto é sobre seletividade (o que você deixa de fora), não sobre compressão (como você escreve o que ficou).
✓ Conciso bem-feito
- ✓Corta o parágrafo que não muda a próxima ação do leitor.
- ✓Escreve frases completas, mesmo que curtas.
- ✓Nomeia arquivos/números por extenso na primeira menção.
✗ Conciso mal-feito
- ✗Comprime em fragmentos tipo "ok, feito, prox".
- ✗Abrevia tudo até virar telegrama.
- ✗Corta o resultado principal achando que "menos é sempre melhor".
Em 1 frase: conciso é sobre o que você deixa de fora, não sobre como você escreve o que ficou.
🔀 Terse entre tool calls vs. resumo final (re-grounding)
🧠 Imagine assim: um cirurgião pode falar em jargão técnico curto durante a operação, pra equipe que está ali. Mas o relatório que ele entrega à família no fim precisa reexplicar tudo do zero, em português claro — quem recebe não estava na sala.
Durante o trabalho — entre uma chamada de ferramenta e outra — taquigrafia curta é ótima. É você "pensando em voz alta", ninguém está lendo aquilo em tempo real, e brevidade ali economiza tempo e tokens sem custo real de clareza.
Legenda: taquigrafia entre tool calls é ok pra você pensar em voz alta; mas a mensagem final precisa reancorar quem não viu o processo — resultado primeiro, cada identificador explicado como se fosse novo.
Você inicia a tarefa e se ausenta
Overnight, ou uma sessão longa em que você não está lendo cada passo do agente.
Entre chamadas de ferramenta: taquigrafia terse
Bom sinal — é o agente pensando em voz alta, e brevidade ali não custa nada porque ninguém está lendo em tempo real.
Sessão longa, muitas idas e vindas
Jargão interno acumula: nomes de flag, siglas de PR, atalhos que só fazem sentido pra quem acompanhou tudo.
Mensagem final: troca de modo
De "continuação da linha de raciocínio" pra "re-grounding" — outcome primeiro, cada identificador (arquivo, commit, flag) explicado como se fosse a primeira vez que o leitor ouve falar dele.
Objetivo: fazer o agente trocar de "modo telegráfico" pro "modo re-grounding" na hora de fechar uma sessão longa sem supervisão.
Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity there is good). Your final summary is different: it's for a reader who didn't see any of that. If you've been working for a while without the user watching (overnight, across many tool calls, since they last spoke), your final message is their first look at any of it. Write it as a re-grounding, not a continuation of your working thread: the outcome first, then the one or two things you need from them, each explained as if new. When you mention files, commits, flags, or other identifiers, give each one its own plain-language clause. Open with the outcome: one sentence on what happened or what you found. Then the supporting detail. If you have to choose between short and clear, choose clear.
Ser telegráfico entre chamadas de ferramenta tudo bem — isso é você pensando em voz alta, e brevidade ali é bom. Seu resumo final é diferente: é para um leitor que não viu nada daquilo. Se você trabalhou por um tempo sem o usuário observando (da noite pro dia, ao longo de várias chamadas de ferramenta, desde a última vez que ele falou), sua mensagem final é o primeiro contato dele com tudo isso. Escreva-a como um re-grounding (reancoragem), não como continuação da sua linha de raciocínio: o resultado primeiro, depois uma ou duas coisas que você precisa dele, cada uma explicada como se fosse nova. Ao mencionar arquivos, commits, flags ou outros identificadores, dê a cada um sua própria frase em linguagem simples. Abra com o resultado: uma frase sobre o que aconteceu ou o que você encontrou. Depois o detalhe de apoio. Se tiver que escolher entre curto e claro, escolha claro.
Como verificar: cole isso nas instruções do seu agente (system prompt/skill) e, na próxima sessão longa e assíncrona, releia a mensagem final sozinho: dá pra entender o resultado sem ter visto nenhuma chamada de ferramenta? Se sim, funcionou.
Em 1 frase: terse enquanto ninguém vê; re-grounding quando alguém finalmente vai ler.
⚖️ Isso não contradiz "dê o porquê" (módulo 1.2)
🧠 Imagine assim: um bom briefing de design tem 1 frase de propósito ("isso é pra convencer investidor cético") e zero páginas de regras de pixel. Intenção rica e poucas regras enumeradas sempre conviveram bem — só pareciam a mesma coisa porque prompts antigos costumavam empilhar os dois.
O módulo 1.2 (dê o porquê) pede pra você explicar a intenção por trás do pedido. Este módulo (1.5) pede pra você não enumerar regra por regra. À primeira vista parece contraditório — mais um lado, menos outro — mas são dois eixos diferentes, não a mesma régua.
⚖️ Dois eixos independentes
Intenção (o porquê) mede a qualidade do contexto — o que você quer e por que quer. Verbosidade (quantas regras) mede volume — quantos itens você enumera. Dá pra ter os dois: uma frase densa de intenção, zero lista de regras.
- •Eixo 1 (intenção): "porque este endpoint é usado por 3 serviços críticos" — 1 frase, alto valor.
- •Eixo 2 (verbosidade): "sempre faça X, nunca faça Y, em caso Z faça W..." — quanto mais itens, mais ruído.
- •"Diga menos" mira o eixo 2 pra baixo. "Dê o porquê" mira o eixo 1 pra cima. Eles não competem pelo mesmo espaço.
Legenda: "diga menos" mexe no eixo horizontal (menos regras enumeradas); "dê o porquê" mexe no eixo vertical (mais contexto de intenção). São eixos independentes — dá pra ter os dois ao mesmo tempo.
Na prática, um prompt "ideal" pro Fable 5 fica no canto superior esquerdo do diagrama acima: 1-2 frases de intenção genuína, sem a lista de regras que ele já cumpriria sozinho. Se você está em dúvida sobre onde cortar, revise primeiro o módulo 1.2 — a pergunta certa não é "tenho contexto demais?", é "esse contexto é intenção ou é regra redundante?".
Relacionado→ Revisite o módulo 1.2 — Dê o porquê + não peça raciocínio
Em 1 frase: intenção rica + poucas regras enumeradas não é contradição — é a combinação ideal.
🛠️ Na prática: refatorando CLAUDE.md e skills antigas
🧠 Imagine assim: CLAUDE.md e skills escritas pra modelos antigos são como manuais de instrução traduzidos de um aparelho antigo — cheios de avisos que já não se aplicam ao modelo novo, mas continuam lá, ocupando espaço e competindo por atenção.
A doc oficial dá um alvo concreto pra aplicar tudo isso: seu CLAUDE.md, system prompts e skills antigas escritas pensando em modelos anteriores. Se elas enumeram comportamento por comportamento, é provável que estejam competindo com o próprio julgamento do Fable 5 em vez de ajudá-lo.
Fonte oficial · doc "Prompting Claude Fable 5"
"Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. Review and consider removing older instructions if default performance is better."
PT-BR: "Skills desenvolvidas pra modelos anteriores costumam ser prescritivas demais pro Claude Fable 5 e podem piorar a qualidade da saída. Revise e considere remover instruções antigas se a performance padrão já for melhor."
Isso vale especialmente pra skills e system prompts herdados de projetos com modelos mais antigos: releia com olho crítico e teste se remover metade das regras muda o resultado. Se não muda, a regra já não fazia diferença — só inflava o prompt e disputava atenção com o que de fato importa.
Objetivo: pedir ao próprio Claude Code pra auditar seu CLAUDE.md/system prompt atual e sinalizar o que provavelmente é enumeração redundante pro Fable 5.
Releia o CLAUDE.md (ou system prompt) deste projeto <cole o conteúdo ou aponte o arquivo>. Aponte quais instruções são regras enumeradas que um modelo com strong instruction-following como o Fable 5 provavelmente já seguiria por padrão, e proponha uma versão mais curta que mantenha só o que muda o comportamento de fato. Não remova nada relacionado a intenção, contexto de negócio ou fronteiras de segurança — só o que é enumeração redundante.
Como verificar: rode as duas versões (original vs. enxuta) na mesma tarefa real e compare a saída. Se o comportamento não mudou, a versão enxuta é estritamente melhor (menos tokens, menos ruído). Se algo importante sumiu, foi cortado contexto de intenção por engano — devolva pro prompt.
⚠️ Atenção
Não apague tudo de uma vez. Corte um bloco de regras por vez e rode a mesma tarefa antes/depois. Regra que existe por causa de um incidente real (segurança, dado sensível, integração frágil) fica — o alvo é a regra que só existia "por garantia".
📎 Indo mais fundo (opcional): sinais de que uma skill está prescritiva demais
- •Lista com mais de 10 "sempre/nunca" sem nenhuma frase de contexto explicando o porquê.
- •Instruções redundantes com o bom senso padrão do modelo (formatação óbvia, tom educado, não inventar fatos).
- •Regras que tentam prevenir um cenário hipotético que nunca aconteceu de verdade no projeto.
- •Instruções de "mostre seu raciocínio" ou "explique passo a passo antes de responder" — o módulo 1.3 já mostrou que isso pode disparar a categoria de recusa
reasoning_extractionno Fable 5.
Em 1 frase: releia CLAUDE.md e skills antigas com a régua do Fable 5 — se a regra não muda o resultado, ela é ruído, corte.
🧾 Resumo do Módulo
Próximo módulo:
1.6 — Esforço e roteamento de segurança: effort levels (max/xhigh/high/medium/low) e as 4 categorias de recusa.