Skip to main content

confidence-check

Pre-implementation validation requiring ≥90% confidence before coding. Prevents wrong-direction work by assessing duplicates, architecture alignment, and root cause understanding.

Ir para a instalação

Informações da origem

Repositório
kimasplund/clawdbot-skills-pack
Última atividade na origem
26 de janeiro de 2026 às 09:44
Idioma detectado do SKILL.md
inglês
Estrelas
0
Forks
0

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
confidence-check
description
Pre-implementation validation requiring ≥90% confidence before coding. Prevents wrong-direction work by assessing duplicates, architecture alignment, and root cause understanding.
metadata
{"clawdbot":{"requires":{"env":"[Truncated]"}}}
user-invocable
true
# Confidence Check Pre-implementation validation framework. **Never code at < 90% confidence.** ## Why This Matters Wrong-direction work costs 5K-50K tokens to undo. A 2-minute confidence check saves hours of rework. ## The 90% Rule Before implementing ANY significant change: ``` Confidence < 70% → STOP. Research more. Confidence 70-89% → PAUSE. Fill gaps first. Confidence ≥ 90% → PROCEED with implementation. ``` ## Confidence Checklist ### 1. Duplicate Check (20 points) - [ ] Searched codebase for existing solution - [ ] Checked if similar pattern exists elsewhere - [ ] Verified not reinventing existing functionality ### 2. Architecture Alignment (20 points) - [ ] Understand where this fits in the system - [ ] Know which files/modules are affected - [ ] Approach matches existing patterns ### 3. Requirements Clarity (20 points) - [ ] Clear on what success looks like - [ ] Understand edge cases - [ ] Know acceptance criteria ### 4. Root Cause Understanding (20 points) - [ ] If fixing bug: know WHY it happens - [ ] If adding feature: know WHY it's needed - [ ] Understand the problem, not just symptoms ### 5. Implementation Path (20 points) - [ ] Know the steps to implement - [ ] Identified potential blockers - [ ] Have fallback approach ## Scoring ``` Score each category 0-20: - 0-5: No understanding - 6-10: Partial understanding - 11-15: Good understanding, some gaps - 16-20: Full understanding Total = sum of all categories (0-100) ``` ## Output Template ```markdown ## Confidence Check: [Task] ### Assessment | Category | Score | Notes | |----------|-------|-------| | Duplicate Check | /20 | | | Architecture | /20 | | | Requirements | /20 | | | Root Cause | /20 | | | Implementation | /20 | | | **TOTAL** | **/100** | | ### Gaps Identified - [ ] [gap 1 - how to fill] - [ ] [gap 2 - how to fill] ### Verdict **[PROCEED / RESEARCH MORE / STOP]** ### If RESEARCH MORE: 1. [specific question to answer] 2. [file to read] 3. [person to ask] ``` ## Quick Check (30 seconds) For small changes, ask yourself: 1. Have I read the code I'm changing? (Y/N) 2. Do I know why this change is needed? (Y/N) 3. Do I know how to test it works? (Y/N) All Y → Proceed Any N → Pause and fill the gap ## When to Skip - Typo fixes - Comment updates - Obvious one-liners - Explicitly requested by user with full context ## Anti-Patterns ❌ "I'll figure it out as I go" ❌ "This looks similar to something I did before" ❌ "The user asked for it so it must be right" ❌ "I'll just try this and see" ✅ "I understand the problem and solution" ✅ "I've verified no existing solution" ✅ "I know exactly what files to change"
Ver no GitHub