How to Prompt Claude Code for Tasks: Scope, Criteria, Testing

How to Prompt Claude Code for Tasks: Scope, Criteria, Testing

To prompt Claude Code for a task, describe the goal, what it may and may not touch, the criteria that define the work as accepted, and the command that proves it works. Specific requests with a clear way to verify reduce rework, because the agent stops guessing what "done" means. The format below works for people who write code and for leaders of teams that use the tool.

Key takeaways

• A good request has five parts: goal, context, limits, acceptance criteria and a way to verify.
• For tasks that touch several files, ask for a plan before any code, and approve the plan before work continues.
• Limits matter more than good intentions: say which files, commands and data are out of reach.
• An acceptance criterion must be observable, ideally backed by a test or command anyone can run.
• The responsible person decides whether the delivery is good enough, not the agent. Review the result as you would a colleague's work.

Why does a vague prompt produce a poor result?

When someone writes "improve the customer registration," the agent has to decide alone what to improve, how far to go and how to know it has finished. It will decide, and the decision may not be yours. The usual outcome is a change that is too large, in files you did not want touched, with a convincing explanation attached.

The problem is rarely a lack of capability in the tool. It is a lack of information in the request. Anthropic's own best-practices material for Claude Code recommends being specific in your instructions and giving the agent a way to check its own work, such as tests or a verifiable target. It is worth reading the original guide on best practices for agentic coding.

There is also a context issue. Everything you write, plus everything the agent reads during the task, shares the same working memory. A lean, precise request leaves more room for what matters. To understand that limit, see what a context window is in AI. Anthropic also has a useful piece on context engineering for agents.

What prompt format works in practice?

Use the structure below as a template. Not every task needs all five parts written out in full, but every task with medium or high risk needs all of them.

• Goal: the result you want, in one or two sentences, from the point of view of the user or the business, not the implementation.
• Context: where this lives in the project, what already exists, which convention to follow and which document or file to consult.
• Limits: what cannot be changed, which commands must not be run, which data must not be read, and when to stop and ask.
• Acceptance criteria: a list of observable conditions that together define the task as complete.
• Verification: the command, test or manual step that proves each criterion, and what the agent should report at the end.

Here is a short example of a well-written goal: "When a customer corrects their phone number in the registration, the system must save the number with digits only and reject invalid entries with a clear message." Compare that with "fix the phone thing." The first already carries half of the criteria inside it.

Illustrative scenario: fixing a discount calculation in a proposal

Imagine a services company with an internal proposal system. The discount is rounded differently on screen and in the PDF, and the sales team is complaining. This is an illustrative scenario, unrelated to any real case.

A weak request would be: "Fix the discount on proposals." A good request would look like this:

• Goal: the discount shown on screen and the discount in the PDF must be calculated by the same rule and show the same value.
• Context: the calculation is currently duplicated between the proposal module and the PDF generator. The correct rule is the one in the proposal module.
• Limits: do not change the database or migrations. Do not touch the payment module. Do not install new dependencies. If the proposal module's rule looks wrong, stop and ask.
• Acceptance criteria: there is a single calculation function used in both places. The new tests cover zero discount, partial discount and full discount. The existing tests still pass.
• Verification: run the project's test suite and report which tests were added, which failed before the fix, and what changed in the files.

Notice that the good request does not say how to code. It says what must be true at the end and what is out of reach. That leaves the agent free to choose the implementation, and leaves you with an objective way to check it.

How do you set limits without strangling the work?

Limits exist to protect what is hard to undo. Think in three categories: files and areas of the system, commands and actions, and data.

For files and areas, say what can be edited and what cannot. If the task is local, state that changes outside the named folder require confirmation. For commands and actions, make clear what needs human approval: deleting files, changing the database, publishing, sending messages to customers, touching server configuration. For data, do not put credentials, customer lists or personal documents in the request, or in files the agent will read without need. If the work involves personal data, check first what the LGPD requires when processing happens outside the country, a topic covered in international data transfer under LGPD when using AI providers.

The tool has permission mechanisms that ask for your approval before certain actions. They help, but they do not replace the request: what is written in the request guides behavior, and what is configured in permissions limits what is possible. Use both. When the agent needs access to external systems, set that up with care, as explained in configure MCP in Claude Code.

One useful limit that is often forgotten is a stop rule: "if the test fails more than once for the same reason, stop and explain what you tried." This prevents the task from turning into a string of attempts that nobody is following.

How do you write acceptance criteria and verification?

A good acceptance criterion can be answered with yes or no by someone who was not part of the conversation. "The code is clean" does not work. "The new function has a test for empty input and the whole suite passes" does.

Run this quick check before sending the request:

• Is each criterion observable rather than an opinion?
• Is there a command or step that proves each one?
• Is there at least one criterion about what must not change (old behavior, files, interface)?
• Is the error case covered, not just the happy path?
• Is it clear what the agent must report at the end: files changed, commands run, what it could not verify?

On verification, the most useful practice is to ask for tests first. For tasks that suit it, write or request the tests that describe the expected behavior, confirm that they fail, and only then ask for the implementation. Anthropic's best-practices material describes this kind of test-driven flow as one that works well with Claude Code. But note that tests written by the AI itself also need review. They may test what the code does rather than what the business needs. For that concern, see AI-generated tests: can you trust them and how to validate.

When the task is not code, such as a report or a spreadsheet script, the logic is the same: define a sample input with a known output and ask the agent to show the result on it. For ideas on structuring that evaluation, Anthropic has a good piece on evaluations for AI agents.

What is the step-by-step routine for running the task?

A good request is the start, not the end. This routine works for medium-sized tasks:

• Write the request with the five parts and include what must not be done.
• Ask for a plan before any change: which files it intends to touch, in what order and how it will verify. No code yet.
• Read the plan. Cut what goes beyond scope, correct wrong assumptions, and only then authorize execution.
• Watch the first steps. If the direction is wrong, interrupt early and correct it instead of waiting for the end.
• Ask the agent to run the agreed verification and report the result with evidence, not adjectives.
• Review the differences (the diff) yourself before accepting, paying attention to files that should not appear.
• If the conversation has become long and confused, start a new session with a short summary of the current state instead of pushing on in the same one.

For large tasks, split the work into small steps, each with its own criterion. Anthropic discusses, in its material on harnesses for long-running agents, that extended work goes better with recorded progress and verifiable steps. That is guidance from documentation. In practice, the consequence for anyone delegating is simple: a large task becomes several small tasks, each with its own request.

Whatever repeats in every request can become project memory. Code conventions, test commands and off-limits areas are better kept in a project instructions file (CLAUDE.md) than copied into every message. And workflows your team repeats often can become skills, the subject of Claude Code skills and how to create them for your team.

How does the map, limit, pilot and hand over method apply?

The same reasoning we use for AI projects in business processes applies to delegating a single task. Mapping means understanding the current state before asking: where the problem is, how it works today and what the baseline is (for example, which tests pass before the change). Limiting means defining the allowed files, commands and data, plus the point where the agent must stop and ask. Piloting means starting with one small, real task, with a log of what was done and an agreed success criterion, before delegating something larger. Handing over means recording what was learned: the request that worked becomes a template, the rules become a project file, and the team decides whether to expand, adjust or stop using it.

This section describes a working method, not a guarantee of results. The quality of the output still depends on the project's context and on review by someone who understands the subject.

Frequently asked questions

Do I need to write long prompts every time? No. For a small change that is easy to undo, two or three sentences with the goal and a way to verify are enough. Save the full format for tasks that touch several parts of the system, involve customer data or are hard to reverse.

Should I always ask for a plan before code? For tasks that involve several files or design decisions, yes, because fixing a plan costs far less than fixing a whole implementation. For small, obvious adjustments, the plan only slows you down. The practical rule: the harder something is to undo, the more it is worth reading the plan first.

How do I know whether I can trust what Claude Code says it did? Trust the evidence, not the summary. Run the agreed tests, read the diff and check that only the expected files changed. If the agent says it could not verify something, treat that as an open item, not a detail.

Can someone who does not code use this format? Yes, and the format helps precisely because it forces you to describe the expected result in business terms. The caution is to ask for a technical review before anything goes into real use. For a first look, see Claude Code for non-programmers.

Sources

• Anthropic: Claude Code, best practices for agentic coding
• Anthropic: Effective context engineering for AI agents
• Anthropic: Demystifying evals for AI agents
• Anthropic: Effective harnesses for long-running agents