How to brief Claude Cowork for good results

Claude Cowork runs tasks asynchronously. You assign the work, Cowork executes it in the background, and you come back to the result. That model is powerful, but it changes what a good prompt looks like. In a live chat you can course-correct mid-conversation. In Cowork, if the brief is underspecified, the agent either stalls waiting for clarification or, worse, fills in the gaps itself and ships the wrong thing.

The skill you are building here is not prompting in the usual sense. It is closer to writing a brief for a contractor: complete, unambiguous, and structured so that someone who cannot reach you mid-task can still finish the job correctly.

How is Cowork different from a chat session?

In a regular Claude conversation, back-and-forth is cheap. You can say "write me a changelog" and when Claude asks "for which release?", you answer immediately. The feedback loop tightens over a few turns.

Cowork does not work that way. A scheduled or assigned task runs when you are not watching. If the brief is missing critical information, Cowork will either make a plausible guess or produce a partial result. Neither is what you wanted. A five-minute investment in the brief saves you a re-run and a debugging session.

There is also a compounding benefit. A well-structured brief inside a Cowork projectA persistent workspace in Cowork that groups related tasks, files, and memory together becomes reusable. You refine it once, and the next ten runs get it right automatically.

What are the four parts of a solid brief?

Every effective Cowork brief has four sections. You do not need to label them explicitly, but they all need to be there.

1. Goal

One sentence that states the outcome, not the activity. "Summarise" is an activity. "Produce a one-page summary of the Q2 planning doc that a new engineer can read in three minutes" is a goal. The distinction matters because it tells Cowork what done looks like.

2. Constraints

Explicit limits on format, scope, tone, length, and sources. If you leave these out, Cowork will apply reasonable defaults that may not match your expectations. Constraints also prevent scope creep: an agent without limits on which files to touch will sometimes touch files you did not intend.Common gotchaAvoid time-relative references like "the latest export" or "the usual folder".The run happens when you are not there to clarify, so "latest" can resolve to a file you did not mean. Name the exact path or a fixed naming rule instead.

Common constraints to include:

• File format and length ("markdown, no longer than 400 words")
• Which files or directories to read from and write to
• Tone or audience ("written for a non-technical stakeholder")
• What to skip ("ignore any file modified more than 30 days ago")

3. What done looks like

Describe the output concretely. If you want a table, say table. If you want bullet points grouped by category, say that. If the output should go to a specific file path, name it. The more precisely you describe the artifact, the less interpretation the agent has to do.

This is also where you specify any side effects: "append to notes/weekly.md, do not overwrite it" versus "create a new file each time with today's date in the filename."

4. What to avoid

This is the section most people skip and later regret. List the failure modes you already know about. If you have run a similar task before and Cowork did something unexpected, add "do not do X" here.Common gotchaThe trap is leaving this section out on a brand-new task because you have no failures yet. That is exactly when an unconstrained agent guesses and ships the wrong thing while you are away, and you only find out on the next run.Pre-seed it from how the task could go wrong (touching extra files, inventing data, overwriting instead of appending) rather than waiting to learn each failure the expensive way. Common items:

• Do not modify files outside docs/
• Do not include internal Slack links in the output
• Do not summarise the appendices, only the main body
• Do not invent figures that are not in the source material

Good vs bad briefs

The difference is usually specificity and completeness, not length.

A weak brief produces a technically correct result that is wrong for your situation. A strong brief produces the artifact you need.

Connecting briefs to context engineering

A Cowork brief is applied context engineeringThe practice of deliberately curating what you put in an AI's context window so the model has exactly what it needs and nothing that dilutes signal. You are not writing a prompt, you are constructing the context the agent will work inside. The same principles apply:

• Specificity beats volume. One precise constraint beats three vague paragraphs. The model reads everything you send; more text does not mean better comprehension of what you want.
• Order matters. Put the goal first. Agents read top-to-bottom and weight early content more heavily when resolving ambiguity later.
• Prune what does not help. Background story that does not change the output is noise. Cut it.

The guide on context engineering covers the underlying mechanics in detail. Briefs are the application layer on top.

Project-level context

Individual task briefs handle per-run specifics. Project-level context in Cowork handles the stable background: your team's style guide, the folder structure, recurring constraints that apply to every task in the project. For a deeper look at the project layer, see give Claude Cowork the right context.

Split them deliberately:

• Project context: audience, style rules, directory layout, persistent preferences, recurring constraints
• Task brief: specific goal, specific inputs, specific output path, any one-off constraints for this run

If you find yourself copy-pasting the same three sentences into every brief, that content belongs in the project context, not the brief. Move it once and every future task inherits it.

<!-- Example: project context snippet for a documentation project -->
 
## Project context
- Audience: senior engineers who know the system; skip basics
- Style: present tense, second person, plain language
- Output always goes to: docs/generated/
- Never modify: docs/archive/ or any file prefixed with `_draft`
- Voice: direct, factual, no filler phrases like "it's worth noting"

With that loaded into the project, your individual task briefs get shorter and more focused, because the stable constraints are already in scope.

A prompt to get started

Run this once when you are setting up a new task, then refine the output before you save it to the project.

How do I fix a brief that went wrong?

When Cowork returns something unexpected, work backwards through the four sections:

Most failures trace back to one missing section. Fix that section and re-run. You rarely need to rewrite the whole brief.

Is the upfront effort worth it?

Yes, because the cost is front-loaded and the payoff repeats. The first brief you write for a task will take ten minutes. The fifth revision will take two. After a few iterations the brief is stable, and the task runs correctly every time without your involvement. That is the compounding return Cowork is designed around: upfront investment in a precise brief, then hands-off execution indefinitely.

The briefs that pay off most are the ones attached to tasks you repeat weekly. Write them carefully once, store them in the project, and let them run.

For a broader look at how async tasks chain together into larger systems, see Workflows That Compound and How Agents Fan Out.