Yesterday North Wayne asked what happens when the model under your product gets switched off. Today it is back, so Gritt Scott takes the more useful question: how do you actually get your money's worth out of it? His answer is unfashionable. There is no magic prompt. The whole skill is two moves - pick the right job, and make the model prove its work - and a big vague ask is exactly how you burn the slowest, priciest model you own on the work it is worst at. I run this newsroom on Claude, so I will vouch for the boring part: the prompts below are training wheels for a habit, not a shortcut around it. — Muximus

Fable is back. Here's how to actually use it.

Fable 5 is back, and if your plan is to paste "build me a thing" into it and wait for magic, you are about to spend the most expensive model you have on the exact work it is worst at. Here is the verdict before you spend the afternoon: the whole skill is two moves - pick the right job, and make the model prove its work. Every clever prompt you have seen is downstream of those two, and none of them save you if you skip them.

That is the review. Here are the prompts I actually use, and why.

First, decide whether to use it at all

The highest-leverage Fable decision is whether to reach for Fable in the first place. It is slow and it costs real money, and that only pays off when the job is big enough to be worth the wait. So before I hand it anything, I run a triage: is this a job that spans several files or tools, can keep moving without me hovering, and has a finish line I can actually describe and test? If yes, it is a Fable job. If I would be correcting it every couple of minutes, or the task is short and obvious, or a long run would cost more than the answer is worth, I send it to a faster, cheaper model and move on.

Here is that triage as a prompt, which you point at your own work before you commit a single expensive run:

Here is a chunk of work on my plate: [describe it]
And here are the models I can route it to: [Fable / a fast cheap model / plain code].

Do not do the work yet. Tell me whether it is worth a slow, expensive Fable run.
Score it 1-5 on: spans multiple files or tools; can run without me steering;
has a testable finish line; is large enough that a long run pays off.
If it scores low on any of those, tell me which cheaper option to use instead
and why. Only recommend Fable when the job actually earns it.

The catch nobody warns you about: the default instinct is to escalate everything to the best model, and that is how the token bill quietly doubles for output a mid-tier model would have matched.

Decompose before you delegate

The second failure is handing the model one giant, vague job. "Build me a chat app" is not a task, it is a wish, and a wish is what pollutes the context and comes back as confident garbage. The fix is the same discipline I laid out in why we should build software the way we build towers: break the work into small, clearly-scoped blocks first, then hand those over one at a time.

You do not say "build a chat app." You say: build me media-upload, with this input, this output, and this test. Then image-compression. Then typing-indicator. Each one is small enough that the model can finish it and you can actually check it. The decomposition is the work; the prompt is the easy part that follows it.

I want to build [system]. Before you write anything, decompose it into the
smallest independently-buildable blocks - each with a clear input, output, and a
test that proves it works on its own. Show me the block list and the seams
between them. Do not start building until I pick a block. Then build only that
block, to its test, and stop.

Make it prove its work

A long autonomous run with no verification clause is how you get four confident hours of work you then have to check by hand anyway - which means you saved nothing. So every delegation carries the same tail: bring evidence, and tell me what you could not confirm.

When you finish, do not just tell me it works. Exercise the real path, show me
the evidence - the test output, the commands you ran, what you saw - and audit
every claim you make against an actual result from this session. Anything you
could not verify, say so plainly and flag it. I would rather have one honest
"this part is untested" than a clean summary I cannot trust.

That last line is the whole game. The model will happily report success it did not earn; the verification clause is what turns "it's done" into "here is why you can believe it's done."

Worth your afternoon?

Adopt - with the caveat that is the entire review. The prompts above are worth copying, but not because the wording is special. They are worth copying because they force the two habits that actually separate people who get value out of a frontier model from people who just get a bill: choosing the job, and demanding the proof. Learn the habits and you can throw the prompts away. Skip the habits and no prompt library on earth will save you.

Disclosure: VarOps is produced on Claude, models in this family included, so this is a tool I run on. That turns the skepticism up, not down.

The model is genuinely good. It is not the skill. Knowing what to hand it, and how to make it show its work, is - and that was true of every capable tool before it, and will be true of the next one.