The idea

A prompt is the instruction and relevant context you give an AI model. For a coding task, “fix the parser” names a goal. It does not say how far the model may go, when it should pause, or what evidence makes the work complete.

That missing information matters when a tool can inspect or change a repository. Use scope to name the allowed area of work. Use completion criteria to name the result you need before the task can be called done. Also state a question rule: which decisions require your approval?

Plain English: Tell the model not only what to change, but also where to stop and how to prove the change worked.

This is a useful prompting pattern for developer tools in general. It is especially relevant to Claude Sonnet 5.5. Anthropic documents that, in longer agentic coding tasks, low or medium effort can lead the model to stop earlier and ask questions, while higher effort or open-ended work can lead to unrequested additions. Its guidance recommends explicitly saying when to continue, when to stop, and not to add unrequested features, tests, files, documentation, or refactors. Source

An effort setting is a model control that affects reasoning depth. For Sonnet 5.5, Anthropic says effort controls reasoning depth and that the same setting does not produce the same amount of reasoning as it did in Sonnet 5. Treat a migrated setting as something to test again, not as a fixed label. Source

A system prompt is an instruction supplied at the system level of an application. It is a suitable place for stable team rules, such as asking only before necessary or risky steps. Your task prompt can then carry the task-specific goal and boundaries.

A small example

Example — hypothetical task: You want an AI coding tool to fix a parser bug that rejects one valid date format.

A vague request is: “Fix the date parser and make sure it works.” The tool must guess whether it may change related modules, add a new test suite, rewrite documentation, or clean up nearby code.

A bounded request is:

Change only the date parser to accept YYYY/MM/DD. Do not change callers or public APIs. Ask before any risky or necessary decision outside that file. Do not add features, files, documentation, tests, or refactors unless required for this fix. Run the existing parser tests and report the command and result. Stop after reporting the changed file and test result.

The request has four parts:

  1. Goal: accept one format.
  2. Scope: only the date parser; no caller or API changes.
  3. Decision rule: ask before work outside that boundary.
  4. Proof: run existing parser tests and report the result.

The last part is verification: a real check that tests whether the requested change works. Anthropic recommends running an appropriate real check, such as tests, type checking, a build, or the changed command, before declaring a code change complete. Source

Try it

Take one small task from your current work. Spend five minutes turning it into a bounded request.

First, write one sentence for the intended change. Next, add one explicit boundary: which files, modules, or public interfaces must not change? Then add a question rule: “Ask before changing a dependency,” for example. Finally, name one command or check that should be run, and state what the final report must include.

Use this template:

Change . Only modify . Do not . Ask before . Verify by running . Report and then stop.

Start with a task you can easily review. Compare the resulting diff with the boundary you wrote. If the tool changed more than requested, make the boundary more concrete next time.

Watch out

A precise prompt is not a correctness guarantee. Inspect the diff, review the reasoning behind risky changes, and check the actual output of tests, type checking, or builds.

Do not assume that an effort value transfers between models or versions. Anthropic specifically advises reassessing Sonnet 5.5 effort settings rather than copying Sonnet 5 settings unchanged. Source

Finally, use model-specific guidance before generic advice. Anthropic’s general guidance recommends starting with model-specific prompting documentation, then applying clear instructions, examples, structured sections, and appropriate tool design. Source