confidence-check

name: confidence-check description: Pre-implementation confidence assessment (≥90% required). Verifies duplicate check, architecture compliance, official docs, OSS references, root cause understanding. Keywords: confidence, check, verify, before, implement.

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

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