Stop prompting, start briefing: delegating whole deliverables to Claude

Update — July 3, 2026. A second access change since publish: Anthropic has announced that Fable 5 stays on paid plans only until July 7, 2026 — capped at up to 50% of a plan's weekly usage until then — and after that moves to API-only, token-billed access, a surface for developers rather than for working in the app. A return to subscription plans has been left open but not committed to. For work in the app, the top capability tier after July 7 is Opus for everyone. None of the craft below changes: the brief was always written to the tier, not the model.

Update — June 26, 2026. After this published, Anthropic restricted Claude Fable 5 access following new US export controls — it's currently unavailable to non-US nationals, and the rules are still moving. The original opener said Fable 5 had "finished rolling out to everyone on a paid plan." That's no longer true, so we've corrected it. What it doesn't change is the point of the article: briefing is the skill for delegating whole deliverables to the top capability tier, and if you can't reach Fable 5, that tier is Opus — every move below works on it. Read "Fable 5" throughout as "the most capable model you can access." Background: Don't build your practice on one AI model.

This piece is about delegating whole deliverables to Claude's top tier — a capability that arrived with Fable 5 and now, for most readers, lives in Opus instead: first for everyone the access restrictions cut off, and after July 7, 2026 for anyone working in the app (see the notes above). Two weeks of coverage treated Fable 5 as a better answer machine: same prompts, shinier outputs. That framing wastes the release — and it would waste any top-tier model you point at the problem.

The real change was never one model. It's the unit of work you can hand over. We made the argument when Fable 5 shipped: the current top tier can hold an entire deliverable coherent from start to finish, which means the binding skill is no longer the prompt. It's the brief. A prompt tells the model what to produce. A brief equips it to produce the thing — the way you'd equip a subcontractor you trust with a week of work.

Most consultants have spent two years getting good at prompts. This article is the conversion course: what goes in a brief, a worked example you can copy the shape of, when to keep steering instead, and the review pass that keeps delegated output client-grade.

The prompt was always a workaround

Worth being honest about what prompt craft mostly was. Models drifted on long tasks, so we broke work into scoped steps and steered between them. They invented details, so we bolted on guardrail clauses. They wandered off-format, so we wrote format specs — "three sections, table for pricing, under two pages." A whole discipline grew up around compensating for the model in the loop.

Compensation was the right call. But notice what it trained us into: prompts that describe the artifact — its sections, its format, its length — and say almost nothing about the engagement. The model got a blueprint of the container and nothing to fill it with, so it filled it with plausible inventions, and we caught them in review, and we called that a workflow.

Anthropic's guidance for Fable 5 says the quiet part: prompts written for earlier models are often too prescriptive now, and the over-specification can reduce output quality. The model can plan the artifact. What it cannot do — what no model will ever do — is know your client, your scope boundary, and your rate floor unless you hand them over. That handover is the brief.

The five parts of a brief that works

Every working brief we've built has the same five parts. Order matters less than completeness.

1. The objective — an outcome, not an artifact. Not "write a proposal" but "get a yes on a phased engagement from a client who got burned by a big-bang project last year." The artifact version produces something proposal-shaped. The outcome version makes a hundred small decisions correctly — what to emphasize, what to defuse, where the exit ramps go — because the model knows what the document is for.

2. The inputs — everything it needs, nothing it doesn't. The transcript. Your services file. The rate floor. The client-context file. Here's the rule that does the most work in practice: anything you don't hand over, the model will invent. An input checklist isn't bureaucracy — it's the fabrication guardrail. If the draft cites a metric, that metric should be traceable to something you attached. The discipline cuts the other way too: a brief stuffed with irrelevant material buys you a slower run and a muddier draft. Relevant and complete, not exhaustive.

3. The constraints — and the negative ones carry the day. Voice. Length. The rate floor as a floor. And the prohibitions: don't promise outcomes we didn't discuss on the call, don't invent credentials or client names, don't quote a number the inputs don't support. Positive constraints shape the draft; negative constraints are what stop a confident long run from compounding a bad assumption for twelve pages.

4. What done looks like. The acceptance test, written before the run. For a proposal it might be: phase one fits inside their stated quarterly budget, every scope item maps to something the client actually said, and the whole thing survives the shape that closes — problem in their words before any solution in yours. The all-purpose version: something I'd send after one editing pass. If you can't write what done looks like, you've found the real problem — and no model fixes an undefined deliverable.

5. The why. One or two sentences of motive: who this is for, what happens if it lands, what the client is afraid of. The why settles every decision you didn't think to enumerate. It's the difference between a subcontractor following instructions and one exercising judgment in your direction.

That's the whole format. A page, usually less. It takes longer to write than a prompt — the first time. Which is the point of the worked example.

A worked example: the case study you never write

Friday's piece showed a proposal brief inline. Here's a different deliverable — the case study that every consultant means to write after a good engagement and almost never does, because it's two hours of assembly nobody bills for.

Objective: A case study that makes a prospect in the same situation say "that's my problem" — written to win the next engagement, not to flatter the last one.

Inputs: The project folder (kickoff brief, the three monthly updates, final deliverable, closing email where the client described the change in their own words). My voice file. My ICP file.

Constraints: 600–900 words. Client anonymized to industry and size. No invented metrics — if the inputs don't contain a number, the outcome gets described, not quantified. No corporate filler, no breathless adjectives; my voice file applies.

Done looks like: A reader in the same industry recognizes the before within the first hundred words. Every factual claim traces to an input. The client quote is verbatim from the closing email. I'd publish it after one editing pass.

Why: My pipeline is referral-heavy and I'm trying to open an inbound channel. This is the proof asset for the services file's second offer.

Notice the "no invented metrics" constraint — that one line is the difference between a case study and marketing fiction. Hand this brief and the folder to a top-tier model — Fable 5 if you have it, Opus otherwise — and the two hours of assembly becomes a review pass. The brief took fifteen minutes to write, and the next one will take five, because the constraints and the done-test barely change between case studies. You're not writing prose each time. You're maintaining an asset.

When to keep steering

Briefing is a mode, not a religion. Monday's model-picker piece drew the line with the leash rule — how much work you hand over between check-ins, and what wrong costs — and that line is exactly the steer-or-delegate line.

Delegate against a brief when the work is assembly against a known standard: the inputs exist, done is checkable, and your judgment applies at the end, in review. Case studies, first-draft proposals from clean discovery, the monthly pipeline memo.

Steer step by step when your judgment is the input at each stage — when seeing stage one changes what you ask for in stage two. Pricing a strange engagement. Scoping where the client's stated problem and actual problem haven't converged yet. Anything where you'd interrupt a junior mid-task because the direction depends on what turns up.

There's also a hybrid worth knowing: delegate the draft, steer the revision. Hand over the brief, take the long run, then work the output conversationally — tightening the pricing section, arguing about an emphasis call — instead of regenerating from scratch. The brief buys you a strong starting position; the steering spends your judgment where it's actually worth something, on a concrete draft instead of a blank page.

The two modes are also two products of ours, and it's worth being plain about that. Our Proposal-Closer Pack is the steered mode, deliberately: eight chained prompts that walk discovery-to-follow-up with your judgment gating every step, which is exactly what you want on engagements where the scope is still finding its shape. A more capable model doesn't retire that — it sharpens every step in the chain. What changed is that the delegated mode now exists beside it, and clean, well-understood engagements can move there. Know which mode the engagement calls for and you'll get more out of both.

The review pass: delegation is not abdication

A long-run output arrives looking finished. Formatted, confident, coherent. That polish is camouflage — the most dangerous draft is the one that reads clean enough to skip checking. Delegating the assembly means your hours move to the review, not to zero. The pass that works:

Trace every number and name to an input. Anything that doesn't trace gets cut or flagged — no exceptions for plausible-sounding figures. This is five minutes with the brief's input list open.

Check the claims a client could falsify. Dates, quotes, what was actually said on the call. A wrong adjective costs nothing; a misattributed quote costs the relationship.

Read one section aloud against your voice file. Drift hides mid-document where skimming misses it.

Run the done-test you wrote in the brief. You defined it before the run precisely so you'd hold the draft to it after.

Then the move that compounds: when review keeps catching the same class of error, the fix goes into the brief's constraints, permanently. A prompt you retype; a brief you version. Six months in, your briefs encode every mistake you've ever caught — which is a moat no one else's prompt library has.

Where briefs come from

Here's the part that should feel like relief: you don't conjure briefs from a blank page. They compile from standards you either already maintain or already know you should — who you serve, what you sell and at what floor, how you sound, what's true of each client right now. If those live in files, a brief is twenty minutes of assembly. If they live in your head, writing the first brief is what finally extracts them — paying down a debt that's been taxing every Claude conversation you've ever had. Where that material should live — Projects, skills, plain files — we've covered; the briefing habit is what makes the setup pay. And if you'd rather start from finished files than blank ones, we ship that standing setup two ways: the Claude Project Kit for chat (the instructions block, the four practice docs, a filled-in worked example), and the Claude Workspace Kit for working in your files — which also ships six briefs of exactly the kind this article teaches, written and wired to a folder, review passes included.

The "done looks like" half has a source too. If you run on documented procedures, every SOP already states when the work happens and what good output is — which is most of a brief's acceptance test, pre-written. Our Solo Operator SOP Bundle covers the ten recurring procedures of a solo practice for exactly this reason: a documented standard is what turns "review the draft" from vibes into a checklist.

This week's move: pick the one deliverable you produce most often — or avoid most reliably. Write its brief once, all five parts, and run it against your last real engagement's inputs. Review hard, fold what you catch back into the constraints, and file the brief where you'll find it next time.

A prompt is a sentence you retype. A brief is an asset you own. Start the library.