What you will be able to do
- Rewrite a vague coding request so it includes a check Claude can run to confirm it worked
- Give Claude precise context using @ references, piped input, images and pointers to sources
- Run the explore, plan, implement, commit sequence, using plan mode to review changes before they are made
- Steer a session and manage its context with Esc, /rewind, /clear, /compact, /btw and subagents
Key concept
Verifiable, scoped instruction — Claude Code works in a loop: it acts, checks the result and corrects itself. A prompt gets much better results when it gives Claude a concrete check to run and the exact context it needs, not just a description of the outcome you want.
1.Give Claude a way to check its own work
Claude Code is an agentic loop, not autocomplete. When you ask it to fix a failing test, it runs the suite, reads the error, searches for and reads the relevant source files, edits them, and then runs the tests again to confirm the fix. That last step is what makes the loop useful, and it depends on Claude having a check to run. A request like "make the dashboard look better" has no finish line. A request with test cases, a screenshot to compare against, or a build that must pass gives Claude something it can actually verify.
| Strategy | Before | After (what changed) |
|---|---|---|
| Provide verification criteria | implement a function that validates email addresses | Names validateEmail, lists example test cases, and says to run the tests after implementing |
| Verify UI changes visually | make the dashboard look better | Pastes a screenshot, then asks Claude to screenshot the result, compare it to the original, list differences and fix them |
| Address root causes, not symptoms | the build is failing | Pastes the error, asks Claude to verify the build succeeds, and says to fix the root cause rather than suppress the error |
How firmly the check is enforced is up to you. The simplest option is to put the check in the prompt itself and ask Claude to run it and iterate. For work that spans a whole session, you can set the check as a /goal condition: a separate evaluator re-checks it after every turn, and Claude keeps working until the goal is met. If you need a hard gate, a Stop hook runs your check as a script and stops the turn from ending until the check passes. Finally, a verification subagent can review the result with a fresh model that tries to refute it, so the agent that did the work is not the one grading it.
Checkpoint 1 of 5· Check yourself
Your team wants a guarantee that Claude cannot finish a turn while the type checker still reports errors, whatever the prompt says. Which mechanism does that?
The best-practices guide describes the Stop hook as the deterministic gate: it is a script, not an instruction, and it blocks the turn from ending until the check passes. The other three options still depend on how the model behaves.
“a Stop hook runs your check as a script and blocks the turn from ending until it passes”Source: code.claude.com
Checkpoint 2 of 5· Exam question
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.
2.Point Claude at the exact context
A check tells Claude when it is done. Context tells it where to start. The best-practices guide groups this into four habits. Scope the task by naming the file, the scenario and your testing preferences. Point Claude to the source that can answer the question, such as a class's git history. Reference an existing pattern in your codebase for it to follow. For a bug, describe the symptom, the likely location and what "fixed" looks like. Its bug example ends by asking Claude to write a failing test that reproduces the issue before fixing it. That combines context and verification in one prompt.
Claude Code also gives you several ways to supply context directly instead of describing it. An @ reference makes Claude read the file before it responds. In the prompt library, "why is the build failing? @build.log" is a complete debugging prompt. Typing @ on a directory shows Claude a file listing, not the files' contents. You can pipe output straight in with cat error.log | claude. You can paste or drag in screenshots of errors, mockups or schema diagrams. You can also tell Claude to collect context itself with Bash commands, MCP tools or by reading files. For debugging, the common-workflows guide adds three things to include: the command that reproduces the issue, the steps to trigger it, and whether the failure is intermittent or consistent.
Checkpoint 3 of 5· Match them up
Match each input technique to what it does
Tap a term, then the definition that fits it.
File @ references load the file, directory @ references show only a listing, piping sends contents in directly, and images help when text would be clumsy.
“Directory references show file listings, not contents”Source: code.claude.com
3.Explore, plan, implement, commit
For anything larger than a one-line fix, the best-practices guide uses four phases. Explore: Claude reads the relevant code and builds an understanding of it. Plan: you ask which files need to change and what the flow is, and Claude writes a plan. Implement: you ask Claude to build from that plan, write tests and fix any failures. Commit: Claude writes a descriptive commit message and opens a PR. Because the plan is a separate step, you can correct a wrong approach before any code is written.
Plan mode is built for the first two phases. In this permission mode, Claude explores the code and proposes a plan but does not edit your source files, so you can review the changes before they touch disk. You can start a session in it directly:
claude --permission-mode planCheckpoint 4 of 5· Put it in order
Put the best-practices workflow for adding Google OAuth in order
- 1.Commit with a descriptive message and open a PR
- 2.Implement the OAuth flow from the plan, write tests and fix failures
- 3.Ask which files need to change and have Claude create a plan
- 4.Have Claude read /src/auth to understand sessions, login and secrets
Exploration comes before the plan, and implementation builds on that plan. Committing and opening the PR comes last.
“implement the OAuth flow from your plan.”Source: code.claude.com
4.Steer the session and keep context clean
Even a good prompt sometimes goes the wrong way. Press Esc to stop Claude mid-action. Context is kept, so you can redirect it. You can also type a correction while Claude is working: it is queued, and Claude reads it once the current tool calls finish. Press Esc twice or run /rewind to restore an earlier conversation and code state. You can also simply tell Claude "undo that".
Context is a budget. Long sessions full of irrelevant history can reduce performance, so run /clear between unrelated tasks. When you want to keep a session but shrink it, /compact <instructions> lets you choose what the summary keeps, for example /compact Focus on the API changes. Use /btw for a quick side question: the answer never enters conversation history. For broad research, such as how the auth system handles token refresh, ask Claude to use subagents. They do the investigation without filling your main context.
Checkpoint 5 of 5· Check yourself
Mid-refactor, you want to confirm a function's signature without adding anything to the session's context. Which command fits?
/btw answers without the answer entering conversation history. /clear wipes the whole context, /compact summarizes it, and /rewind restores an earlier state.
“The answer never enters conversation history, so you can check a detail without growing context.”Source: code.claude.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Pasting the error and saying "fix it" is enough for a failing build.Why is that wrong?
The recommended prompt also asks Claude to confirm the build succeeds and to fix the root cause rather than suppress the error. Without a check, Claude has no way to know it is finished.
Covered in Give Claude a way to check its own work
2.Referencing a directory with @ loads every file in it into context.Why is that wrong?
A directory reference gives Claude only a file listing. To load a file's contents, reference the file itself.
Covered in Point Claude at the exact context
3.Keeping one long session across unrelated tasks helps Claude because it remembers more.Why is that wrong?
Irrelevant history can reduce performance. The guidance is to run /clear between unrelated tasks.
Covered in Steer the session and keep context clean
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 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“Reference files with @ instead of describing where code lives. Claude reads the file before responding.”
↩︎ Point Claude at the exact context“write a failing test that reproduces the issue, then fix it”
↩︎ Point Claude at the exact context“Esc: stop Claude mid-action with the Esc key. Context is preserved, so you can redirect.”
↩︎ Steer the session and keep context clean“For more control, run /compact <instructions>, like /compact Focus on the API changes”
↩︎ Steer the session and keep context clean“write a validateEmail function. example test cases: user@example.com is true, invalid is false, user@.com is false. run the tests after implementing”
↩︎ Key concept“fix it and verify the build succeeds”
↩︎ Exam trap 1“/clear: reset context between unrelated tasks. Long sessions with irrelevant context can reduce performance.”
↩︎ Exam trap 3“read /src/auth and understand how we handle sessions and login.”
↩︎ Prediction“implement the OAuth flow from your plan.”
↩︎ Checkpoint“The answer never enters conversation history, so you can check a detail without growing context.”
↩︎ Checkpoint - 2.
“Run the tests again to verify”
↩︎ Give Claude a way to check its own work“Plan: Claude explores and proposes a plan without editing your source files”
↩︎ Explore, plan, implement, commit - 3.https://code.claude.com/docs/en/prompt-libraryOfficial docs
“why is the build failing? @build.log”
↩︎ Point Claude at the exact context - 4.https://code.claude.com/docs/en/common-workflowsOfficial docs
“Tell Claude the command to reproduce the issue and get a stack trace”
↩︎ Point Claude at the exact context“Plan before editing to review changes before they touch disk”
↩︎ Explore, plan, implement, commit“Delegate research to subagents to keep your main context clean”
↩︎ Steer the session and keep context clean“Directory references show file listings, not contents”
↩︎ Exam trap 2“Directory references show file listings, not contents”
↩︎ Checkpoint