Give Claude Cowork the right context

Before Claude Cowork writes a single line, decide what it can see. Point it at the exact files that matter, paste the ticket or spec verbatim, name the constraints out loud, and say what to leave alone. A scoped hand-off finishes the job. A vague one guesses, and a guess you cannot supervise is a guess you have to redo.

This guide is about the five minutes before the run, not the run itself. Cowork executes asynchronously, so you are not in the loop while it works. The context you assemble up front is the only steering you get. Get it right and the agent stays on rails. Get it wrong and it fills the gaps with plausible-but-wrong assumptions.

A vague hand-off versus a scoped one

Here is the same task, two ways.

Vague: "Add rate limiting to the API."

Scoped: "Add a fixed-window rate limiter to the login route in src/auth/login.ts. Read src/auth/session.ts and src/middleware/index.ts first so you match the existing middleware pattern. Limit: 5 attempts per IP per minute, return HTTP 429 with a Retry-After header. Do not touch any other route. Do not add a new dependency, use the existing src/lib/redis.ts client."

The vague version forces Cowork to make a dozen decisions you never authorised: which route, which algorithm, which storage, which files to edit, whether to add a library. Each decision is a coin flip away from the result you wanted. The scoped version removes the coin flips. Same model, same effort, wildly different odds of a usable result.

What are the four moves that scope a task?

A scoped hand-off does four concrete things. Do all four every time. They take minutes and they are the whole game.

1. Point it at the right files

Do not let the agent hunt. If you already know which files matter, name them. In the Claude Code CLIThe terminal tool for running Claude on your codebase, also the engine behind Cowork tasks you reference a file or directory with @, which pulls its contents straight into context instead of waiting for the agent to search for it.

# Reference specific files and a directory in the prompt
claude "Refactor the validation in @src/auth/login.ts to match the
pattern in @src/auth/register.ts. The shared helpers live in @src/lib/"

Referencing a file with @ also pulls in the CLAUDE.md from that file's directory and its parents, so project rules near the code come along for free. Reference the two or three files that define the pattern, not the whole repo. Twenty files of noise dilute the signal worse than two files of signal help it.Common gotchaBecause Cowork runs unsupervised, the tempting move is to over-attach: paste the whole directory and every adjacent file "just in case."That backfires, since the agent now has to guess which of the twenty files defines the pattern, and a wrong guess is exactly the unsupervised mistake you were trying to prevent. Attach only the two or three files that pin the pattern, and let plan mode confirm the agent picked up the right ones before it edits.

If you do not know where the relevant code lives, say so and let the agent scout first: "Find the files that handle session expiry, list them, then wait for my go-ahead." That keeps the search explicit instead of buried inside an edit you cannot see.

2. Paste the actual ticket or spec

Do not paraphrase the ticket from memory. Paste it. The wording in the issue, the acceptance criteria, the reproduction steps, the linked design note: that is the ground truth the agent should work from. Your one-line summary drops the details that decide whether the result is correct.

If the spec is long, paste the parts that define done: the acceptance criteria and any concrete examples. Strip the internal chatter that does not change the output. You are curating context, not dumping it. This is applied context engineeringDeliberately choosing what goes into the model's context so it has exactly what it needs and nothing that dilutes the signal: the right detail in, the noise left out.

A copyable shape for handing over a ticket:

3. Name the constraints out loud

Every constraint you leave unstated, the agent fills with a default that may not be yours. Make the limits explicit: format, scope, dependencies, performance budget, public API stability, the libraries already in use. "Match the existing pattern" is a real constraint and worth saying, because without it the agent may introduce a second, inconsistent way of doing the same thing.

Common constraints worth stating every time:

4. Say what to leave alone

This is the move most people skip and later regret. An agent with broad scope will sometimes "improve" things you never asked it to touch: reformat a file, rename a variable across the repo, bump a dependency, delete code it judges dead. Name the no-go zones up front.

Useful "leave alone" clauses:

• Do not modify files outside src/auth/
• Do not change the database schema or migrations
• Do not reformat files you are not otherwise editing
• Do not upgrade or add dependencies without asking first
• Do not delete code that looks unused; flag it instead

Leaving things alone is not just tidiness. A diff that touches three intended files is reviewable in minutes. A diff that also reformats forty files is a diff you cannot trust at a glance, which means you cannot ship it on the timeline Cowork was supposed to save you.Common gotchaThe opposite failure is as common: a no-go zone so wide it walls off the task itself, like "do not edit anything outside login.ts" when the fix legitimately needs a sibling helper.The unsupervised agent then either stalls or hacks around the wall. Fence off what is off-limits, not every file the change might reasonably touch.

What goes in CLAUDE.md versus the task hand-off?

Stable project rules go in CLAUDE.md; the parts that change per task go in the hand-off. Some context is the same on every run, some changes per task, so put each in the right place and you are not re-typing the stable part into every brief.

Project-wide rules belong in a CLAUDE.md memory file at the repo root (and optionally in subdirectories for area-specific rules). Claude Code loads it automatically, so every task inherits it without you pasting it. Good CLAUDE.md content: the directory layout, the test command, the style conventions, the libraries to prefer, and the standing "never touch" list.

<!-- CLAUDE.md at the repo root -->
 
# Project rules
 
- Tests live next to source as `*.test.ts`. Run them with `npm test`.
- Prefer the existing `src/lib/` helpers over new dependencies.
- Match the surrounding file's style; do not reformat unrelated code.
- Never edit files under `src/generated/` by hand.

With the stable rules in CLAUDE.md, each task hand-off shrinks to the parts that change: this ticket, these files, these one-off constraints. If you catch yourself pasting the same three sentences into every task, that text belongs in CLAUDE.md, not the hand-off.

Should I let the agent plan before it edits?

When you are unsure the scope landed, ask for a plan first. In the CLI, plan mode has the agent read the relevant files and propose an approach without writing anything to disk until you approve.

# Start in plan mode: read and propose, no edits until approved
claude --permission-mode plan

You can also press Shift+Tab inside a session to toggle plan mode. A plan is a cheap dry run of your context: if the agent's proposed steps are wrong, your hand-off was underspecified, and you can fix it before any code changes.

How do I keep parallel tasks from colliding?

If you hand off two tasks at once, isolate them so their edits do not stomp on each other. Each Cowork task should work in its own branch or its own working copy. The CLI builds this on top of git worktrees, a separate checkout on its own branch.

# Start an isolated session on its own branch
claude --worktree feature-rate-limit

Under the hood that is the standard git mechanism. You can manage worktrees directly too:

# Create a new worktree on a new branch
git worktree add -b feature-rate-limit ../feature-rate-limit
 
# List active worktrees
git worktree list
 
# Remove one when the task is done
git worktree remove ../feature-rate-limit

Isolation is itself a form of "leave alone": a task confined to its own branch cannot disturb work in progress elsewhere. See isolate parallel agents with git worktrees for the full setup.

Use a subagent to keep the main context clean

If the task needs research before the edit, pushing all that file-reading into your main context buries the actual instruction under pages of noise. Delegate the exploration to a subagent, which reads in its own context window and reports back only a summary.

# In a session, ask the agent to delegate exploration
claude "Use a subagent to map how session refresh works,
then implement the fix in @src/auth/session.ts"

The research stays out of the way and the working context stays focused on the change you scoped. For how this generalises to larger systems, see how agents fan out.

A reusable hand-off template

Keep one prompt around and fill in the blanks each time. It enforces all four moves so you cannot forget one.

Fill it in, paste it, and the agent starts with the same picture you have. That is the entire difference between a vague hand-off and a scoped one.

When a run goes sideways, check the context first

If Cowork returns the wrong thing, resist rewriting the whole brief. Walk the four moves and find the one that was missing.

Most failures trace back to a single gap. Patch that one move and re-run. You almost never need to start over.

The short version

Spend five minutes before the run, not an hour after it. Point Cowork at the files that matter, paste the real ticket, name the constraints, and say what to leave alone. Push the stable rules into CLAUDE.md so every task inherits them, ask for a plan when scope is uncertain, and isolate parallel work in its own branch. A scoped hand-off is the cheapest reliability you can buy.

For the broader skill of writing self-contained task briefs, see briefing Claude Cowork. For deciding which tasks suit async execution at all, see when to use Claude Cowork.