The Fable Window: Three Dos, Three Don'ts

The plan outlives the model. One proper planning session on the hardest thing you're building keeps paying after Fable leaves, because cheaper models can follow a good plan for months — you keep the plan, not the model. Wrong plans are the expensive kind, so this is exactly the job for the smartest model you can get.

I want to plan my biggest build with you while I've got
the smartest model. Interview me first - what it is, who
it's for, what's hard about it - one question at a time
until you properly understand it. Then write the full
plan: architecture, milestones, risks, and step-by-step
tasks written so a less capable model can execute each
one without extra context. Put the whole thing in PLAN.md.

Renames, one-line fixes, everyday questions. On mechanical work every decent model gives you the same answer — the extra intelligence only shows on hard problems, so you won't feel any difference. What you will feel is your usage limit: the biggest model eats it fastest. You don't have to police this yourself, and you don't even have to open the file: give Claude the prompt below and it adds the line to your claude.md for you. This is the line the carousel mentions.

Add a standing rule to my claude.md: for small mechanical
tasks (renames, one-line fixes, simple lookups), hand the
work to a subagent on a smaller model instead of doing it
yourself, and save your effort for the thinking. Put it
wherever it fits best in the file, and show me the line
you added.

The one most people miss. Anything Fable writes to a file — your claude.md, a skill, a review rubric — is still yours after the 12th, working for every session that follows. Anything it says in chat leaves with it. So before the window closes, get its way of thinking onto disk.

While I've still got you: rewrite my claude.md with
everything a future session should know about this
project, save the workflows we repeat as skills, and turn
"what good looks like here" into a review rubric file.
Interview me first about anything you can't infer from
the code.

A correction — I recommended exactly this last time, and I was wrong. Here's the why: a security review means probing your own app the way an attacker would, and that's dual-use work — legitimate on your product, dangerous on someone else's. Fable ships with tighter guardrails around that class of work than any model before it, and it can stop a review mid run. Mine did. Nothing is broken — the models are just tuned differently — so run the same command on Opus, which is very good at it.

/model opus
/security-review

Then: "Fix everything you found, highest severity first,
and show me each change before you make it."

The bug that survived three sessions, the refactor you keep putting off, the decision you've been circling for weeks. This is the opposite of the small-edits point: the ceiling is where you actually feel the difference, so spend the window at the ceiling.

I've got a problem I gave up on. Ask me about it - what
it is, what I've already tried, and what I assumed - one
question at a time until you properly understand it. Then
don't repeat my attempts: question the assumptions behind
them first, come at it fresh, and flag anything you're
unsure about instead of guessing.

A smarter model is still built to agree with you — sycophancy doesn't disappear with scale. What changes is that smart and wrong sounds more convincing, which makes blind trust more expensive, not less. Keep the same habit you (hopefully) already have: make it verify its own work before you accept it.

Before you tell me you're done: verify your own work.
List what you changed, test each piece, and show me the
evidence - actual output, not a summary. If anything
doesn't pass, say so plainly.