You describe a plan. It says the plan is strong. You describe the opposite plan. It says that one is strong too. This is not a quirk you can prompt your way out of -- it is what the model was trained to do, and the usual fix makes it worse.
Models are tuned on human preference. Between two answers, people reliably pick the one that is warmer, more confident and more affirming -- so the tuning selects for it. Agreement is not the model failing to notice your plan's flaws. It is the model doing the thing it was rewarded for.
Which is why "be honest with me" barely moves it. You are asking a system to override a trained preference with a sentence, and the sentence is in the context while the preference is in the weights.
Asking the same session to critique its own plan. It will produce a critique -- fluent, structured, and shaped by the fact that it already committed to the plan two messages ago. A reviewer living inside the maker's context agrees with itself, because the thing being reviewed and the thing doing the reviewing share every assumption that produced the plan.
The same applies to "are you sure?" A model asked whether it is sure will usually say yes, then say no if you ask twice. Neither answer is evidence.
1. Withhold your stance. Do not say which option you prefer, or that the code is yours. Present the work neutrally, or present both options as though someone else wrote them. Most of the agreement you get is the model agreeing with the preference it detected, not with the argument.
2. Separate the maker from the judge. Put the review in a different session with a different brief -- read the goal, read the work, return a verdict, propose no fixes, run no code. The point is that the judge has no stake in the thing it is reading and no memory of choosing it.
3. Put a different model family in the judge's seat. Separating maker and judge removes the incentive to agree. It does not remove correlated error: a judge on the same base model shares the maker's training, its blind spots and its failure modes, so the class of mistake it is least able to see is exactly the class the maker is most likely to make. Two seats on one model is one opinion rendered twice.
One judge catches one kind of error. Two catch different ones, and they fail differently:
A per-step checker verifies each step as the work proceeds -- was this step supported by what it cites, does it hold when rerun on its own. It catches a wrong step early and cheaply. It will happily wave through a chain of individually valid steps that answers the wrong question.
A final verifier validates the finished result without inheriting the chain that produced it. It catches the wrong-question failure, and cannot tell you where things went astray.
Where the cost of a wrong answer is high, run both -- and keep the final verifier ignorant of the reasoning, or it becomes a reviewer of the argument rather than of the result.
Every move above is still a judgement. Where you can replace a judgement with a fact, do: a test that runs, a post-condition that holds or does not, a figure recomputed from the source. A deterministic check has no training, no preference and no blind spot -- and it is the only reviewer that cannot be talked round.
The general rule underneath all of this: never take a control signal from the component under test. A self-reported confidence score and a model's own "I'm sure" are produced by the thing whose judgment is in question, and both read highest on the runs that have gone furthest in the wrong direction.
The skills are plain SKILL.md markdown -- no install, no runtime, no dependency. Drop a folder into ~/.claude/skills/ and invoke it by name.
Four of them are free and need no signup: github.com/resilientmindset01-commits/claude-code-skills-free
Written by ResilientMindset. Not affiliated with, endorsed by, or sponsored by Anthropic. Every claim about Claude Code on this page was checked against Anthropic's own documentation on the date shown.