excatt/skills/confidence-check

Dynamic Context

Project dependencies: !cat package.json 2>/dev/null | head -20 || cat pyproject.toml 2>/dev/null | head -20 || echo "No package manifest found"

Confidence Check Skill

Purpose

Assess confidence before implementation to prevent wrong-direction execution.

Requirement: ≥90% confidence needed to proceed with implementation

ROI: 100-200 token confidence check → prevents 5,000-50,000 token wrong-direction work

When to Use

Use before starting implementation work to verify:

• No duplicate implementation exists
• Architecture compliance confirmed
• Official documentation reviewed
• Working OSS implementation found
• Root cause properly understood

Confidence Assessment Criteria

Calculate confidence score (0.0 - 1.0) based on 5 checks:

1. No Duplicate Implementation? (25%)

Check: Search codebase for existing functionality

# Search for similar functions
grep -r "function featureName" src/
grep -r "def feature_name" src/

# Find related modules
find src/ -name "*feature*"

✅ Pass if no duplicate exists ❌ Fail if similar implementation found

2. Architecture Compliant? (25%)

Check: Verify tech stack alignment

• Read CLAUDE.md, package.json, requirements.txt
• Verify using existing patterns
• Avoid reinventing existing solutions

# Check tech stack
cat package.json | grep -E "(supabase|prisma|firebase|next)"

✅ Pass if using existing tech stack (e.g., Supabase, UV, pytest) ❌ Fail if introducing unnecessary new dependencies

3. Official Docs Checked? (20%)

Check: Review official documentation before implementation

• Query official docs with Context7 MCP
• Access documentation URLs with WebFetch
• Verify API compatibility

✅ Pass if official docs reviewed ❌ Fail if relying on assumptions

4. Working OSS Implementation Referenced? (15%)

Check: Find proven implementation

• Use Tavily MCP or WebSearch
• Search GitHub for examples
• Verify working code samples

✅ Pass if OSS reference found ❌ Fail if no working example exists

5. Root Cause Understood? (15%)

Check: Understand actual problem

• Analyze error messages
• Check logs and stack traces
• Identify root issue

✅ Pass if root cause clear ❌ Fail if symptoms unclear

---

Confidence Score Calculation

Total = Check1 (25%) + Check2 (25%) + Check3 (20%) + Check4 (15%) + Check5 (15%)

If Total >= 0.90:  ✅ Proceed with implementation
If Total >= 0.70:  ⚠️  Suggest alternatives, ask questions
If Total < 0.70:   ❌ STOP - Request more context

---

Output Format

High Confidence (≥90%)

📋 Confidence Checks:
   ✅ No duplicate implementation
   ✅ Using existing tech stack
   ✅ Official docs verified
   ✅ Working OSS implementation found
   ✅ Root cause understood

📊 Confidence: 1.00 (100%)
✅ High confidence - proceed with implementation

Medium Confidence (70-89%)

📋 Confidence Checks:
   ✅ No duplicate implementation
   ✅ Using existing tech stack
   ⚠️  Official docs partially verified
   ❌ OSS implementation not found
   ✅ Root cause understood

📊 Confidence: 0.75 (75%)
⚠️  Medium confidence - suggest alternatives

💡 Options:
1. JWT-based auth (recommended) - matches existing pattern
2. OAuth integration - requires additional setup
3. Session-based - legacy approach

Which direction should we proceed?

Low Confidence (<70%)

📋 Confidence Checks:
   ❌ Duplicate check failed - search needed
   ⚠️  Architecture unclear
   ❌ Official docs not verified
   ❌ No OSS reference
   ❌ Root cause unclear

📊 Confidence: 0.45 (45%)
❌ Low confidence - STOP

❓ Need following information to proceed:
1. Should we use JWT or OAuth for authentication?
2. What's the expected session timeout?
3. Is 2FA support required?

Please guide so we can proceed with confidence.

---

Workflow Integration

Before Any Implementation

User request received
    │
    ▼
┌─────────────────────┐
│  /confidence-check  │
└─────────────────────┘
    │
    ├─→ ≥90%: Proceed with implementation
    │
    ├─→ 70-89%: Suggest alternatives → User choice → Proceed
    │
    └─→ <70%: STOP → Ask questions → Wait for answers → Reassess

With /feature-planner

/confidence-check        # Check confidence first
    │
    └─→ ≥90%
          │
          ▼
/feature-planner        # Create plan
    │
    ▼
Proceed with implementation

With /verify

/confidence-check       # Pre-implementation confidence
    │
    ▼
Implementation work
    │
    ▼
/verify                 # Post-implementation verification

---

Check Implementation Details

Check 1: Duplicate Search

# Search by function name
grep -rn "function ${feature_name}" src/
grep -rn "def ${feature_name}" src/
grep -rn "const ${feature_name}" src/

# Search by filename
find . -name "*${feature}*" -type f

# Search by class name
grep -rn "class ${FeatureName}" src/

Check 2: Architecture Verification

# Check tech stack in package.json
cat package.json | jq '.dependencies'

# Check architecture guide in CLAUDE.md
cat CLAUDE.md | grep -A 10 "Architecture"

# Check existing patterns
ls -la src/

Check 3: Documentation Review

# Query official docs with Context7 MCP
# Access documentation URLs with WebFetch
# Check README and internal docs

Check 4: OSS Reference Search

# GitHub search
# Search implementation examples with Tavily/WebSearch
# Check npm/pip packages

Check 5: Root Cause Analysis

# Analyze error logs
# Review stack traces
# Verify reproduction steps

---

Commands

| Command | Description | |---------|-------------| | /confidence-check | Full confidence assessment | | /confidence-check --quick | Quick check (1, 2 only) | | /confidence-check --verbose | Detailed output for each check |

---

Best Practices

Always Use When

• Before implementing new feature
• Before fixing bug (understand root cause)
• Before refactoring (verify architecture)
• Before external API integration

Can Skip When

• Fixing typo
• Adding comment
• Formatting change
• Simple config change

Red Flags

If tempted to proceed with low confidence:

• 🚩 "Probably fine" - need verification
• 🚩 "No time" - wrong direction wastes more time
• 🚩 "Fix it later" - accumulates tech debt