What you will be able to do
- Give Claude the actual failure output instead of a description of the symptom
- Decide whether several issues belong in one detailed message or in separate turns
- Redirect or roll back a wrong iteration with Esc and /rewind
1.Give Claude the failure itself
Once Claude has produced something and your checks have run, the next prompt should give Claude the evidence, not your summary of it. The Claude Code best-practices page shows the difference with before/after pairs. In each case the improved prompt contains the real signal and a definition of done:
| Before | After |
|---|---|
| the build is failing | the build fails with this error: [paste error]. fix it and verify the build succeeds. address the root cause, don't suppress the error |
| fix the login bug | users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. write a failing test that reproduces the issue, then fix it |
| add tests for foo.py | write a test for foo.py covering the edge case where the user is logged out. avoid mocks. |
There are two reasons. A pasted error or failing assertion is specific in a way a paraphrase isn't, so Claude can go after the root cause and not just the symptom you described. And asking Claude to verify ("fix it and verify the build succeeds") closes the loop in the same turn. The page puts it this way: "ask Claude to run the check and iterate in the same message." You can also pipe output in directly, for example cat error.log | claude, so nothing is lost in copying.
Checkpoint 1 of 5· Check yourself
After Claude's first implementation, two tests fail. Which follow-up prompt fits the documented guidance best?
The documented pattern pastes the actual error, asks for a root-cause fix, and asks Claude to verify. Skipping tests suppresses the error, which the guidance warns against.
“fix it and verify the build succeeds. address the root cause”Source: code.claude.com
Sources1
2.One detailed message, or one issue at a time?
When several things are wrong, should you report them all at once or one by one? The exam's rule is: put interacting issues in one detailed message, and handle independent issues sequentially. The sources don't use the words "interacting" and "independent", but they support both halves of the rule.
Interacting issues. Anthropic's iterate-and-fix cookbook deliberately includes a failure that is "downstream of the other two." It is there to teach the agent "not to over-fix." If Claude saw that failure alone, the obvious move would be to patch the wrong function. It can only find the shared cause if it sees all the related failures together. So when fixes depend on each other, write one detailed message with all the issues, how they relate, and the order that matters. The platform guidance recommends numbered lists or bullet points "when the order or completeness of steps matters."
Independent issues. Take a currency-formatting bug in the summary totals and a missing file extension in an export filename. They don't share a cause, and fixing one won't affect the other. Here the advice to split work applies: "Break into multiple prompts (chaining). Each prompt should do one thing well." Anthropic's prompt-engineering guide also notes that a focused task "consistently produces higher quality results than trying to accomplish multiple objectives in a single prompt." Fix one, confirm it passes, then move on to the next. Each turn stays narrow and easy to check.
| Situation | How to present it | Why |
|---|---|---|
| Failures share a cause or one is downstream of another | One detailed message with every issue and how they relate | Claude can fix the root cause once instead of over-fixing symptoms |
| Fixes must happen in a particular order | One message, steps as a numbered list | Order and completeness are explicit |
| Failures are in unrelated parts of the code | Separate prompts, one issue each | Each prompt should do one thing well |
Checkpoint 2 of 5· Check yourself
A schema change broke a serializer, and the serializer bug in turn causes two API tests to fail. How should you report these to Claude?
These failures interact: two are downstream of the serializer. Reporting them together lets Claude fix the shared cause and not patch each symptom separately.
“One of the failures (test_mean) is downstream of the other two, which quietly teaches the agent not to over-fix”Source: platform.claude.com
Checkpoint 3 of 5· Exam question
While reviewing a diff from Claude Code that adds a background job scheduler, an architect notices two problems: the retry backoff logic uses the same shared timer instance that the job-locking logic also relies on to prevent double execution, so changing one affects the other; and separately, a log message uses the wrong log level and needs a one-word fix. How should the architect sequence feedback on these two problems?
Correct answer: A — Describe the retry backoff and job-locking interaction in one detailed message because they depend on the same shared timer, and separately note the log-level fix as an unrelated change that should be addressed separately.
- A. Correct. The retry backoff and job-locking logic are coupled via the shared timer, so describing them together gives Claude the context needed to avoid breaking one when fixing the other. The log-level fix is an unrelated, trivial change that should be addressed separately to avoid confusion.
- B. Incorrect. The log-level fix is not related to the shared timer, so bundling it with the retry and locking logic would introduce noise and might cause Claude to waste effort searching for a nonexistent connection. The retry and locking logic are coupled, but the log fix is a separate cosmetic issue that should be handled independently.
- C. Incorrect. Postponing the description of the timer interaction to first handle the trivial log-level fix wastes a feedback cycle and delays the more complex, coupled change. The retry and locking logic should be presented together early so Claude has full context for a coherent fix.
- D. Incorrect. Intentionally omitting the shared timer dependency removes the critical context that Claude needs to understand why these two behaviors cannot be changed independently. Without that explanation, Claude might propose a fix for one that inadvertently breaks the other.
Checkpoint 4 of 5· Exam question
A team lead wants Claude Code to implement a CSV-to-JSON conversion utility whose column-to-field mapping rules are difficult to describe precisely in words, since the exact handling of empty cells, quoted commas, and duplicate headers matters. Which approach best sets up an effective iterative refinement loop before implementation begins?
Correct answer: A — Give Claude a few sample input rows paired with the exact expected JSON output including one row with an empty cell and one with a quoted comma, before asking it to write the converter.
- A. Correct. Providing sample rows with exact expected JSON outputs, including edge cases like empty cells and quoted commas, gives Claude a precise, unambiguous specification to implement from the start. This avoids the ambiguity that purely verbal descriptions would introduce, setting up a reliable iterative refinement loop.
- B. Incorrect. Writing the full converter first without examples and then verbally describing edge-case handling after seeing unexpected results leads to unnecessary rework and confusion. Verbal descriptions of CSV parsing nuances are inherently ambiguous, making this approach less effective for iterative refinement.
- C. Incorrect. Selecting a popular library and relying on its default behaviors does not guarantee that the handling of empty cells and quoted commas will match the team's specific requirements. This approach assumes the library's defaults are correct without verification, undermining the refinement process.
- D. Incorrect. Adding TODO comments for unresolved edge cases and moving on without further iteration defers ambiguity rather than resolving it. This leaves the implementation incomplete and risks inconsistent behavior when those edge cases are eventually addressed.
3.Redirecting or rolling back an iteration
Some iterations go wrong partway through. Claude Code gives you three ways to recover without starting over. Pressing Esc stops Claude mid-action; the context is kept, so you can redirect it with better examples or the failure output. Pressing Esc twice or running **/rewind opens the rewind menu, where you can restore an earlier conversation and code state. Telling Claude "Undo that" has it revert its own changes. If you are moving to an unrelated task, /clear** resets the context, because long sessions full of irrelevant context can reduce performance.
These tools serve the same goal as the previous sections: catch a wrong direction early, then give Claude a clearer specification or more precise evidence. As the prompt-engineering guide says, "The first prompt rarely works perfectly. Test and refine."
Checkpoint 5 of 5· Match them up
Match each control to what it does during iteration
Tap a term, then the definition that fits it.
Esc keeps the context and lets you redirect. /rewind restores an earlier state. "Undo that" asks Claude to revert. /clear removes context entirely for unrelated work.
“Esc: stop Claude mid-action with the Esc key. Context is preserved, so you can redirect.”Source: code.claude.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Every failing test needs its own direct fix, so each failure should go to Claude separately.Why is that wrong?
Some failures are downstream of others. Seeing them together lets Claude fix the shared cause; fixing each symptom directly is over-fixing.
2.Putting every outstanding issue into one big message is always the most efficient approach.Why is that wrong?
Issues in unrelated code don't benefit from being together. Splitting them into focused prompts that each do one thing tends to give better results.
3.Summarising a failure in your own words ("the build is failing") gives Claude enough to iterate.Why is that wrong?
The documented improvement is to paste the actual error, ask for a root-cause fix, and have Claude verify the result.
Covered in Give Claude the failure itself
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
“In one prompt: ask Claude to run the check and iterate in the same message, as in the table above.”
↩︎ Give Claude the failure itself“fix it and verify the build succeeds. address the root cause”
↩︎ Give Claude the failure itself“Esc: stop Claude mid-action with the Esc key. Context is preserved, so you can redirect.”
↩︎ Redirecting or rolling back an iteration“fix it and verify the build succeeds. address the root cause”
↩︎ Exam trap 3 - 2.https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practicesOfficial docs
“Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.”
↩︎ One detailed message, or one issue at a time? - 3.
“One of the failures (test_mean) is downstream of the other two, which quietly teaches the agent not to over-fix”
↩︎ One detailed message, or one issue at a time?“once those are fixed test_mean starts passing on its own without any direct edit to mean()”
↩︎ Exam trap 1“once those are fixed test_mean starts passing on its own without any direct edit to mean()”
↩︎ Prediction - 4.https://claude.com/blog/best-practices-for-prompt-engineeringSecondary source
“A focused task with clear boundaries consistently produces higher quality results than trying to accomplish multiple objectives in a single prompt.”
↩︎ One detailed message, or one issue at a time?“The first prompt rarely works perfectly. Test and refine.”
↩︎ Redirecting or rolling back an iteration“Break into multiple prompts (chaining). Each prompt should do one thing well.”
↩︎ Exam trap 2