What you will be able to do
- Write a Claude Code prompt that includes a check Claude can run to prove its own work
- Choose between a check inside one prompt, a /goal condition, a Stop hook and a verification subagent
- Split a non-trivial change into explore, plan, implement and commit phases, and know when plan mode fits
- Give Claude precise context with @ references, pasted errors, piped input and pointers to sources
- Use the documented recipes for debugging, refactoring, testing and documentation
Key concept
Verification criteria — A concrete check you give Claude, such as test cases, a build that must pass or a screenshot to compare against. Claude runs the check and keeps iterating until it passes, so you are not the one who has to judge whether the work is done.
1.Give Claude a way to check its own work
The best-practices guide keeps coming back to one change in how developers prompt. Don't just describe what you want. Also describe how Claude can tell that it got there. A request like "implement a function that validates email addresses" has no finish line. Claude writes something plausible and stops. If the same request includes example inputs with their expected results, plus an instruction to run the tests, Claude has something objective to work towards. The same holds for UI work, where a screenshot of the target design is the reference, and for failures, where the check is that the build succeeds.
| Strategy | Before | After |
|---|---|---|
| Provide verification criteria | implement a function that validates email addresses | write a validateEmail function with example test cases, then run the tests after implementing |
| Verify UI changes visually | make the dashboard look better | paste a screenshot, implement the design, screenshot the result, list the differences and fix them |
| Address root causes, not symptoms | the build is failing | paste the error, fix it, verify the build succeeds and don't suppress the error |
The guide describes four places to put the check, and each is sturdier than the one before. The simplest is inside a single prompt, as in the table. For work that runs across a whole session, you can make the check a /goal condition. The docs explain that a separate evaluator re-checks the condition after every turn and that Claude keeps going until the goal resolves. When the check has to be deterministic, a Stop hook runs it as a script and won't let the turn end until the script passes. The last option is a second opinion. A verification subagent or a self-checking dynamic workflow has a fresh model try to refute the result, so the agent that did the work doesn't grade itself.
A Stop hook. It runs the check as a script, outside the model, and blocks the turn from ending until the script passes. A check written into the prompt, or a /goal, still depends on Claude or an evaluator model to act on it. The hook is the deterministic gate.
A platform team wants Claude Code to automatically block any Bash tool call that includes rm -rf targeting a path outside the working directory, without relying on the model choosing to avoid it on its own. Which mechanism should they configure?
Correct answer: A — Configure a PreToolUse hook that inspects the Bash tool input and returns a deny decision before the command runs
- A. Correct. A PreToolUse hook is a deterministic shell command that runs before the matching tool executes and can return a blocking decision, so it enforces the rule regardless of what the model decides, which is exactly the guarantee hooks are designed to provide over relying on the model's judgment.
- B. Incorrect. Plan mode blocks all execution, not just the specific dangerous pattern, so it would stop every Bash command including safe ones, and it is not a targeted, permanent enforcement mechanism for this one rule.
- C. Incorrect. A CLAUDE.md instruction is guidance the model may follow, but it is not deterministic enforcement; the model could still misjudge or ignore the instruction under certain phrasing of a task.
- D. Incorrect. Delegating to a restricted subagent limits which tools that subagent can call, but it does not deterministically inspect and block a specific dangerous command pattern the way a PreToolUse hook does, and the main agent could still issue the command directly.
Sources1
2.Explore, plan, implement, commit
The guide's example of adding Google OAuth splits one feature into four prompts. First Claude explores: it reads the auth code and how secrets are managed. Next it plans: which files have to change, and what does the session flow look like? Then it implements from that plan, writing tests for the callback handler and fixing any failures. Finally it commits and opens a PR. The point of separating the steps is that you can review Claude's understanding and its plan before any code changes. A wrong assumption is much cheaper to catch in a plan than in a diff.
Plan mode builds that separation into a permission mode. In plan mode, Claude explores and proposes a plan but doesn't edit your source files. The common-workflows page describes the use case as planning before editing, so you can review changes before they reach disk. You can start a session in plan mode from the command line:
claude --permission-mode planWhen you aren't sure what to build yet, you can reverse the roles. The guide suggests asking Claude to interview you in detail with the AskUserQuestion tool about implementation, edge cases and tradeoffs, and then to write a complete spec to SPEC.md.
3.Feed Claude precise context
A vague prompt makes Claude guess, and it may guess wrong. The guide contrasts vague and specific requests. "add tests for foo.py" becomes a request for one test covering the logged-out edge case, without mocks. "why does ExecutionFactory have such a weird api?" becomes a request to read ExecutionFactory's git history. "add a calendar widget" becomes a request to follow an existing widget in the codebase, with a named file as the example. In each case you are telling Claude where the answer lives rather than hoping it finds the right place.
| Technique | What it does |
|---|---|
| @ file reference, e.g. @src/utils/auth.js | Claude reads the file before responding |
| @ directory reference, e.g. @src/components | Shows the file listing, not the file contents |
| @ MCP resource, e.g. @github:repos/owner/repo/issues | Pulls data from a connected MCP server into the prompt |
| cat error.log | claude | Sends the file's contents directly to Claude |
| Pasted or dragged-in images | Screenshots of errors, UI designs or diagrams, useful where text would be unclear |
| URLs, with /permissions | Documentation and API references; allowlist frequently used domains |
You also don't have to paste everything yourself. The guide recommends telling Claude to fetch context on its own, with Bash commands, MCP tools or by reading files. Context works in both directions, though. When you move on to an unrelated task, run /clear, because long sessions full of irrelevant context can reduce performance. If Claude heads the wrong way, press Esc to stop it without losing context, or press Esc twice (or run /rewind) to restore an earlier conversation and code state.
Sources1
4.Recipes for debugging, refactoring, tests and docs
The common-workflows page turns everyday tasks into short prompt sequences, and they all follow the same pattern: find, propose, apply, verify. For debugging, share the error, ask for a few possible fixes, then apply the one you choose. The tips are what make it work. Give Claude the command that reproduces the issue and produces a stack trace, list the steps to reproduce, and say whether the error is intermittent or consistent. The best-practices guide adds that a bug report should include the symptom, the likely location and what "fixed" looks like. Its example ends with an instruction to write a failing test that reproduces the issue before fixing it.
The how-it-works page describes the loop. Claude runs the test suite to see what's failing, reads the error output, searches for the relevant source files, reads them, edits them to fix the problem, and runs the tests again to verify. Everything you supply in the prompt, such as the reproduce command, the likely location and whether the error is intermittent, shortens that loop.
The other recipes follow the same pattern. Refactoring goes from finding deprecated API usage, to suggestions, to a change that keeps the same behaviour, to running the tests, done in small, testable increments. Testing goes from finding untested functions, to scaffolding, to edge-case tests, to running them and fixing failures. Documentation goes from finding undocumented functions, to adding comments in the style you name, to checking them against your project standards. Pull requests go from summarising your changes, to creating the PR, to improving the description.
A security engineer wants Claude Code to review a pull request from an external contributor. Claude should be able to read files and run analysis commands, but the engineer must manually approve every file edit and shell command before it executes. Which permission mode satisfies this requirement?
Correct answer: A — default (Manual) mode, which prompts before any write or command beyond reads
- A. Correct. Manual mode, the default mode, only auto-approves reads and prompts before every edit, write, or shell command, matching the requirement that the engineer approve every action on an untrusted external contribution.
- B. Incorrect. acceptEdits auto-approves file edits and common filesystem Bash commands like mkdir or mv without a prompt, which violates the requirement to manually approve every edit and command.
- C. Incorrect. auto mode routes most actions through a classifier that approves them without a human prompt, which is the opposite of requiring manual approval for every edit and command.
- D. Incorrect. bypassPermissions disables prompts entirely, including for protected paths, so nothing would require the engineer's manual approval.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Telling Claude Code "the build is failing" is enough, because Claude can run the build and work out the rest.Why is that wrong?
The documented better prompt pastes the actual error, asks Claude to fix it and verify that the build succeeds, and forbids suppressing the error instead of fixing the root cause.
Covered in Give Claude a way to check its own work
2.Referencing a directory with @ loads every file in it into Claude's context.Why is that wrong?
A directory reference only gives Claude the file listing. To give Claude a file's code, reference that file directly.
Covered in Feed Claude precise context
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/best-practicesOfficial docs
“A separate evaluator re-checks it after every turn and Claude keeps working until the goal resolves.”
↩︎ Give Claude a way to check its own work“a Stop hook runs your check as a script and blocks the turn from ending until it passes”
↩︎ Give Claude a way to check its own work“has a fresh model try to refute the result”
↩︎ Give Claude a way to check its own work“I want to add Google OAuth. What files need to change?”
↩︎ Explore, plan, implement, commit“Interview me in detail using the AskUserQuestion tool.”
↩︎ Explore, plan, implement, commit“Reference files with @ instead of describing where code lives. Claude reads the file before responding.”
↩︎ Feed Claude precise context“Tell Claude to pull context itself using Bash commands, MCP tools, or by reading files.”
↩︎ Feed Claude precise context“reset context between unrelated tasks. Long sessions with irrelevant context can reduce performance.”
↩︎ Feed Claude precise context“press Esc twice or run /rewind to open the rewind menu and restore previous conversation and code state”
↩︎ Feed Claude precise context“write a failing test that reproduces the issue, then fix it”
↩︎ Recipes for debugging, refactoring, tests and docs“ask Claude to run the check and iterate in the same message”
↩︎ Key concept“the build fails with this error: [paste error]. fix it and verify the build succeeds.”
↩︎ Exam trap 1 - 2.
“Plan: Claude explores and proposes a plan without editing your source files”
↩︎ Explore, plan, implement, commit“Search for the relevant source files”
↩︎ Recipes for debugging, refactoring, tests and docs - 3.https://code.claude.com/docs/en/common-workflowsOfficial docs
“Plan before editing to review changes before they touch disk”
↩︎ Explore, plan, implement, commit“Tell Claude the command to reproduce the issue and get a stack trace”
↩︎ Recipes for debugging, refactoring, tests and docs“Let Claude know if the error is intermittent or consistent”
↩︎ Recipes for debugging, refactoring, tests and docs“Do refactoring in small, testable increments”
↩︎ Recipes for debugging, refactoring, tests and docs“Directory references show file listings, not contents”
↩︎ Exam trap 2