Give the agent a check it can run, because "looks done" is otherwise the only stop signal it has. Plan before anything large. Name the files in your prompt. Clear context between unrelated tasks. Read the diff rather than the summary. Keep CLAUDE.md short enough that the rules in it still get read. Everything else is secondary.
- Give it a check it can run. Without one, you are the verification loop.
- Name the files. Orientation is the expensive phase of every task.
- Plan before anything large. A wrong direction costs the run plus the undo.
- Read the diff, not the summary. The summary was written by whatever wrote the bug.
- After two failed corrections,
/clear. The failures are now in context.
The constraint the rest follows from
Almost every practice here exists because of one property: the context window holds the entire conversation, every file read, and every command output, and model performance degrades as it fills. A single debugging session can consume tens of thousands of tokens. When the window gets full the agent starts losing earlier instructions and making more mistakes.
That is why "keep the task small" and "clear between tasks" keep reappearing below in different clothes. They are the same advice.
Habit one: give it something to verify against
An agent stops when the work looks done. Without a check it can run, that is the only signal available and you become the verification loop: every mistake waits for you to notice it. Give it something that returns pass or fail and the loop closes on its own.
The same request, without and with a check.
| Weak | Strong |
|---|---|
| "Implement email validation" | "Write validateEmail. Test cases: user@example.com true, invalid false, user@.com false. Run the tests after implementing." |
| "Make the dashboard look better" | "Implement this design. Screenshot the result, compare it to the original, list the differences and fix them." |
| "The build is failing" | "The build fails with this error. Fix it and verify the build succeeds. Address the root cause, do not suppress the error." |
Once a check exists, decide how hard it gates the stop. These are four different amounts of setup buying four different amounts of unattended reliability.
| Gate | What it does | Setup |
|---|---|---|
| In the prompt | Ask it to run the check and iterate in the same message | None |
/goal condition | A separate evaluator re-checks after every turn | One line |
A Stop hook | Blocks the turn from ending until your script passes | A script |
| A verification subagent | A fresh model tries to refute the result | A prompt or the bundled reviewer |
Ask for evidence rather than assertion: the test output, the command it ran and what came back, a screenshot. Reading evidence is faster than re-running the verification yourself, and it is the only thing that works for a session you were not watching.
Explore, plan, implement, commit
Explore
Press Shift+Tab until the status bar shows plan mode on, or launch with claude --permission-mode plan. The agent reads and answers without changing anything.
read src/auth and explain how we handle sessions and login.
also look at how we manage environment variables for secrets.Plan
Ask for a plan, then edit it. Ctrl+G opens the plan in your editor so you can cut the parts you disagree with before any code exists.
I want to add Google OAuth. What files change? What is the session flow?
Create a plan.Implement
Approve the plan or press Shift+Tab to leave plan mode, then hold it to what it wrote.
implement the OAuth flow from your plan. write tests for the callback
handler, run the suite, fix any failures.Commit
Ask for a descriptive commit and a pull request. The diff is the artefact you review, so get it into a reviewable shape before you read it.
For a larger feature, invert the flow: ask the agent to interview you first, have it write the spec to a file, then start a fresh session to execute it. The implementation session gets clean context and a written spec, which is a better trade than one long session that holds both.
Prompting that removes turns
The pattern in the right column is always the same three things.
| Weak | Strong |
|---|---|
| "Fix the login bug" | "Users report login fails after session timeout. Check src/auth/, especially token refresh. Write a failing test that reproduces it, then fix it." |
| "Add tests for foo.py" | "Write a test for foo.py covering the logged-out edge case. Avoid mocks." |
| "Make this faster" | "getOrders in src/db/orders.ts does an N+1. Batch it. Do not change the signature." |
| "Add a calendar widget" | "Look at how existing widgets work on the home page. HotDogWidget.php is a good example. Follow that pattern. No new libraries." |
- Reference files with
@rather than describing where the code lives. - Paste screenshots directly. A picture of the broken layout beats a paragraph about it.
- Pipe data in:
cat error.log | claude -p "find the root cause". - A vague prompt is legitimate when you are exploring. "What would you improve in this file?" surfaces things you would not have asked about.
Keeping CLAUDE.md worth reading
Run /init to generate a starter file from your actual project, then prune it. The test for every line: would removing this cause the agent to make a mistake? If not, cut it.
| Include | Exclude |
|---|---|
| Commands it cannot guess | Anything it can work out by reading code |
| Style rules that differ from the default | Standard language conventions |
| How to run one test | Detailed API docs; link instead |
| Branch and PR etiquette | Information that changes frequently |
| Architectural decisions specific to you | Long explanations and tutorials |
| Environment quirks and required vars | File-by-file descriptions of the tree |
| Gotchas with non-obvious behaviour | Self-evident advice such as "write clean code" |
Move procedures out. A section of CLAUDE.md that has grown into a multi-step workflow belongs in a skill, where the body loads only when it is used instead of on every turn of every session.
Managing the session
| Control | When |
|---|---|
Esc | Stop mid-action. Context is preserved, so you can redirect |
Esc Esc or /rewind | Restore conversation, code, or both to a checkpoint |
/clear | Between unrelated tasks, every time |
/btw | A side question whose answer should never enter history |
/rename then /resume | Treat sessions like branches, one per workstream |
Checkpoints change how much planning is worth doing. Every prompt creates one, and files are snapshotted before each change, so you can tell the agent to try something risky and rewind if it does not work. The caveat is real though: checkpoints only track changes made through the file editing tools. Anything a Bash command did is not captured, which is why committing before an unattended run is still the actual undo button.
Reviewing, and delegating the review
This is where value is won or lost, and it is the step under the most pressure, because reading is slower than generating and it feels like the boring part.
- Read the diff. Not the summary. The summary was written by the same process that wrote any bug in it.
- Check what it deleted. Additions get scrutinised, removals slip through, and a quietly deleted edge case is the classic agent regression.
- Run the tests yourself. "All tests pass" is a claim, not evidence.
- Look for scope creep. Files touched that had nothing to do with the task.
- Ask why, once. If the explanation is vague, the code usually is too.
For anything that ran unattended, add an independent check before you count it done. A reviewer running in a fresh subagent sees only the diff and the criteria you gave it, not the reasoning that produced the change, so it evaluates the result on its own terms. The bundled /code-review skill does exactly this and returns findings into the session, so the implementing agent can fix them without you copying text between windows.
The five expensive failure modes
| Failure | What it costs | Fix |
|---|---|---|
| The kitchen-sink session | Context full of irrelevant material | /clear between unrelated tasks |
| Correcting over and over | Failed approaches stay in context | After two, /clear and rewrite the prompt |
The over-specified CLAUDE.md | Real rules get ignored | Prune ruthlessly, or convert a rule to a hook |
| The trust-then-verify gap | A plausible diff that misses the edge cases | Always supply a check; if you cannot verify it, do not ship it |
| Infinite exploration | Hundreds of files read into your window | Scope the investigation, or send it to a subagent |
None of this is a fixed rulebook. Sometimes you should let context accumulate because you are deep in one problem and the history is the value. Sometimes skipping the plan is right because the task is exploratory. Pay attention to what worked and why, and the intuition arrives faster than any guide can deliver it.
Questions people ask
Giving the agent a check it can run: a test suite, a build, a linter, a screenshot comparison. Without one, "looks done" is the only stop signal it has and you become the verification loop for every mistake.
For anything touching more than a few files, or where you are unsure of the approach, yes. If you could describe the diff in one sentence, skip it. Planning has real overhead and only pays when the direction is genuinely in question.
As carefully as a colleague pull request, with extra attention to deletions. If the volume makes that impractical, the tasks are too big. Ask for evidence rather than assertions, and add a fresh-context reviewer for anything that ran unattended.
Press Escape immediately, then Escape twice or run /rewind to restore a checkpoint and edit the original prompt. Replying with a correction leaves the wrong reasoning in context where it keeps influencing every later answer.
Between unrelated tasks, every time, and immediately after two failed corrections on the same issue. It costs nothing, takes no time, and usually improves the next answer as well as its price.
Aim under 200 lines. Beyond that Claude starts ignoring instructions because the rules that matter are buried in noise. Move anything procedural into a skill, which loads on demand instead of on every turn.
Always. Checkpoints only track changes made through the file editing tools, so anything a Bash command did is not captured. Git is the real undo button, and a clean tree turns any bad outcome into a reset.
Delegate it. Tell the agent to use subagents to investigate, and the file reads stay in the subagent context window while only the summary returns to yours.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.