Confidence Scoring

You ask Claude Code to set up authentication for your app. Clean answer. Well-structured. You ship it. Two hours later you discover it used a library function that doesn't exist. The method name sounded right, the arguments looked plausible, but the whole thing was fabricated. Claude Code was 100% confident about something 100% wrong.

Confidence and correctness aren't the same thing. Three lines in CLAUDE.md can force Claude Code to separate them.

The Confidence Rule

Add this to your CLAUDE.md file:

## Communication
- At the end of your responses, write your confidence from 1 to 100 in this format: x/100
- Be objective. Do not inflate or deflate the score.
- If your confidence is below 85/100, you MUST explain what specifically is uncertain, what you couldn't verify, or what assumptions you made, and what would raise your confidence.

Three lines. Every response ends with a number. That number changes everything.

When confidence is high (85+), you glance at the score and move on. When it drops below 85, Claude Code has to stop and tell you exactly what it doesn't know. What specifically it couldn't verify, what it assumed, what would raise its confidence.

Why 85?

Not 90. Not 70. Nothing magic about the number, but it lands in the right range.

Set it to 90 and you'll drown in false alarms. Claude Code flags routine tasks because it couldn't verify every last edge case, you start ignoring the warnings, and the whole thing becomes noise you scroll past.

70 is too generous. Claude Code can feel 75% confident about something with a serious bug buried in it.

85 catches the stuff that actually matters:

• Unfamiliar APIs. Claude Code isn't sure if a method exists or what its signature looks like. Instead of guessing, it says so.
• Complex edge cases. Core logic is solid, boundary conditions haven't been thought through.
• Codebase assumptions. Code based on how Claude Code thinks your system works, without actually reading the files to confirm.
• Version uncertainty. Works in one version of a library, maybe not in yours. This one bites hard with fast-moving frameworks.

The Score Is Not the Point

The number is useful. The explanation that comes with a low score is where the real value lives.

Without this rule, Claude Code says: "Here's the authentication middleware. This should handle your JWT validation."

"Should." That word is doing enormous heavy lifting. Uncertain about the JWT library API? Your project structure? The token format? You've got no idea what "should" is hiding.

With the rule, that same response ends with: "72/100. I used the jose library for JWT verification but I did not check your package.json to confirm it is installed. I also assumed your tokens use the HS256 algorithm. If you are using RS256, the verification function signature is different. Reading your auth config file would raise my confidence."

Two specific things to check instead of reviewing every line. Way better than re-reading the whole output.

Stack this with another CLAUDE.md pattern that bans hedge words:

## Evidence Before Claims
- NEVER use hedge words ("should be", "probably", "likely", "I believe") unless you called a tool first and the tool output was ambiguous.
- Complex questions require investigation FIRST: Call tools, THEN answer.

Together they kill the vague middle ground where hallucinations hide. Claude Code either verifies and speaks confidently, or admits what it skipped.

Extensions

You don't need all of these. Start with the base rule, bolt on more when you notice specific failure patterns.

Prevent position flipping. Without this, Claude Code sometimes abandons a correct answer just because you pushed back. Infuriating when you realize later that its first answer was right.

- When challenged, do NOT flip your position to appease the user. Instead: investigate with tools, THEN respond with evidence. Flipping without new evidence is worse than being wrong initially.

Force evidence on architecture questions. Stops Claude Code from making claims about your codebase without actually reading the code. You'd be surprised how often it confidently describes imports that don't exist.

- Architecture/deployment questions: MUST call grep/read to check actual imports, configs, or call chains BEFORE answering. Directory names or file locations are NOT proof of usage.

Domain-specific thresholds. If you are working on something safety-critical, you can set a higher bar for certain categories of work.

- For security-related code (auth, crypto, input validation, permissions), confidence below 90/100 requires citing the specific documentation or source you relied on.

Try it: Add the three-line confidence rule to your CLAUDE.md right now. Ask Claude Code to do something moderately complex, like refactoring a module or adding error handling to an API route. Watch the score. If it drops below 85, read the explanation and check whether those uncertainties are real. You'll almost certainly find something that would've slipped through.

The confidence rule is the single highest-value addition to any CLAUDE.md. Three lines, permanent improvement, zero maintenance. The 85 threshold keeps noise low. The explanation that comes with a low score tells you exactly what to verify. And banning hedge words alongside it closes the last escape hatch for vague answers.