ai-error-prevention

SKILL.md

Required Plugins

Superpowers plugin: MUST be active for all work using this skill. Use throughout the entire build pipeline β€” design decisions, code generation, debugging, quality checks, and any task where it offers enhanced capabilities. If superpowers provides a better way to accomplish something, prefer it over the default approach.

AI Error Prevention in Software Development

Overview

This skill teaches you to prevent errors BEFORE they happen when working with Claude to generate code. It focuses on minimizing wasted tokens, catching Claude's mistakes early, and ensuring production-ready output.

Documentation Structure (Tier 2 Deep Dives):


When to Use This Skill

Always use when:

  • Working with Claude to generate code
  • Building software with AI assistance
  • Want to minimize wasted tokens on wrong solutions
  • Need to catch Claude's mistakes early
  • Developing production-ready code with AI

This skill prevents errors BEFORE they happen.


The Core Problem

Traditional vs AI-Assisted Development

Traditional Development:
You write code β†’ Code fails β†’ You debug β†’ You fix

AI-Assisted Development:
You ask Claude β†’ Claude generates code β†’ Code might be:
β”œβ”€ Perfect βœ“
β”œβ”€ Partially wrong (hallucination)
β”œβ”€ Missing edge cases
β”œβ”€ Insecure
β”œβ”€ Inefficient
└─ Doesn't match your spec

YOU MUST: Verify, test, catch mistakes, know when to trust/distrust

Why Claude Can Fail

1. HALLUCINATION - Invents facts/APIs/methods that don't exist
2. INCOMPLETE SOLUTIONS - Solves 80%, misses the 20%
3. MISUNDERSTANDING - Misunderstood your requirement
4. OUTDATED KNOWLEDGE - Knows old way, not new way
5. CONTEXT LIMITS - Forgot earlier context
6. LAZY SOLUTIONS - Simplest answer, not best answer
7. WRONG ASSUMPTIONS - Assumes constraints you didn't mention

The 7 Prevention Strategies (Quick Reference)

πŸ“– See prevention-strategies.md for complete details with examples.

Strategy 1: Verification-First

Rule: NEVER accept code without verification

Claude generates β†’ YOU STOP β†’ Check:
β–‘ Matches requirement?
β–‘ Imports exist?
β–‘ Obvious bugs?
β–‘ Edge cases?
β–‘ Secure?
β†’ Pass? Use it | Fail? Ask Claude to fix

Strategy 2: Test-Driven Validation

Rule: Test Claude's code IMMEDIATELY

Claude generates β†’ YOU WRITE TESTS:
β–‘ Happy path
β–‘ Boundary cases
β–‘ Edge cases
β–‘ Error cases
β–‘ Security cases
β†’ Tests pass? Good | Tests fail? Fix

Strategy 3: Specification Matching

Rule: Make Claude review against spec

You have SPEC β†’ Claude generates β†’ ASK CLAUDE:
"Check this against requirements. Does it:
β–‘ Requirement 1?
β–‘ Requirement 2?
β–‘ Requirement 3?"
β†’ Gaps found? Fix | No gaps? Complete

Strategy 4: Incrementalism

Rule: Break big requests into small steps

❌ DON'T: Ask for complete feature (Claude gets 50% right)

βœ“ DO: Break into steps:
Step 1: Data model β†’ VERIFY βœ“
Step 2: Core function β†’ VERIFY βœ“
Step 3: Edge cases β†’ VERIFY βœ“
Step 4: Error handling β†’ VERIFY βœ“
Step 5: Integration β†’ VERIFY βœ“

Each step: 10-20 lines, easy to verify


Strategy 5: Dual Approach

Rule: Ask Claude to solve problem TWO ways

Ask Claude: "Solve problem X"
β†’ Claude gives Solution A

Ask Claude (new message): "Solve problem X differently"
β†’ Claude gives Solution B

COMPARE:
If A == B β†’ Probably correct
If A β‰  B β†’ One might be wrong
β†’ Ask Claude: "Compare. Which is better?"

Strategy 6: Fallback Code

Rule: Keep simple backup implementation

Claude generates: Complex optimized solution
YOU ALSO WRITE: Simple naive solution (Plan B)

try {
  return claudeSolution();  // Try Claude's
} catch {
  return simpleFallback();  // Use backup
}

Strategy 7: Documentation Validation

Rule: If Claude can't explain it, code might be wrong

Claude generates β†’ YOU ASK:
"Document this:
1. What it does
2. Inputs (with types)
3. Outputs (format)
4. Possible errors
5. Edge cases
6. Usage examples"

If Claude explains clearly β†’ Probably correct
If Claude struggles β†’ Code might be wrong

Common Claude Failure Modes (Summary)

πŸ“– See failure-modes.md for detailed prevention strategies.

Failure Mode 1: Incomplete Understanding

Problem: Claude implements basic version, misses critical parts
Prevention: Ask for COMPLETE spec first, verify before implementing

Failure Mode 2: Wrong Pattern/Approach

Problem: Claude chooses suboptimal approach
Prevention: Provide context (data patterns, usage, constraints)

Failure Mode 3: Hallucinated Libraries

Problem: Claude suggests library that doesn't exist
Prevention: Verify library exists (docs URL, version, install command)

Failure Mode 4: Misunderstood Requirement

Problem: Claude implements something different
Prevention: Provide examples and scenarios

Failure Mode 5: Lazy Solution

Problem: Claude gives simplest answer, misses edge cases
Prevention: Explicitly demand edge case handling with test cases

AI Development Error Prevention Framework

Complete Workflow:

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ PHASE 1: REQUEST PREPARATION        β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ β–‘ Use Clear Task pattern            β”‚
β”‚ β–‘ Include specific constraints      β”‚
β”‚ β–‘ Ask for structured output         β”‚
β”‚ β–‘ Show examples                     β”‚
β”‚ β–‘ Break into small steps            β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                ↓
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ PHASE 2: CLAUDE GENERATES           β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                ↓
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ PHASE 3: IMMEDIATE VERIFICATION     β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ β–‘ VERIFY: Match spec?               β”‚
β”‚ β–‘ READ: Imports exist?              β”‚
β”‚ β–‘ CHECK: Obvious bugs?              β”‚
β”‚ β–‘ ASK: "Document this"              β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                ↓
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ PHASE 4: TESTING                    β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ β–‘ Write tests (happy, edge, error)  β”‚
β”‚ β–‘ Run tests                         β”‚
β”‚ β–‘ If fails β†’ Back to Claude         β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                ↓
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ PHASE 5: QUALITY CHECKS             β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ β–‘ SECURITY: Vulnerabilities?        β”‚
β”‚ β–‘ PERFORMANCE: Bottlenecks?         β”‚
β”‚ β–‘ EDGE CASES: All handled?          β”‚
β”‚ β–‘ ERROR HANDLING: Clear messages?   β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                ↓
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ PHASE 6: ITERATION (if needed)      β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ If ANY check fails:                 β”‚
β”‚   β†’ Specific feedback to Claude     β”‚
β”‚   β†’ Claude fixes                    β”‚
β”‚   β†’ Return to Phase 3               β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                ↓
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ PHASE 7: ACCEPTANCE                 β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ All checks passed β†’ USE CODE βœ“      β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

App-Specific Prevention (Summary)

πŸ“– See app-specific-prevention.md for complete checklists.

MADUUKA (Franchise ERP)

High-Risk: Multi-tenancy, pricing, inventory, payments
Prevention:
β–‘ Explicitly require tenant isolation
β–‘ Provide pricing formulas with examples
β–‘ Test edge cases (discounts, taxes, stock)
β–‘ Verify tenant_id in ALL queries

MEDIC8 (Healthcare)

High-Risk: HIPAA, medication interactions, dosage calculations
Prevention:
β–‘ List HIPAA requirements explicitly
β–‘ Provide medication interaction rules
β–‘ Show dosage formulas with examples
β–‘ MANUAL REVIEW before production

BRIGHTSOMA (Education)

High-Risk: Curriculum alignment, grading fairness
Prevention:
β–‘ Provide curriculum reference
β–‘ Show grading rubric
β–‘ Define difficulty criteria
β–‘ Human review of first batch

DDA (Database Tool)

High-Risk: Schema compliance, data integrity
Prevention:
β–‘ Provide full schema
β–‘ Show realistic data examples
β–‘ Test referential integrity
β–‘ Backup before running

The Golden Rule

TRUST BUT VERIFY

βœ“ Trust Claude's speed
βœ“ Trust Claude's knowledge
βœ“ Trust Claude to explain

βœ— Don't trust without verification
βœ— Don't skip testing
βœ— Don't assume it's secure
βœ— Don't use without understanding

YOUR JOB: Skeptical, test, verify
CLAUDE'S JOB: Generate, explain, fix

Acceptance Checklist

Before accepting ANY code from Claude:

β–‘ REQUIREMENTS
  β–‘ Matches all requirements
  β–‘ Handles edge cases
  β–‘ Error cases handled

β–‘ VERIFICATION
  β–‘ Imports/libraries exist
  β–‘ No hallucinated APIs
  β–‘ Parses without errors

β–‘ TESTING
  β–‘ Happy path tested
  β–‘ Edge cases tested
  β–‘ Error cases tested
  β–‘ All tests passing

β–‘ SECURITY
  β–‘ No SQL injection
  β–‘ No XSS
  β–‘ No exposed secrets
  β–‘ Input validation present

β–‘ QUALITY
  β–‘ Readable
  β–‘ Documented
  β–‘ Follows patterns
  β–‘ No performance issues

β–‘ EXPLANATION
  β–‘ Claude can explain it
  β–‘ Edge cases explained
  β–‘ Assumptions documented
  β–‘ Usage examples provided

β–‘ INTEGRATION
  β–‘ Works with existing code
  β–‘ No conflicts
  β–‘ Error handling integrated
  β–‘ Logging present

If ALL checked β†’ Accept If ANY unchecked β†’ Back to Claude


Token Waste Prevention

How This Skill Saves Tokens:

WITHOUT prevention:
Request β†’ Wrong code β†’ Discover later β†’ Fix β†’ Still wrong β†’ Fix again
TOKENS WASTED: 4-5x

WITH prevention:
Request (clear spec) β†’ Generate β†’ Verify immediately β†’ Fix once
TOKENS USED: 1-2x

SAVINGS: 50-75% fewer tokens

Best Practices:

βœ“ Be specific (prevents misunderstanding)
βœ“ Verify immediately (catch errors early)
βœ“ Specific feedback (faster fixes)
βœ“ Small steps (easier to verify)
βœ“ Test each step (no cascading errors)

Integration with Other Skills

Use this skill WITH:

  • orchestration-best-practices - Structure in generated code
  • ai-error-handling - Validation after prevention
  • ai-assisted-development - Prevent errors across multiple agents
  • prompting-patterns-reference - Better requests = fewer errors

Workflow:

1. AI-ERROR-PREVENTION (this) β†’ Request correctly, verify immediately
2. ORCHESTRATION-BEST-PRACTICES β†’ Ensure code structure
3. AI-ERROR-HANDLING β†’ Final validation layers
4. AI-ASSISTED-DEVELOPMENT β†’ Coordinate multiple agents

Result: Minimal errors, maximum efficiency, lowest token waste

Summary

Core Concept: Prevent errors BEFORE they happen by changing HOW you interact with Claude

The 7 Strategies:

  1. Verification-First
  2. Test-Driven Validation
  3. Specification Matching
  4. Incrementalism
  5. Dual Approach
  6. Fallback Code
  7. Documentation Validation

5 Common Failures:

  1. Incomplete Understanding
  2. Wrong Pattern
  3. Hallucinated Libraries
  4. Misunderstood Requirement
  5. Lazy Solution

Result: 50-75% fewer tokens wasted, higher quality code, faster development

Next Steps:

  1. πŸ“– Read prevention-strategies.md for detailed strategy examples
  2. πŸ“– Read failure-modes.md for failure prevention
  3. πŸ“– Read app-specific-prevention.md for your app's checklist
  4. Apply to your next Claude request!

Related Skills:

  • orchestration-best-practices/ - Code structure enforcement
  • ai-error-handling/ - Validation after generation
  • ai-assisted-development/ - Multi-agent coordination
  • prompting-patterns-reference.md - Better prompts
  • encoding-patterns-into-skills.md - Creating pattern-enforcing skills

Last Updated: 2026-02-07 Line Count: ~481 lines (compliant)

Weekly Installs
4
GitHub Stars
3
First Seen
Feb 28, 2026
Installed on
gemini-cli4
opencode4
codebuddy4
github-copilot4
codex4
kimi-cli4