All posts

Brief Claude Cowork like a contractor, not a colleague

Cowork doesn't fail because Claude is dumb. It fails because you briefed it the way you'd brief someone who already sits in your head.

Here's the deal. Claude Cowork runs on your actual files, in an actual folder, for a long stretch without you watching. That's the whole point of it. And the thing that decides whether you get back something usable or something you have to redo by hand is not the model, not the prompt cleverness, not the temperature of your mood that morning. It's the brief. Specifically: whether the brief is a conversation opener or a contract.

The usual take on briefing agents is "write a better prompt." Longer. More context. Add a persona. That advice is wrong for Cowork, because a long prompt is still ephemeral, still one message, still something you can't diff, version, or hand to a second agent. When I brief a freelance designer I don't send a 900-word paragraph. I send a file: what we're making, what exists already, what's off limits, what done looks like. The handoff-file pattern is just that, applied to Claude. You write the brief as a file in the working folder. Claude reads it, works against it, and writes back to it. And the difference in output quality is not subtle.

Why a message is not a brief

A prompt is a request. A handoff file is a spec you both point at. The practical differences:

	Long prompt in chat	Handoff file in the folder
Survives a new session	No	Yes
Can be version-controlled	No	Yes
Claude can update it mid-run	No	Yes
You can reuse it for the next campaign	Copy-paste, degraded	Duplicate, edit 4 lines
Second agent can pick up the work	No	Yes
You can audit what it was told	Scroll hell	git diff

The one that matters most is row three. A handoff file is two-way. Claude writes its questions, its assumptions, and its [MISSING] flags back into the same document. When you come back after an hour, you're not reading a transcript to reconstruct what happened. You're reading one page that tells you what it did and what it needs from you.

The file layout

Drop this in the folder Cowork is pointed at. Five files, no more. I've tried richer structures and they rot within a fortnight.

campaign-q4-winback/
├─ BRIEF.md            ← the contract. Claude reads this first, every time.
├─ CONTEXT/
│  ├─ voice.md         ← how we sound. Real excerpts, not adjectives.
│  ├─ audience.md      ← who, what they already believe, what they've heard from us
│  └─ facts.md         ← numbers, claims, product truths. The ONLY source for stats.
├─ INPUT/              ← raw material. Exports, transcripts, old assets, the SERP dump.
├─ OUTPUT/             ← where Claude writes. Never edit INPUT.
└─ LOG.md              ← Claude appends: what it did, what it assumed, what it needs.

Three rules make this work and all three are load-bearing:

INPUT is read-only. Say so in the brief. Otherwise you lose the ability to re-run a task cleanly, because the source material has quietly drifted.

facts.md is the only place numbers may come from. If a number isn't in there, Claude writes [MISSING: REAL NUMBER] and moves on. This is the single highest-value line in the whole pattern. Agents invent plausible statistics when a sentence has a number-shaped hole in it, and a plausible invented statistic is worse than a blank, because a blank gets fixed and a plausible number gets published.

LOG.md is append-only and Claude owns it. You read it. You don't tidy it.

BRIEF.md: the actual template

Copy this. The section headers matter more than the prose; keep them stable across projects so Claude's behaviour stays stable too.

# BRIEF ,  Q4 winback email sequence

## Contract
You are producing: 4 emails + subject line variants, in OUTPUT/.
You are NOT producing: strategy recommendations, a deck, a channel plan.
Done means: each email passes the Definition of done below, and LOG.md
lists every [MISSING] flag you raised.

## Scope boundaries
- Read: INPUT/ and CONTEXT/. Treat INPUT/ as read-only, never edit it.
- Write: OUTPUT/ and LOG.md only.
- Do not create new subdirectories.
- Do not fetch anything from the web for this task.

## Source of truth
- Numbers, product claims, pricing: CONTEXT/facts.md ONLY.
  If a number you need is not there, write [MISSING: REAL NUMBER] inline
  and add a line to LOG.md. Never estimate, never use an industry average,
  never write "up to". This is non-negotiable and I will check.
- Voice: CONTEXT/voice.md. Match the excerpts, not the adjectives.
- Audience state: CONTEXT/audience.md.

## Definition of done (per email)
1. Subject line under 45 characters, no colon-splice, no emoji.
2. One idea per email. If it needs two, it's two emails, flag it in LOG.md.
3. Every claim traceable to facts.md, or flagged.
4. No em dashes. Commas or full stops.
5. Ends with one action, not three.

## Known failure modes (avoid these specifically)
- Opening with "We noticed you haven't..." Nobody wants surveillance.
- Apologising for emailing. We're not sorry, we're useful or we're not.
- Stacking three CTAs because the copy didn't earn one.

## Working style
- Work through all 4 emails before asking me anything, unless you hit a
  blocker that makes the remaining work pointless.
- Batch questions into LOG.md under "## Needs Zara". Don't stop and wait
  per-question.
- When you finish, append a LOG.md entry: files written, assumptions made,
  open flags.

The two sections people skip are Known failure modes and Working style, and they're the two that change the output most. Failure modes are how you encode taste, the specific bad moves you've seen a hundred times and can't be bothered to correct a hundred and first. Working style is how you stop an hour-long run from stalling at minute four on a question that could have waited.

The "you are NOT producing" line

Negative scope is the cheapest quality lever in agent briefing. Claude is helpful by default, and helpfulness expands. Ask for four emails and you often get four emails plus a suggested testing plan plus a note about your segmentation plus a tidy little summary of best practices you didn't ask for.

None of that is bad work. It's just work you now have to read, evaluate, and discard, which is a tax paid in your attention. A contractor who delivers double the scope isn't generous, they're expensive to manage. One line of explicit exclusion in the brief removes it.

Same logic applies to the filesystem. "Write: OUTPUT/ and LOG.md only" prevents the thing where you come back to a folder with a notes/, a drafts/, a v2/, and a README.md that Claude wrote to explain its own filing system.

Voice.md: excerpts, not adjectives

The most common way a brief fails is the voice section. People write:

> Our tone is friendly but professional, confident but not arrogant, warm and human.

That describes roughly every brand on earth and constrains nothing. What actually works is a file of real sentences with a verdict attached:

# Voice

## Sounds like us
"We don't want your email. We want a fair exchange."
"Restraint is a strategy."
"Here's what this doesn't do."

## Does not sound like us
"Unlock the power of AI for your marketing team." (webinar language)
"In today's fast-paced landscape..." (says nothing, costs a sentence)
"We're excited to announce..." (nobody is excited, including us)

## Rules
- No em dashes. Ever.
- Short sentences. Then one longer one to change the rhythm.
- Name the flaw before the buyer finds it.
- Never two emphasis words in one sentence.

Twelve real lines beat three paragraphs of adjectives. If you have published work, paste six sentences you'd defend in a room and six you'd be embarrassed by. That's your voice file.

LOG.md: the thing that makes it two-way

Give Claude the format or you'll get freeform prose. This shape reads in fifteen seconds:

## 2026-09-24 14:02 ,  run 1
Wrote: OUTPUT/email-1.md, OUTPUT/email-2.md, OUTPUT/email-3.md, OUTPUT/email-4.md

Assumptions made:
- Treated "lapsed" as 90 days, per INPUT/segment-export.csv column header.
  Not confirmed in facts.md.
- Email 3 assumes the Q3 feature shipped. Not in facts.md.

## Needs Zara
- [MISSING: REAL NUMBER] email-2, line 14: "X customers came back last quarter"
- [MISSING: REAL NUMBER] email-4, line 8: time-to-value claim
- Email 3 wants a screenshot. None in INPUT/. Placeholder left.
- "Winback" offer: facts.md lists 20% and 25% in different places. Which?

That last line is the tell of a good run. It found a contradiction in my own source file and refused to pick one. That's the behaviour you're paying for, and you only get it if the brief explicitly makes refusing the right answer.

Honest failure mode: Claude will sometimes log an assumption and then not actually flag it inline in the copy, or flag it inline and forget to log it. Belt and braces, ask for both, and skim the output for number-shaped claims before you ship. The pattern reduces invention a lot. It doesn't make checking optional.

Running it: the opening message

Once the files exist, the message you send is short, because the brief is doing the work.

Read BRIEF.md first, then CONTEXT/ in full, then skim INPUT/.

Follow BRIEF.md exactly, including the negative scope and the
[MISSING: REAL NUMBER] rule. Work through the full scope before
coming back to me. Append to LOG.md when you're done.

Start now.

That's it. If you find yourself adding instructions to this message, stop and put them in BRIEF.md instead. Every instruction that lives in chat is one that evaporates next session, and next session is where the compounding lives.

Reuse: duplicate the folder, keep CONTEXT/ as-is, rewrite the Contract and Definition of done. Second campaign takes about four minutes to brief. That's the actual return on this, not run one.

Where this connects to research work

The same discipline runs upstream. If the brief is going to say "source of truth is facts.md," something has to fill facts.md with things that are actually true rather than things that sound right. For content and SEO work that's where the SERP-Informed Brief Skill fits, it's one of the free Skills at /skills/ with no email gate. It pulls what's actually ranking and what those pages actually cover, and its output drops cleanly into INPUT/ or CONTEXT/facts.md as sourced material rather than vibes.

It's built on the same refuse-first rule: where it doesn't have a real figure, it says so instead of filling the gap. Which is the point. A handoff file inherits the honesty of whatever fed it, and if you fill facts.md with plausible guesses, you've just automated the production of confident nonsense at higher volume.

Where the Hub fits

If what you needed today was the pattern, you have it. The layout, BRIEF.md, voice.md, the LOG format, the opening message are all above and all copy-pasteable. Nothing is held back, and if the four free Skills at /skills/ and four free prompts at /free/ cover the work you actually do, use those and don't pay me anything. That's a real recommendation, not a modesty move.

What the paid library adds is the boring repetitive part: pre-built BRIEF.md contracts and Definition-of-done blocks per discipline, so you're not writing "here's what good looks like for a lifecycle email" from scratch each time. A single pack is the right buy if you mostly work in one discipline, one set of briefs, one set of failure modes, done properly. If you're spread across three or four disciplines, the single pack will annoy you and you should look at the suite instead. And if you're not sure yet, build two projects with the template above first. You'll know by the second one whether the repetition is worth paying to remove.