How to hand a task to Claude Code so it doesn't go sideways

The way you frame a task changes the output more than the task itself. A vague request gets vague work. A specific one with clear scope gets specific work that stays in scope.

Here's the structure that works.

The task format

Task: [one sentence — what you want done]
Files in scope: [list the files that should change]
Files not in scope: [list the files that should not change]
Done when: [what success looks like — specific, verifiable]
Do not: [any specific things to avoid]

This takes two minutes to write. It prevents most of the common failure modes: scope creep, wrong files edited, task completed in a technically-correct-but-wrong way.

Why "done when" matters most

If you don't define what done looks like, Claude will decide. Sometimes its definition matches yours. Sometimes it calls something done when it isn't — or keeps going past done because it noticed something else.

"Done when: the test passes" is better than "done when: it works." "Done when: the API returns the correct format for empty arrays and for arrays with items" is better than "done when: the API works correctly."

The more concrete the done condition, the more likely Claude stops at the right place.

Files in scope and not in scope

This is the scope creep control. Without it, Claude will touch files it thinks are related. Sometimes those touches improve things. Sometimes they introduce bugs in code you weren't thinking about.

Listing files not in scope is especially useful for: auth middleware, database migrations, shared utilities, config files. Things where a well-intentioned change creates a problem somewhere else.

When to include "do not"

Use this for decisions Claude tends to make on its own that you disagree with. Common examples:

• Do not add error handling beyond what the tests require
• Do not change the function signature
• Do not add logging
• Do not create new files — only edit existing ones

If you've run Claude on similar tasks before and it did something you didn't want, put that in "do not."

The pre-task read step

Add this to the top of any task prompt:

Before writing any code: read [relevant files].
Tell me what you understand about how this works.
Tell me what you plan to change.
Wait for my confirmation before making changes.

This catches misunderstandings before they become wrong code. The confirmation step is optional if you trust the task is clear — but for anything non-trivial, it's worth the extra round trip.