Confidence Assessment

Rate your confidence that the current work fully solves the stated requirement.

Multi-signal evaluation. A single LLM-confidence number is unreliable as a stand-alone gate (token probability ≠ correctness). This skill combines the LLM's dimensional scoring with deterministic rule checks the agent must run alongside. The final score is gated on BOTH passing.

Contents

• Mode Detection
• Assessment Dimensions
  • For plan mode — multi-signal: LLM scoring + rule checks (89% cap on failure)
  • For code mode
  • For analysis mode
• Output Format
• Score Thresholds
• Iteration Protocol (plan mode)
• Auto-Fix (Fix Mode Only)

Mode Detection

Check the arguments: $ARGUMENTS

If no argument is provided, default to code.

Alias handling. bug-analysis is accepted as a deprecated alias and resolves to analysis with identical dimensions, weights, thresholds, and Fix Mode behaviour. When invoked with the alias, prepend a single line to the report header: > Note: \bug-analysis` is a deprecated alias for `analysis`. Update the caller when convenient.` The alias keeps in-flight workflows and existing transcripts working through the transition; remove it after callers have migrated.

If arguments contain "fix" (e.g., code fix, plan fix, analysis fix), run in Fix Mode — after the review, automatically apply fixes for any concerns found.

Assessment Dimensions

For plan mode

Plan mode is multi-signal: LLM dimensional scoring + deterministic rule checks. Both must pass for the gate to clear.

Step 1 — LLM dimensional scoring

Step 2 — Deterministic rule checks (run via Bash)

Every check below MUST pass for plan mode. A single failed rule caps the gate at 89% regardless of LLM score — the agent must surface the failed rule and either fix the plan or escalate to the user. Rules #10 and #11 are conditionally applicable (their trigger condition is part of the rule); when the condition does not hold they pass vacuously with a logged note — they never silently skip.

Run each check, list pass/fail in the output table. A failing rule is a blocker the gate must surface even if the LLM dimensional score is high.

Step 3 — Combined gate

overall_score = min(weighted_LLM_score, max_allowed_by_rule_checks)
where max_allowed_by_rule_checks = 100% if all rules pass, else 89%

The intent: a plan that scores 95% on LLM judgment but fails rule check #4 (references a file path that doesn't exist) is capped at 89% — and the gate fails. This catches the failure mode where the model is confident but the plan is grounded in hallucinated paths.

For code mode

For analysis mode

Use this mode whenever the artifact being graded is an analysis — a root-cause write-up, a refactor rationale, a /create-skill diagnose proposal, a holistic re-analysis after a stuck loop, or any other reasoning artifact that precedes a proposed change.

Output Format

You MUST output in this exact format:

## Confidence: X%

### LLM dimensional scoring

| Dimension | Score | Notes |
|-----------|-------|-------|
| <dim 1>   | X%    | ...   |
| <dim 2>   | X%    | ...   |
| <dim 3>   | X%    | ...   |

### Deterministic rule checks (plan mode only — omit for code/analysis)

| # | Rule                | Status      | Evidence                  |
|---|---------------------|-------------|---------------------------|
| 1 | <rule description>  | ✓ pass / ✗ fail | <command output snippet> |
| ... |                   |             |                           |

### Combined gate

- Weighted LLM score: X%
- Rule checks: <N pass> / <total> (cap: 100% if all pass, else 89%)
- **Final: X%**

Calculate the weighted LLM score as a weighted average using the dimension weights above. For plan mode, the Final is min(weighted_LLM_score, rule_check_cap). For code and analysis modes (including invocations via the deprecated bug-analysis alias), omit the rule-check section and Final = weighted_LLM_score.

Be honest and critical — do not inflate scores. A low score with clear reasoning is more valuable than a false 95%. A failed rule check is non-negotiable — surface it even if the LLM score is high.

Score Thresholds

Iteration Protocol (plan mode)

When used as a quality gate before autonomous execution:

If confidence is below 90%, do up to 2 iterations of additional research, analysis, and evidence collection to raise the score. After each iteration, re-run the confidence assessment. If still below 90% after 2 iterations, present findings to the user and ask whether to proceed or refine further.

Auto-Fix (Fix Mode Only)

Skip this section entirely if not in Fix Mode.

When running in Fix Mode (plan fix, code fix, analysis fix — or the deprecated bug-analysis fix alias), automatically address every concern that lowered your score:

Simple Fixes (apply immediately)

Fix these without asking — they are low-risk and mechanical:

• Missing edge case handling with obvious implementation
• Missing null/undefined checks
• Off-by-one errors or incorrect boundary conditions
• Typos in strings, comments, or variable names
• Missing return types or type annotations where the type is clear
• Small logic errors with an unambiguous correction
• (plan mode) Missing sections, incomplete requirements, vague implementation steps

After applying each fix, briefly note what was changed (one line per fix).

Complex Fixes (plan, then apply)

For issues requiring more thought:

• Missing test coverage for uncovered paths
• Incomplete implementations (missing cases, unhandled states)
• Architectural concerns or incorrect abstractions
• (plan mode) Fundamental approach issues, missing technical design

For each, output:

### [Issue title]
**Why:** [1-sentence explanation]
**Fix plan:**
1. [Step 1]
2. [Step 2]
**Files involved:** [list]

Then execute the plan.

Post-Fix Re-Assessment

After all fixes are applied:

1. Re-run the confidence assessment with updated scores
2. List what was fixed and how each fix improved the score
3. If confidence is still below 90%, list remaining concerns that could not be auto-fixed