confidence-check

Purpose

Prevent costly wrong-direction work by assessing implementation readiness before starting. Spend 100-200 tokens on assessment to save 5,000-50,000 tokens on misdirected implementation.

When to Apply

• Before implementing new features
• Before significant refactoring
• Before fixing complex bugs
• When requirements seem ambiguous
• Keywords: implement, build, create, add feature, refactor

The 5-Check Assessment

Evaluate each criterion and calculate a weighted confidence score:

| Check | Weight | What to Verify | |-------|--------|----------------| | No Duplicates | 25% | Search codebase for existing functionality | | Pattern Compliance | 25% | Aligns with MVVM, Coordinator, @Injected DI | | Documentation Verified | 20% | Checked middleware, protobuf, existing services | | Design System Applied | 15% | Uses Loc.*, Color.*, Image(asset:) | | Root Cause Clear | 15% | Understand actual problem vs symptoms |

Decision Thresholds

Score >= 90%  -->  PROCEED with implementation
Score 70-89%  -->  PAUSE - present alternatives, ask clarifying questions
Score < 70%   -->  STOP - request more context before proceeding

How to Score

Check 1: No Duplicates (25%)

Before implementing, search for existing solutions:

# Search for similar functionality
rg "similar_function_name" --type swift
rg "RelatedClass" --type swift

Pass: No existing implementation found, or existing code needs extension Fail: Duplicate functionality exists that should be reused

Check 2: Pattern Compliance (25%)

Verify alignment with project architecture:

• [ ] Using MVVM pattern (ViewModel + View separation)
• [ ] Coordinator for navigation (not direct NavigationLink)
• [ ] @Injected for dependency injection
• [ ] @MainActor on ViewModels
• [ ] Repository pattern for data access

Pass: Planned approach follows all relevant patterns Fail: Proposed solution violates established patterns

Check 3: Documentation Verified (20%)

Confirm understanding of existing systems:

• [ ] Checked relevant service layer code
• [ ] Reviewed middleware/protobuf definitions if applicable
• [ ] Read existing related ViewModels/Coordinators
• [ ] Understood data flow

Pass: Have concrete evidence from code exploration Fail: Assumptions without code verification

Check 4: Design System Applied (15%)

Verify UI implementation uses project standards:

• [ ] Localization: Loc.keyName (not hardcoded strings)
• [ ] Colors: Color.Text.primary, Color.Shape.* (not custom colors)
• [ ] Icons: Image(asset: .X24.iconName) (not SF Symbols)
• [ ] Typography: Design system text styles

Pass: All UI elements use design system Fail: Custom colors, hardcoded strings, or non-standard icons

Check 5: Root Cause Clear (15%)

Ensure you understand the actual problem:

• [ ] Can explain why the current behavior is wrong
• [ ] Identified where the issue originates (not just symptoms)
• [ ] Understand the expected behavior clearly

Pass: Can articulate problem and solution clearly Fail: Only treating symptoms or unclear on requirements

Example Assessment

Task: Add a new settings toggle for notification preferences

CHECK 1 - No Duplicates: [PASS - 25%]
  - Searched: rg "notification.*toggle" --type swift
  - Found: No existing toggle, only NotificationService

CHECK 2 - Pattern Compliance: [PASS - 25%]
  - Will use SettingsViewModel (existing)
  - Will extend SettingsCoordinator for new screen
  - Will inject NotificationService via @Injected

CHECK 3 - Documentation Verified: [PASS - 20%]
  - Reviewed SettingsViewModel.swift
  - Checked NotificationService protocol
  - Confirmed UserDefaults storage pattern

CHECK 4 - Design System Applied: [PASS - 15%]
  - Will use Loc.Settings.notifications
  - Will use Toggle from DesignSystem
  - Will use Color.Text.primary

CHECK 5 - Root Cause Clear: [PASS - 15%]
  - Users need granular notification control
  - Currently only global on/off exists
  - Need per-category toggles

TOTAL SCORE: 100%  -->  PROCEED

Quick Checklist Format

For faster assessment, use this condensed format:

CONFIDENCE CHECK:
[ ] No duplicates found (25%)
[ ] Follows MVVM/Coordinator/DI patterns (25%)
[ ] Verified existing code/docs (20%)
[ ] Uses Loc/Color/Image design system (15%)
[ ] Root cause understood (15%)

Score: ___% --> [PROCEED/PAUSE/STOP]

When to Skip

Skip confidence check for:

• Trivial changes (typos, simple renames)
• Direct user instructions with clear requirements
• Following up on already-verified implementation

ROI

| Scenario | Without Check | With Check | |----------|--------------|------------| | Duplicate implementation | 5,000+ tokens wasted | 100 tokens saved it | | Wrong architecture | 10,000+ tokens rework | 150 tokens caught early | | Missing context | 8,000+ tokens redoing | 200 tokens asked first |

Rule of thumb: If implementation will take >500 tokens, spend 100-200 on confidence check first.

---

Navigation: This skill integrates with ios-dev-guidelines and design-system-developer for pattern verification.