Where these tips come from: this module (and all of Track 2) comes from a practical guide to using Fable 5 as a work agent — it's not a verbatim quote from Anthropic's documentation. The prompts here are tested in practice, not “official.” The exception is when a tip directly overlaps with a technique already verified in Track 1 (emerald)—then you’ll see a note with the link and corresponding official citation.
Tip 7 — the most powerful use isn’t the prompt, it’s the memory
Imagine it this way: every new employee faces the same problem on their first day—no one told them what’s already been tried, what’s already been decided, and what’s already gone wrong. Without a project memory, every new Fable 5 session is day one on the job all over again.
The perfect prompt, on its own, has a clear limit: it only applies to the session where you typed it. As soon as the conversation ends, everything Fable 5 “learned” about your project—your audience, your voice, the mistakes it has already made, the decisions you’ve already confirmed—disappears with it. The strongest use of Fable 5 isn’t writing the perfect prompt; it’s giving it continuous project memory.
Without memory, the same pattern keeps repeating: you re-explain the same context every session, the model repeats a mistake that was fixed last week, and a decision that was already made gets debated from scratch. Project memory breaks this cycle—the session today reads what yesterday’s session learned, before to act.
The person who records the lesson isn't the person who reads it. A future session can avoid repeating the mistake only if the note exists, is specific, and is still accurate—which is why it can be updated or deleted.
The simplest structure that works in practice is a folder with one file per topic, each short enough to read in seconds:
/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)
In one sentence: The perfect prompt is useful for one session; project memory is useful for every session after that.
Tip 7 — the prompt: record learning in memory
Having the folder /memoria-projeto/ creating it isn’t enough — Fable 5 needs to know that it should write it on its own, without you having to ask every time. Paste this prompt into CLAUDE.md or the project’s system prompt just once.
Goal: turn any lesson learned during the work—a correction, a confirmed decision, an identified error—into a short, standardized note without waiting for you to ask.
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.
How to check: work through a few real sessions and check the folder /memoria-projeto/: each lesson became a note with a decision, reason, where to apply it, what to avoid, and date—without duplicating what was already there, and with old notes updated instead of repeated.
🔗 Cross-reference with Track 1 (official)
This tip directly echoes the file-based memory system of module 1.7 of Track 1, which is backed by the “Prompting Claude Fable 5” documentation:
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: Keep one lesson per file, with a one-line summary at the top. Record both corrections and confirmed approaches, including why they mattered. Don’t save what the repository or conversation history already records; update an existing note instead of creating a duplicate; delete notes that turn out to be wrong.
💡 Practical tip
Don’t duplicate what’s already in the repository, code or chat history. Extra memory that only repeats what’s already recorded elsewhere becomes noise—and outdated noise is worse than no memory at all.
In one sentence: decision + reason + where to apply it + what to avoid + date — paste this format once and Fable 5 will record it automatically from then on.
Tip 8 — the problem: stopping early or ending with a promise
Imagine it this way: you ask someone to review a 40-page report, and the answer is "I gave it a quick look, it seems good, I can keep going later if you want." Technically, they responded. In practice, you have nothing in hand—just a promise that the work will exist.
For long tasks, Fable 5 already has enough information to finish most of the time — and still may stop too early: asking for generic confirmation (“should I continue?”), returning a plan instead of completed work, or ending the turn with a statement of intent (“I’ll do X now”) without actually doing X.
The cost is greater than it seems. In a conversation, you notice and say “continue” — but in automation, a scheduled pipeline, or a review nobody is monitoring in real time, a turn that ends with a promise is without correction for hours, and “almost done” never becomes “done.”
✗ Ends with a promise
— generic question, nothing delivered —
It looks like polite progress, but there’s no deliverable or recorded decision.
✓ Ends with a result
— complete, verifiable work —
You get something to use now, not a promise to continue later.
⚠️ Attention
Stopping early isn’t always wrong—sometimes pausing is exactly the right thing to do (see module 2.2, on limits). The problem is stopping early without a reason, when the information needed to finish was already available. Tip 8 is about eliminating that unnecessary pause, not eliminating every pause.
In one sentence: a turn that ends with a plan, a generic question, or a promise isn’t progress—it’s an “almost” that only becomes “done” if someone says to continue.
Tip 8 — the prompt: continue until complete
The antidote is the same clear-boundary principle: instead of asking it to “be more decisive” (too vague to act on), say exactly when it’s okay to stop — and make everything else execution.
Goal: eliminate unnecessary pauses in long tasks—code, documentation, planning, content creation—reserving “stop” only for what truly requires a person.
If you already have enough information, execute. Don’t end with a promise, plan, or generic question. Stop only if you need information that only I can provide or if the action is destructive or irreversible.
How to check: paste this into the CLAUDE.md or system prompt and watch the next long tasks: Fable 5 should deliver a real result (file, ready-to-use text, executed plan) instead of asking “can I continue?” midway—and should only stop when it hits one of the two listed exceptions.
🔗 Cross-reference with Track 1 (official)
This tip is the applied version of the official anti-overplanning prompt from module 1.4 of Track 1, tested and documented by 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 for the user only when the work truly requires it: a destructive or irreversible action, a real scope change, or information only they can provide. If you encounter one of these cases, ask and end the turn — instead of ending with a promise."
💡 Practical tip
Works especially well for code, documentation, planning, and content creation — tasks where “almost done” often becomes an excuse to stop. If your case is truly destructive or irreversible (deploy, deletion, sending to others), use the limits in module 2.2 instead of this tip.
In one sentence: enough information = proceed; stop only for something destructive, irreversible, or known only to you.
How the two tips work together in practice
On their own, the two tips already help. Combined, they complete a cycle: an agent that executes to the end (Tip 8) and, when you're done, records what it learned in the project memory (Tip 7) — ready for the next session to start with what this one learned.
Receives the task with context
The session starts by reading /memoria-projeto/ — it already knows confirmed decisions, mistakes to avoid, and the tone of voice, without you having to repeat anything.
Execute until complete
When it has enough information, it acts—without stopping to ask "can I continue?" midway through. It pauses only if the action is destructive or irreversible, or depends solely on you.
Delivery backed by real evidence
The turn ends with an auditable result (file, text, executed plan)—not a promise. See module 1.4 of Track 1 and module 2.3 of this track on real verification.
Records what was learned
Before wrapping up, record what changed in memory: decision, reason, where to apply it, what to avoid, date. The next session starts with that knowledge.
In practice, the two prompts from Tips 7 and 8 can coexist in the same CLAUDE.md—one handles “don’t stop early,” and the other handles “don’t forget what you learned.” Here’s a combined example, ready to paste:
Goal: a single block that combines both tips—execution through completion and automatic memory logging—so you can paste it once and use it across the entire project.
If you already have enough information, execute. Don’t end with a promise, plan, or generic question. Stop only if you need information that only I can provide or if the action is destructive or irreversible. When you finish a task, if we learned something important about the project along the way, record it in memory: decision or lesson, why it matters, where to apply it, what to avoid, date. Don’t duplicate information already recorded—update the existing note when needed.
How to check: run a long task from start to finish and check two things at the end: (1) the turn ended with a real result, not a promise; (2) the folder /memoria-projeto/ there’s a new or updated note reflecting what was learned.
In one sentence: execute to the end, provide evidence, record the lesson — each session makes the project a little easier next time.
Common mistakes and quick checklist
The most common mistakes with these two tips aren’t conceptual—they’re about discipline: creating the memory folder but never instructing the model to write to it, or asking it to "continue until complete" without ever defining the exceptions that justify stopping.
✗ What to AVOID
- ✗Create
/memoria-projeto/but never instruct the model to write in it on its own - ✗Letting notes grow without review—outdated memory is worse than no memory
- ✗Duplicating in memory what’s already in the repository or chat history
- ✗Saying "continue until complete" without ever specifying which exceptions justify stopping
- ✗Treating every action as "destructive, just to be safe"—this recreates the overplanning that Tip 8 addresses
✓ What to DO
- ✓Paste the memory logging prompt (topic 2) into CLAUDE.md just once
- ✓Review
/memoria-projeto/from time to time — update or delete what turned out to be wrong - ✓Paste the prompt "continue until complete" (topic 4) along with the two clear exceptions
- ✓Combine the two prompts (topic 5) for long tasks that generate learning
- ✓Require real evidence of what was done before accepting it as “complete” (module 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
In one sentence: memory without writing instructions stays empty; “continue until complete” with no exceptions becomes reckless—the two tips only work with the explicit rule included in the prompt.
🎓 Module Summary
Next module:
2.5 — Vision for interfaces + defensive security