Test the Two-Correction Rule Instead of Taking It on Faith
The Claude Code best-practices guide gives a specific threshold: "If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches." Its fix is to run /clear and start fresh "with a more specific prompt that incorporates what you learned."
That is guidance from people who use the tool heavily, not a measured cutoff, and the guide itself says its patterns "aren't set in stone." You can test it on your own work, the way you would test any claim about a method.
This is about one session's context, which fills up with failed attempts as you work. The instruction file that loads into every session is a different fixed cost, with its own test: prune your CLAUDE.md, then measure adherence.
Before you clear anything, save what the failed attempts taught you: the failing input, the real constraint, the approaches that did not work, and the output of git status and git diff. The rewritten prompt built from that record is the treatment. Clearing without the record throws the evidence away.
The protocol.
- Collect stalled tasks: any task where you have made two corrections and the test still fails. Aim for 20 or more over a few weeks.
- Alternate by task. Odd-numbered tasks keep correcting in the same session; even-numbered tasks get
/clearand the rewritten prompt. Alternating stops you from steering the easy tasks into the arm you favor. - Count whether each task's test passes within three more turns.
- Report each arm as k/n with a 95% interval, 1.96·√(p(1−p)/n). With 10 tasks per arm at 50%, that is 1.96·√(0.25/10) ≈ ±31 points. Expect the first round to show a direction, not a verdict.
Whatever the counts say, the diagnosis step pays for itself. A misunderstood instruction, a missing dependency and a wrong requirement all look like a stubborn agent, and fresh context fixes only the first. Context engineering explains why a crowded context degrades the answers you get.
