name code-foundations description Classify code tasks and execute task-specific checklists with quality gates. Route to WRITE, DEBUG, REVIEW, OPTIMIZE, REFACTOR, SIMPLIFY, or SECURE workflows, each invoking relevant CC and APOSD skills. Produce classification statement plus DONE/NOT DONE verdict with mandatory pre-commit verification. Use when writing, debugging, reviewing, fixing, implementing, optimizing, refactoring, simplifying, or securing code. Triggers on: implement, build, create, debug, fix bug, broken, error, review, audit, optimize, slow, performance, refactor, clean up, simplify, confusing, too complex, secure, vulnerability.
Code Foundations
When in doubt, load this skill. When NOT in doubt, load it anyway.
Master Checklist: Execute In Order
Phase 1: Classification (MANDATORY - Do First)
1.1 Identify task type from user signals:
Signal Task Type "implement", "write", "build", "add", "create" → WRITE "debug", "fix bug", "failing", "broken", "error" → DEBUG "review", "check", "audit", "is this good?" → REVIEW "optimize", "slow", "performance", "faster" → OPTIMIZE "refactor", "clean up", "improve structure" → REFACTOR "simplify", "too complex", "confusing" → SIMPLIFY "secure", "vulnerability", "validate input" → SECURE
1.2 State classification: "This is a [TASK TYPE] task"
1.3 If ambiguous, ask: "Are you looking for [option A], [option B], or something else?"
Phase 2: Mindset Check (For WRITE, DEBUG, REFACTOR)
Phase 2.5: Pattern Reuse Gate (For WRITE, DEBUG, REFACTOR, SECURE)
MANDATORY: Before implementing, search the codebase.
If Then Pattern exists and is good Follow it exactly Pattern exists but mediocre Follow anyway (consistency > perfection) Pattern exists but bad Document why diverging, consider fixing globally No pattern exists You're establishing one - be deliberate
See: pattern-reuse-gate.md
Phase 3: Execute Task-Specific Checklist
Go to the checklist for your task type:
Phase 4: Pre-Commit Gate (MANDATORY - Before "Done")
WRITE Checklist
Goal: Create new code with good design
Prerequisites
Design Phase
Implementation Phase
Verification Phase (Parallel Subagents)
See references/checker-dispatch.md
Pre-Commit
DEBUG Checklist
Goal: Find and fix bug without making design worse
Investigation Phase
Fix Phase
Verification Phase
Pre-Commit
REVIEW Checklist
Goal: Detect design problems and complexity
CHECKER pattern: See references/checker-dispatch.md
Quick Checks (Inline)
Complexity Symptoms:
Module Depth:
Red Flags:
Full Checklists (Parallel Subagents)
Output
OPTIMIZE Checklist
Goal: Improve performance based on measurement, not intuition
Measurement Gate (MANDATORY)
Fundamental Fixes (Try First)
Critical Path Redesign (Last Resort)
Verification
Pre-Commit
REFACTOR Checklist
Goal: Improve structure without changing behavior
Prerequisites
Planning
Execution (One At A Time)
Verification (Parallel Subagents)
See references/checker-dispatch.md
Quick Checks:
Pre-Commit
SIMPLIFY Checklist
Goal: Reduce complexity, not just relocate it
Analysis
Error Reduction Hierarchy (Apply In Order)
For each error condition:
Pull Complexity Down (Check All Three)
Verification
Pre-Commit
SECURE Checklist
Goal: Protect against malicious or malformed input
Analysis (Parallel Subagents)
See references/checker-dispatch.md
Identify:
Validation (For Each External Input)
Error Handling
Pre-Commit
Rationalization Red Flags
If you think any of these, STOP and apply the checklist anyway:
Thought Reality "This is simple/trivial" Simple tasks have HIGHEST error rates "I can already see the issue" Seeing ≠ systematic verification "I already know how to do this" Knowing ≠ executing checklist "It's just config, not code" Config that affects runtime IS code "The code already works" Your CHANGE can break what worked "I'll refactor later" Later = never "Just make it work" Tactical thinking → permanent slowdown "I don't have time" Checklist takes minutes; debugging takes hours "It's just one line" One-line changes have highest error rate "Tests pass, so it's done" Tests check behavior, not design quality
Crisis Mode (Production Down)
You STILL must:
What you may NOT skip:
Input validation on external data
Verifying fix actually works
One sentence explaining WHY the fix works
Two Skill Families
Family Source Focus Prefix Code Complete McConnell Process rigor, metrics, checklists cc-*APOSD Ousterhout Design philosophy, complexity reduction aposd-*
Use both. CC provides tactical rigor; APOSD provides strategic philosophy.
Quick Reference: All Skills
CC Skills (Process & Metrics)
Skill Use For cc-developer-character Mindset check before WRITE/DEBUG/REFACTOR cc-construction-prerequisites Architecture ready before coding cc-pseudocode-programming Design-before-code cc-routine-and-class-design Cohesion, coupling, inheritance cc-defensive-programming Error handling, validation cc-refactoring-guidance Safe refactoring process cc-quality-practices Testing, debugging, reviews cc-control-flow-quality Nesting, complexity, loops cc-data-organization Variables, types, data structures cc-code-layout-and-style Formatting, visual structure cc-performance-tuning Optimization process cc-integration-practices Build, integration
APOSD Skills (Design Philosophy)
Skill Use For aposd-designing-deep-modules Interface design, design-it-twice aposd-simplifying-complexity Error reduction, pull-down technique aposd-improving-code-clarity Comments-first, naming aposd-maintaining-design-quality Strategic vs tactical mindset aposd-reviewing-module-design Complexity symptoms detection aposd-optimizing-critical-paths Measure-first optimization aposd-verifying-correctness Pre-commit verification
Shared Reference
