The principle
Fable 5.1 follows instructions well enough that one short sentence steers better than ten behavior rules. So what you leave out counts as much as what you add. A prompt with parts that do not fit the task is a worse prompt.
This way of working builds on Anthropic's public prompting guide for Fable 5.1. The intake, the skeleton and the choice of modules are what I made of it in my own work.
Step 1: the intake
Five fields. Only the first is mandatory.
- Outcome: what has to exist at the end?
- For whom and why: who uses it, and what do they need to be able to do with it?
- Sources: files, data, accounts, earlier decisions.
- Limits: what must never happen?
- Mode: are you in the chat, or does it run alone?
Mode weighs most. A prompt for a task that runs alone overnight looks different from a prompt for a conversation. What you do not know, you fill in as an assumption and mark as one, so you can check it afterwards.
Step 2: the effort
| Task type |
Effort |
| Mechanical: extraction, formatting, inventory |
low, and first check whether a smaller model will do |
| Standard: content, audit, research, code with a clear spec |
medium or high |
| Complex, ambiguous, multi-day, strategy |
high |
| One long deliverable |
high, not max |
That last one surprises people. On the highest setting the model tends to write a long document out in full in its reasoning first, and then once more as the answer.
Step 3: the skeleton
# Goal
[Outcome in one or two sentences.] This is for [who], who will use it to [what they do with it].
# Context
- [sources with paths, numbers, dates]
- [what has been decided and is not up for discussion again]
# Task
[What exactly gets made: deliverable, format, where it ends up.]
# Scope
In: [...]
Out: [...]
# Limits
[When to stop and ask. What never to do.]
# Done means
- [testable criteria]
- [how to verify]
# Delivery
[Shape of the final message or file.]
Seven writing rules
- The reason is always in there. The model performs clearly better when it knows what the work is for.
- Concrete. Names, paths, numbers, dates. No "professional" or "thorough" without a criterion.
- Scope has at least one "Out". Fable sometimes does more than asked.
- Done is testable. On long runs, have a separate agent with fresh context do the check. That works better than self-critique.
- Say what should happen, not only what is forbidden.
- No shouting. No capitals, no "CRITICAL". Over-emphasis makes the model rigid.
- No thinking script. Give the goal and the criteria, not the thinking steps.
In an existing prompt, check three things first: is the reason missing, is "done" testable, and is there an instruction to show or explain the reasoning? According to Anthropic's guide, that last one can even trigger a refusal with Fable.
Twelve modules
A module is a ready-made block of text you paste at the bottom of the prompt. You only take what fits.
| Module |
When |
| A Autonomous |
The task runs without you. Always together with your exceptions. |
| B Scope and tests |
Code, or an open feature request |
| C Targeted edits |
Changing existing files |
| D Parallel fetching |
Agent loops with many tool calls |
| E Progress and final message |
Long tasks, and every report after an autonomous run |
| F Writing |
Content, emails, reports |
| G Summarizing sources |
Articles, videos, transcripts |
| H Search first |
Current facts, tools, platform changes |
| I Long output |
Only through the API, on the highest effort |
| J Subagents |
Broad work that can run in parallel |
| K Live accounts |
Mandatory as soon as the task touches an ad account, CRM, shop or production system |
| L Formatting |
When the output needs tables or lists |
Module K matters most for anyone working with real accounts. This is the autonomous variant:
This task touches live accounts. Reading, measuring and analyzing is allowed. You make no changes: no budgets, statuses, ads, targeting, negatives, bidding, tags or flows, and no tasks or records in a CRM. Put every proposed change in your report with the calculation behind it, so that I can decide. Never pause anything yourself. Send nothing, not even an email or a message: you deliver drafts as text.
An agent that runs alone overnight and is allowed to change a budget is a risk you do not solve with a well-written sentence. Reading and proposing: yes. Changing: only with your approval, per action.
Check before you use the prompt
- Is the reason in there?
- Is "done" testable, and does it say how it gets checked?
- Is there at least one "Out"?
- No instruction to show or explain the reasoning
- No anti-formatting rules, unless you really want them. Rather say when formatting is welcome.
- Autonomous and a live account together: are module A and K both in?
- Can it be shorter? Cut every sentence that does not change the result.
The skill
The skill runs the intake, picks the effort, builds the skeleton, adds the modules that fit and walks through the check. You get one copyable prompt, the chosen effort with the reason, and the assumptions to check. It never runs the prompt itself. It also converts an existing prompt that was written for an older model.
Download the Fable prompt skill (zip)
In Claude Code, copy the folder to ~/.claude/skills/. In the Claude app, upload the zip in the skills settings. The README in the zip covers both. All twelve module texts are included, in English and Dutch. No skill needed? The skeleton and the rules above work with copy and paste too.
Shelf life
Models change. This guide was written for Fable 5.1, based on Anthropic's guide as I read it in September 2026. When a new model appears, reread that guide first and adjust the effort table and the checklist. The skeleton stays: goal, reason, limits and a testable definition of done do not go out of date. This guide is not affiliated with or endorsed by Anthropic.
One next step
Take the prompt you use most. Cut the thinking script and the capitals, add the reason and write down what "done" means. Compare the output.