Long prompts decay. You keep stuffing context into one chat window until the model is drowning in your own mess. The fix is not a better prompt. It is a brief written to disk. A brief is a contract. Any worker opens it cold, executes, hands back a result. No shared history. No "as we discussed earlier." The doc is the entire relationship. Here is the template I use. Six sections. Every brief has them. In this order. # <slug> cd <absolute path the worker starts in> ## Task One paragraph. The outcome. What "done" looks like in prose. ## Context Paths to files the worker needs. The spec. The design doc. The prior handoff. Anything not obvious from the codebase. ## Scope - In-scope: what the worker is allowed to touch - Out-of-scope: what the worker must not touch - Kill-switches: time or complexity thresholds that trigger a fallback ## Acceptance - Binary bullets. Either true or false. - Test counts. Commit messages. Evidence file path. - No subjective language. "Looks good" is not acceptance. ## Escalation One file path. If the worker hits ambiguity, it writes a question to this file and exits. Main session reads it on the next turn. ## Returns-with - Commit SHAs - Test pass count before and after - Wall-clock per major task - Final handoff doc path Why each section load-bears Task forces you to state the outcome in prose before a single line of code exists. If you cannot state it, the work is not ready to dispatch. Context is the line between a clean run and a hallucinated one. Never rely on the worker guessing which file you meant. Name the paths. Scope stops the worker sliding into adjacent work. In-scope is the yes list. Out-of-scope is the no list. Both matter. Kill-switches protect you from a worker burning six hours on the wrong branch. Acceptance is the section most people skip. Binary only. If you cannot write acceptance criteria, the work is not shaped yet. You are not ready to brief. Escalation is the pressure release valve. Without it, a stuck worker invents nonsense. With it, the worker writes a question file and exits clean. You read it on your next turn. No wasted tokens.

Most people prompt Claude like they're pulling a lever on a vending machine. Input, output, next. Then they wonder why it stays flat. The shift is simple. Treat Claude like a new employee. A collaborator you invested in. Someone you teach how you work, what you care about, what breaks you. Every session becomes an upgrade. The next session feels like Claude shipped a new version. It didn't. You did. I'm chronically dyslexic. Walls of text are invisible to me. I'll scroll past four critical flags and only catch one. So I said it out loud. I told Claude: "I missed three of the four content moments you gave me. I can't read walls." That was the input. Here's what came out of it, written into memory, applied in every session since: Every response ends with a bold decision marker. DECISION, QUESTION, or NO DECISION NEEDED. Content moments go at the top in a dedicated block. Never buried. Max three lines per paragraph. Bullets aggressive. Bold keywords inside sentences so my eyes have skim anchors. Status and decisions never mixed. Skimmable first, decision clean. I didn't get a better model. I taught the model I had. The mechanism Claude has a memory system. User profile, feedback, project context, references. Every correction, every working pattern, every "do this, not that" can be saved to disk and reloaded next session. The weakness becomes the protocol. The friction becomes the fix. The next session opens with it already loaded. That's why it feels like an update. You gave feedback once. It holds forever. The reframe Stop prompting. Start defining how you work. Tell Claude what frustrates you. Tell it what a good response looks like. Tell it your constraints, your context, your weaknesses. Correct it when it misses. Confirm it when it lands. You're not using a tool. You're onboarding a collaborator. The people who get nothing out of Claude are the people who never told it anything. // A<3

You learned the framework. Now try it on something you're actually working on. Vote below, then drop your prompt structure in the comments. Not the output. The structure. Show us how you set it up.

I hit a display bug on one of my plugins this morning. Felt sure about the fix. Told the Sonnet worker to swap the logic to kCFNull and push it. Walked away. Worker came back and said no. Flagged that my fix was a regression against working Phase 2 code. Reverted it. Added diagnostics. Proved the original empty-dict approach was right all along. I was the junior in that exchange. The advisor had the wrong mental model. The worker was closer to the code and called it. Three things this only works if you have in place: 1. The worker can disagree. If the system prompt says "execute what the advisor says," the worker agrees and ships the regression. My workers are briefed to push back when the instruction conflicts with what the code is actually doing. 2. The worker can revert. Full commit access, not suggestion-only. It rolled back my change, added diagnostics, and proved the case with evidence before I saw any of it. 3. The advisor can hear it. I had to clock the pushback as a feature, not an annoyance. First instinct was frustration. Second instinct was "oh, I was wrong." The gap between those two instincts is where most people break their own system. This is the hands-in-the-shadows setup I've been building for months. Opus in the advisor seat making judgment calls. Sonnet and Haiku workers executing in the background, with tools and permissions. Today was the first time a worker straight up told me I was wrong and had receipts. If your AI always agrees with you, it's not a worker. It's a mirror. The willingness of the system to correct its own operator is the part most people don't build in.

Shipped a major build phase overnight. Started 20:00, done by 07:40 the next morning. 11 hours clocked. ~40 hours of planned task scope. Not magic. Method. The setup One Opus model in the advisor seat. Three Sonnet workers dispatched in parallel, each scoped to a non-overlapping slice of the work. Advisor holds the map. Workers hold the hands. Why it works Sequential execution is the default because most humans can only hold one context at a time. Language models don't have that limit. You do. The bottleneck isn't the models. It's orchestration discipline. Scope correctly, and three workers finish in parallel what one would finish serially. You collapse time taken without sacrificing quality, because the advisor reviews each worker's output at the seam. The three rules 1. Slices don't overlap. If two workers can touch the same file, the brief failed before the work started. 2. Each slice has a crisp definition-of-done. The worker knows what "returned with" looks like before starting. 3. The advisor never codes. The moment the advisor opens an editor, parallel collapses into serial. The deadline math Deadline was 60 hours away when we started. We finished with 49 hours of buffer. That buffer isn't padding. That's the smoke-test window. That's the demo-prep window. That's the "something breaks at 2am" window. Compression isn't about shipping faster. It's about shipping earlier so you can ship better.