De onde vêm essas dicas: este módulo (e toda a Trilha 2) vem de um guia prático de uso do Fable 5 como agente de trabalho — não é citação verbatim da documentação da Anthropic. Os prompts aqui são testados na prática, não "oficiais". A exceção é quando uma dica cruza diretamente com uma técnica já verificada na Trilha 1 (emerald) — aí você vai ver uma nota com o link e a citação oficial correspondente.
Dica 7 — o uso mais forte não é o prompt, é a memória
Imagine assim: todo funcionário novo passa pelo mesmo problema no primeiro dia — ninguém contou pra ele o que já foi tentado, o que já foi decidido e o que já deu errado antes. Sem uma memória de projeto, toda sessão nova do Fable 5 é o primeiro dia de trabalho de novo.
O prompt perfeito, isolado, tem um limite claro: ele só vale pra sessão em que foi digitado. Assim que a conversa acaba, tudo que o Fable 5 "aprendeu" sobre o seu projeto — seu público, seu tom de voz, os erros que já cometeu, as decisões que você já confirmou — desaparece com ela. O uso mais forte do Fable 5 não é escrever o prompt perfeito, é dar a ele memória contínua do projeto.
Sem memória, o padrão que se repete é sempre o mesmo: você reexplica o mesmo contexto toda sessão, o modelo repete um erro que já foi corrigido semana passada, e uma decisão que já foi tomada volta a ser debatida do zero. Memória de projeto quebra esse ciclo — a sessão de hoje lê o que a sessão de ontem aprendeu, antes de agir.
Quem grava a lição não é quem lê. A sessão futura só evita repetir o erro se a nota existir, for específica e ainda estiver correta — por isso ela pode ser atualizada ou apagada.
A estrutura mais simples que funciona na prática é uma pasta com um arquivo por assunto, cada um curto o bastante pra ser lido em segundos:
/memoria-projeto/ posicionamento.md (quem somos, o que oferecemos, contra quem competimos) publico-alvo.md (pra quem é, o que essa pessoa já sabe/já tentou) ofertas.md (o que existe hoje, preço, formato) tom-de-voz.md (como escrevemos, o que evitamos dizer) erros-a-evitar.md (o que já deu errado e por quê) decisoes-confirmadas.md (o que já foi decidido — não reabrir sem motivo novo) prompts-validados.md (prompts que já funcionaram, prontos pra reusar)
Em 1 frase: o prompt perfeito vale por uma sessão; a memória de projeto vale por todas as sessões seguintes.
Dica 7 — o prompt: registrar aprendizado em memória
Ter a pasta /memoria-projeto/ criada não basta — o Fable 5 precisa saber que deve escrever nela sozinho, sem você pedir toda vez. Cole este prompt no CLAUDE.md ou no system prompt do projeto uma única vez.
Objetivo: transformar qualquer lição aprendida durante o trabalho — uma correção, uma decisão confirmada, um erro identificado — numa nota curta e padronizada, sem esperar você pedir.
Sempre que aprendermos algo importante sobre este projeto, registre em memória. Formato: - decisão ou lição; - por que importa; - onde aplicar; - o que evitar; - data. Não duplique informação. Atualize a nota existente quando necessário.
Como verificar: trabalhe algumas sessões de verdade e confira a pasta /memoria-projeto/: cada lição virou uma nota com decisão, motivo, onde aplicar, o que evitar e data — sem duplicar o que já estava lá, e com notas antigas atualizadas em vez de repetidas.
🔗 Cruzamento com a Trilha 1 (oficial)
Esta dica ecoa diretamente o sistema de memória em arquivo do módulo 1.7 da Trilha 1, que tem respaldo oficial da documentação "Prompting Claude Fable 5":
EN: "Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike, including why they mattered. Don't save what the repo or chat history already records; update an existing note rather than creating a duplicate; delete notes that turn out to be wrong."
"PT-BR: Guarde uma lição por arquivo, com um resumo de uma linha no topo. Registre tanto correções quanto abordagens confirmadas, incluindo por que elas importaram. Não salve o que o repositório ou o histórico de conversas já registra; atualize uma nota existente em vez de criar uma duplicata; apague notas que se mostrarem erradas."
💡 Dica prática
Não duplique o que já está no repositório, no código ou no histórico do chat. Memória extra que só repete o que já está registrado em outro lugar vira ruído — e ruído desatualizado é pior que memória nenhuma.
Em 1 frase: decisão + motivo + onde aplicar + o que evitar + data — cole esse formato uma vez e o Fable 5 registra sozinho daí em diante.
Dica 8 — o problema: parar cedo ou terminar com promessa
Imagine assim: você pede pra alguém revisar um relatório de 40 páginas e a resposta é "dei uma olhada geral, parece bom, se quiser eu continuo depois". Tecnicamente ele respondeu. Na prática, você não tem nada em mãos — só uma promessa de que o trabalho vai existir.
Em tarefas longas, o Fable 5 já tem informação suficiente pra terminar boa parte das vezes — e mesmo assim pode parar cedo demais: pedir confirmação genérica ("quer que eu continue?"), devolver um plano em vez do trabalho feito, ou encerrar o turno com uma frase de intenção ("vou fazer X agora") sem ter feito X de verdade.
O custo disso é maior do que parece. Numa conversa você percebe e manda "continue" — mas em automação, pipeline agendado ou revisão que ninguém está acompanhando em tempo real, um turno que termina em promessa fica sem correção por horas, e o "quase pronto" nunca vira "pronto".
✗ Termina em promessa
— pergunta genérica, nada entregue —
Parece progresso educado, mas não há entregável nem decisão registrada.
✓ Termina com resultado
— trabalho completo, verificável —
Você recebe algo pra usar agora, não uma promessa de continuar depois.
⚠️ Atenção
Parar cedo não é sempre errado — às vezes a pausa é exatamente o certo (ver módulo 2.2, sobre limites). O problema é parar cedo sem motivo, quando a informação pra terminar já estava disponível. A Dica 8 é sobre eliminar essa pausa desnecessária, não sobre eliminar toda pausa.
Em 1 frase: um turno que termina em plano, pergunta genérica ou promessa não é progresso — é um "quase" que só vira "pronto" se alguém mandar continuar.
Dica 8 — o prompt: continue até concluir
O antídoto é o mesmo princípio da fronteira clara: em vez de pedir "seja mais decidido" (vago demais pra agir sobre), diga exatamente quando parar é permitido — e deixe tudo o mais virar execução.
Objetivo: eliminar a pausa desnecessária em tarefas longas — código, documentação, planejamento, criação de conteúdo — reservando o "parar" só pro que exige mesmo uma pessoa.
Se você já tiver informação suficiente, execute. Não termine com promessa, plano ou pergunta genérica. Só pare se precisar de uma informação que apenas eu posso fornecer ou se a ação for destrutiva ou irreversível.
Como verificar: cole no CLAUDE.md ou no system prompt e observe as próximas tarefas longas: o Fable 5 deve entregar resultado real (arquivo, texto pronto, plano executado) em vez de perguntar "posso continuar?" no meio — e só deve parar quando bater numa das duas exceções listadas.
🔗 Cruzamento com a Trilha 1 (oficial)
Esta dica é a versão aplicada do prompt anti-overplanning oficial do módulo 1.4 da Trilha 1, testado e documentado pela Anthropic:
EN: "Pause for the user only when the work genuinely requires them: a destructive or irreversible action, a real scope change, or input that only they can provide. If you hit one of these, ask and end the turn, rather than ending on a promise."
PT-BR: "Pause para o usuário só quando o trabalho realmente exigir isso: uma ação destrutiva ou irreversível, uma mudança real de escopo, ou uma informação que só ele pode fornecer. Se você encontrar um desses casos, pergunte e encerre o turno — em vez de terminar numa promessa."
💡 Dica prática
Funciona especialmente bem em código, documentação, planejamento e criação de conteúdo — tarefas onde "quase pronto" costuma virar desculpa pra parar. Se o seu caso é destrutivo ou irreversível de verdade (deploy, deleção, envio pra terceiros), use os limites do módulo 2.2 em vez desta dica.
Em 1 frase: informação suficiente = execute; só pare pro que é destrutivo, irreversível, ou só você sabe.
Como as duas dicas se combinam na prática
Sozinhas, as duas dicas já ajudam. Combinadas, elas fecham um ciclo: um agente que executa até o fim (Dica 8) e, ao terminar, registra o que aprendeu na memória do projeto (Dica 7) — pronto pra sessão seguinte já começar sabendo o que esta descobriu.
Recebe a tarefa com contexto
A sessão começa lendo /memoria-projeto/ — já sabe decisões confirmadas, erros a evitar e o tom de voz, sem você repetir nada.
Executa até concluir
Com informação suficiente, ele age — sem parar pra perguntar "posso continuar?" no meio. Só pausa se a ação for destrutiva/irreversível ou depender só de você.
Entrega com evidência real
O turno termina num resultado auditável (arquivo, texto, plano executado) — não numa promessa. Ver módulo 1.4 da Trilha 1 e módulo 2.3 desta trilha sobre verificação real.
Registra o aprendizado
Antes de encerrar, grava em memória o que mudou: decisão, motivo, onde aplicar, o que evitar, data. A próxima sessão já nasce sabendo.
Na prática, os dois prompts das Dicas 7 e 8 podem conviver no mesmo CLAUDE.md — um cuida do "não pare cedo", o outro cuida do "não esqueça o que aprendeu". Um exemplo combinado, pronto pra colar:
Objetivo: um único bloco que junta as duas dicas — execução até o fim e registro automático de memória — pra colar uma vez e valer pro projeto inteiro.
Se você já tiver informação suficiente, execute. Não termine com promessa, plano ou pergunta genérica. Só pare se precisar de uma informação que apenas eu posso fornecer ou se a ação for destrutiva ou irreversível. Ao concluir uma tarefa, se aprendemos algo importante sobre o projeto no caminho, registre em memória: decisão ou lição, por que importa, onde aplicar, o que evitar, data. Não duplique informação já registrada — atualize a nota existente quando necessário.
Como verificar: rode uma tarefa longa de ponta a ponta e confira duas coisas ao final: (1) o turno terminou com resultado real, não com promessa; (2) a pasta /memoria-projeto/ tem uma nota nova ou atualizada refletindo o que foi aprendido.
Em 1 frase: execute até o fim, entregue evidência, registre a lição — cada sessão deixa o projeto um pouco mais fácil pra próxima.
Erros comuns e checklist rápido
Os erros mais comuns nessas duas dicas não são de conceito — são de disciplina: criar a pasta de memória e nunca instruir o modelo a escrever nela, ou pedir "continue até concluir" mas sem nunca definir as exceções que justificam parar.
✗ O que EVITAR
- ✗Criar
/memoria-projeto/mas nunca instruir o modelo a escrever nela sozinho - ✗Deixar as notas crescerem sem revisão — memória desatualizada é pior que memória nenhuma
- ✗Duplicar em memória o que já está no repositório ou no histórico do chat
- ✗Mandar "continue até concluir" sem nunca dizer quais exceções justificam parar
- ✗Tratar toda ação como "destrutiva por precaução" — isso recria o overplanning que a Dica 8 resolve
✓ O que FAZER
- ✓Colar o prompt de registro de memória (tópico 2) uma única vez no CLAUDE.md
- ✓Revisar
/memoria-projeto/de vez em quando — atualizar ou apagar o que ficou errado - ✓Colar o prompt "continue até concluir" (tópico 4) junto das duas exceções claras
- ✓Combinar os dois prompts (tópico 5) em tarefas longas que geram aprendizado
- ✓Exigir evidência real do que foi feito antes de aceitar como "concluído" (módulo 2.3)
CHECKLIST — Memória de projeto + continuar até concluir (módulo 2.4) [Dica 7] Crie /memoria-projeto/ com 1 arquivo por assunto (posicionamento, público, tom...) [Dica 7] Cole o prompt de registro: decisão + motivo + onde aplicar + o que evitar + data [Dica 7] Atualize a nota existente, nunca duplique; apague o que ficou errado [Dica 8] Cole o prompt "execute se já tem informação suficiente, não termine em promessa" [Dica 8] As únicas exceções pra parar: ação destrutiva/irreversível ou dado só seu [Combo] Ao concluir uma tarefa longa, execute até o fim E registre a lição na memória
Em 1 frase: memória sem instrução de escrita fica vazia; "continue até concluir" sem exceção vira imprudência — as duas dicas só funcionam com a regra explícita colada no prompt.
🎓 Resumo do Módulo
Próximo módulo:
2.5 — Visão pra interfaces + segurança defensiva