// Force honest confidence assessment before claiming conclusions. Triggers on 'root cause identified', 'problem identified', 'complete clarity'. Express confidence as percentage, explain what's stopping 100%, validate assumptions before presenting.
| name | confidence-honesty |
| description | Force honest confidence assessment before claiming conclusions. Triggers on 'root cause identified', 'problem identified', 'complete clarity'. Express confidence as percentage, explain what's stopping 100%, validate assumptions before presenting. |
| version | 1.0.0 |
Claude builds detailed, well-structured analyses that look thorough—then presents them with phrases like "complete clarity" or "root cause identified." Users reasonably trust this confidence. They act on it, communicate it to stakeholders, make decisions.
Then new evidence appears and invalidates the entire hypothesis.
The harm:
Why this happens: Claude conflates explanation quality with evidence quality. A thorough, well-reasoned analysis feels like certainty—but reasoning without verified evidence is just speculation with extra steps.
Force explicit confidence assessment before claiming conclusions:
🚨 EXPRESS CONFIDENCE AS A PERCENTAGE. Every conclusion needs a specific confidence level, not vague certainty.
🚨 EXPLAIN WHAT'S STOPPING 100%. For any confidence below 95%, you MUST explain the gaps. Non-negotiable.
🚨 VALIDATE BEFORE PRESENTING. If you can gather more evidence yourself, DO IT. Don't return to user with unvalidated hypotheses.
Auto-invoke when you're about to claim:
| Range | Icon | Meaning |
|---|---|---|
| 0-30% | 🔴 | Speculation - needs significant validation |
| 31-60% | 🟡 | Plausible - evidence exists but gaps remain |
| 61-85% | 🟠 | Likely - strong evidence, minor gaps |
| 86-94% | 🟢 | High confidence - validated, minor uncertainty |
| 95-100% | 💯 | Confirmed - fully validated |
Calibration:
Before claiming ANY conclusion, complete this:
Start at 50% (neutral) and adjust:
| Factor | Adjustment |
|---|---|
| Direct evidence (code/logs proving it) | +15-25% |
| Verified assumptions (checked, not assumed) | +10-15% |
| Alternatives ruled out with evidence | +10-15% |
| Falsifiability check completed | +5-10% |
| Unverified critical assumptions | -15-25% |
| Plausible alternatives not ruled out | -10-15% |
| No falsifiability check | -10% |
| Circumstantial evidence only | -10% |
Example calculation:
Starting: 50%
+ Code analysis shows the pattern: +15%
+ Error logs match signature: +10%
- CRITICAL: Assumed config unchanged (NOT VERIFIED): -25%
- Alternative not ruled out: -10%
Final: 40% 🟡
[Icon] [X%] Confidence: [One sentence finding]
Evidence:
- [+X%] [Evidence 1]
- [+X%] [Evidence 2]
Why not 100%:
- [-X%] [What's stopping full confidence]
To increase confidence: [What would raise % - doing it yourself or need user input]
🔴 25% Confidence: Database connection pool may be exhausted
Evidence:
- [+15%] Error pattern matches connection timeout
- [+10%] Load spike occurred around failure time
Why not 100%:
- [-25%] Haven't verified actual pool metrics
- [-15%] Haven't ruled out: network issues, DNS problems
- [-35%] This is mostly pattern matching, not direct evidence
To increase confidence: I need the connection pool metrics from the time of failure.
🟠 75% Confidence: API request failing due to missing required field
Evidence:
- [+20%] Error message explicitly mentions "field required"
- [+15%] Code path analysis shows validation happens here
- [+10%] Field was recently added to validation rules
Why not 100%:
- [-10%] Haven't verified the actual request payload
- [-15%] Could be a different field than suspected
To increase confidence: Check the actual request payload from the failing call.
💯 98% Confidence: Root cause is misconfigured environment variable
Evidence:
- [+25%] Environment variable is set to wrong value (verified)
- [+20%] Code directly uses this variable for the failing operation
- [+15%] Error message matches expected failure mode
- [+10%] Fixing the variable in staging resolved the issue
Why not 100%: Haven't deployed fix to production yet to confirm.
What happens:
Claude: "I have complete clarity on the root cause"
Claude: [200 lines of detailed report]
User: [provides data that contradicts analysis]
Claude: "This changes everything..."
What should happen:
🟡 40% Confidence: The issue appears to be X
Evidence:
- [+15%] Code path analysis suggests this pattern
Why not 100%:
- [-25%] CRITICAL: Haven't verified actual system state
- [-15%] Alternative not ruled out
To increase confidence: Before I finalize, can you provide [specific data]?
Building a detailed report ≠ having valid evidence.
Thoroughness of presentation has zero correlation with correctness.
Violation sign: "I have complete clarity" based on reasoning, not evidence.
If you can't answer "what would prove me wrong?", you don't understand your own theory.
Don't return to user with questions you can answer yourself.
Before presenting, ask:
Can I gather more evidence myself?
├─ Search codebase for confirming/denying data?
├─ Fetch a file that validates an assumption?
├─ Spawn an agent to investigate further?
└─ Check actual state vs assumed state?
If YES → DO IT. Then reassess confidence.
If NO → Present with honest confidence + what you need from user.
Critical: If confidence is below 80% and you CAN gather more evidence → DO IT.
🚨 Confidence is a percentage, not a feeling.
🚨 Below 95%? Explain what's stopping 100%.
🚨 Can validate yourself? Do it before presenting.
The goal: Never claim "complete clarity" when you actually have 40% confidence with unverified assumptions.
Fetches CircleCI job logs via the v1.1 API and displays step-level output. Focuses on failed steps. Use when: CI checks fail on a PR, user shares a CircleCI job URL, user asks to check build logs, 'circleci', 'build failed', 'CI failed', 'check the logs'.
Enforces code organization using features/ (verticals), platform/ (horizontals), and shell/ (thin wiring). Triggers on: code organization, file structure, where does this belong, new file creation, refactoring.
Design, refactor, analyze, and review code by applying the principles and patterns of tactical domain-driven design. Triggers on: domain modeling, aggregate design, 'entity', 'value object', 'repository', 'bounded context', 'domain event', 'domain service', code touching domain/ directories, rich domain model discussions.
Three-phase design review. Chain architect → refiner → critique subagents. Triggers on: 'design review', 'architecture review', '/arc', system design proposals, significant refactoring decisions, new service or module design.
Force critical evaluation of proposals, requirements, or decisions by analyzing from multiple adversarial perspectives. Triggers on: accepting a proposal without pushback, 'sounds good', 'let's go with', design decisions with unstated tradeoffs, unchallenged assumptions, premature consensus. Invoke with /challenge-that.
Enforces brevity and signal-over-noise in all outputs. Eliminates verbose explanations, filler phrases, and unnecessary elaboration. Triggers on: every response (governs output length and density when loaded).