Stop Asking Claude to Do the Task. Hand It a Contract.
A worker who has never seen the project before should be able to cold-start from the brief and produce the right output — if it has to ask, the brief is incomplete.
One Wednesday in March I spent 40 minutes free-form driving a Claude session — typing, reading, course-correcting, retyping. At the end of it I had a draft that needed another 20 minutes of cleanup. Total: an hour for an artifact that should have taken 15 minutes.
Looking at the transcript afterward, the pattern was obvious. I had asked Claude to “do the task” without telling it what done looked like. Every few minutes I’d notice it drifting, type a correction, watch it adjust, then notice the next drift. The session worked, technically. The output got there, eventually. But I had been the loop.
That session was the last time I drove free-form. The fix wasn’t a better prompt. It was a different unit of work.
The “just tell Claude what you want” failure mode
Free-form prompting trades upfront-thinking-cost for ongoing-correction-cost. The upfront cost feels small (you just type what you want); the correction cost feels inevitable (of course you iterate). Both feelings are wrong.
Upfront thinking is not optional. It happens either way. If you don’t do it before you start, you do it during, in 30-second bursts after each draft, with the model already committed to a direction and your own attention scattered across whatever Claude just produced. That kind of thinking is worse — less coherent, more reactive, full of small mid-flight contradictions you’d never write into a brief if you sat down to write one.
Writing a brief feels expensive because the cost is concentrated up front and visible. Free-form prompting feels cheap because the cost is distributed across the session and invisible until you sum it.
The brief is the unit of work
The reframe is simple: the brief, not the task, is what you produce. The brief is what the worker reads. The brief is what done looks like.
A brief that works has one property: a worker who has never seen this project before can cold-start from it and produce the right output. No “let me clarify before I start.” No mid-flight “actually I meant…”. No three rounds of revision because the constraints weren’t visible until the draft existed.
If the worker has to ask, the brief is incomplete. That’s the cleanest test I know.
This isn’t theoretical. Every brief I write goes to a session that hasn’t read any prior conversation. There’s no shared history to lean on. Either the brief is complete or the work is wrong. That constraint forces the upfront thinking that makes the rest of the session cheap.
The six sections
A complete brief has six sections. In this order. Every time.
Purpose — one or two sentences on what this work produces and why. Not “write an article about X.” More like: “Produce a 1,200-word article for the operator series, voice anchored on Article 1, lesson on the brief-as-contract pattern.” The why matters as much as the what — when the worker hits an edge case, the why is what tells it which way to lean.
Inputs — every file, reference, prior output, or external link the worker needs to read. Listed by path. No “go find the relevant docs.” If the worker needs to read it, you name it. If it’s not listed, the worker doesn’t open it.
Outputs — every file the worker writes. Listed by path. Listed by format. Listed by dimensions if it’s a visual. “Write to articles/08-brief-as-contract.md. Markdown. Target 1,100-1,300 words.” Specificity here closes off entire classes of disagreement.
Constraints — what the worker must NOT do. The edges. “No influencer-speak.” “No invented statistics.” “No filler phrases.” This is the section most operators skip and most workers need most. Telling Claude what to do points it in a direction; telling it what not to do prevents the entire neighborhood of failures you’ve seen before.
References — the canonical examples or pattern files the worker should match. “Voice anchor: Article 1.” “Visual system: 01-images-brief.md.” These references replace 90% of the back-and-forth in free-form sessions, because the worker can just look at the example instead of guessing what “match the existing voice” means.
Verify — how the worker checks its own output before reporting shipped. Greps it must run, files it must confirm, the breadcrumb it must append. Verify is what closes the loop without requiring you in it. Without a verify section, every shipped output requires an operator review pass; with one, most do not.
That’s it. Six sections, in that order, complete enough that the worker never has to ask.
Before and after, on the same task
Same task framed two ways.
Free-form ask: “Hey Claude, can you write something about the brief pattern for the blog? Make it good. Match our usual style. Probably a thousand words or so.”
What follows: the worker drafts. You read. You notice it’s too generic. You ask it to add specifics. It does, but the specifics are inventions because you didn’t give it sources. You correct the inventions. You realize the voice is off. You point at an old post. It adjusts. You realize the length is wrong. You ask for cuts. You make the cuts yourself because the model cuts the wrong sections. An hour later, you have an article.
Six-section brief: Purpose — 1,100-1,300 word Medium article on the brief-as-contract pattern, voice matched to Article 1. Inputs — _series-brief.md, 01-token-burn-daily-routine.md, 08-brief.md. Outputs — ai-articles/08-brief-as-contract.md. Constraints — no influencer-speak, no invented statistics, no clichéd AI-blog openers, em-dashes max one per ~300 words. References — Article 1 voice anchor. Verify — grep for forbidden vocabulary, confirm bio verbatim, append STATUS.md breadcrumb.
What follows: the worker reads the inputs, drafts the article, verifies against the constraints, ships. Same task. One-tenth the operator load.
The same task. Different cost structure.
Markers — you’re driving when you should be briefing
You’re typing corrections more than 3 times in a session. Each correction is a brief section you didn’t write up front.
You’re reading Claude’s draft to figure out what you actually wanted. The brief is what tells you what you want. If you only know it once you see the draft, you’ll always be one step behind.
Your sessions don’t have a defined end. A brief has a Verify section; the session ends when Verify passes. Free-form sessions end when you get tired.
You can’t hand the same prompt to a different worker and get the same output. That’s the reproducibility test. If the output depends on you being present, the brief is incomplete.
If any of these show up, the fix isn’t a better prompt mid-session. It’s pausing, writing the brief, and starting over.
What I’m giving you, and what I’m not
This article tilts toward give, because the brief pattern only works if you use it. What you’re getting: the six sections in order.
The cold-start principle (if the worker has to ask, the brief is incomplete).
The four markers for when you’re back in free-form mode.
The skeleton template, paste-able: a Brief for <task slug> with headers for Purpose, Inputs, Outputs, Constraints, References, and Verify, each with its own blank line to fill.
What I’m not giving you: my actual filled briefs, my worker-specific variants, my hook scripts that auto-verify briefs before dispatch. Those are tied to my workers and my workflow. The skeleton travels; the contents don’t.
Copy the skeleton into a new file. Fill it once. Hand it to a worker. Notice how different the session feels.