19 software engineering skills from Code Complete, APOSD, GoF, and Clean Architecture, driving a research → plan → build workflow: per-phase gates (Full | Standard | Minimal) that set review timing rather than review existence, batched cross-phase review on a configurable cadence, Fable/Sonnet 5 model ladder with…
Discovery, design, and implementation in one pass. Scopes phase work, makes design decisions, stubs the interface, implements it, then validates with tests.
Independent, execution-grounded review of a build phase against its done-when requirements. Runs the suite first, verifies each requirement with evidence and a trace, returns PASS or FAIL with specific findings.
Placeholder skill directory required by skill-eval's runeval tool signature. This benchmark runs configurations=['withoutskill'] only — we are measuring raw model tiers, not a skill — so this file's content is never mounted or read by a subject session.
Implements a coding task from a written spec with Done-When acceptance items. Use when given a spec to implement: stub the interface, implement it, then write tests that validate the Done-When items and any important behavior beyond them.
Implements a coding task from a written spec with Done-When acceptance items. Use when given a spec to implement: for each Done-When item, write a failing test first, then the minimum code to make it pass (red-green).
Execute an approved plan through gated phases (BUILD → REVIEW → commit) with subagent dispatch. Use when a plan exists in .code-foundations/plans/ and the user wants it implemented — phased implementation, per-phase quality gates, orchestrator commits, and a final trust report.
Runs the scientific debugging method on an active bug — reproduce, locate, hypothesize, fix, verify, search for siblings. Use to chase a failing test, a flaky or intermittent failure, a crash, or any 'why is this broken' investigation, or to audit whether a debugging session was systematic.
Turn a feature request or research doc into a phased, build-ready implementation plan. Use after research, or whenever a change needs decomposition into phases with skills, models, and gates before building.
Guides module and API design using APOSD principles: generates multiple design alternatives, compares them on information hiding and interface depth, and produces a documented design decision. For creating new module/API design; not for assessing existing designs (use aposd-reviewing-module-design) or routine-level…
Assesses existing module and interface design for complexity symptoms: information leakage, shallow interfaces, pass-through layers, and unknown unknowns. Produces a structured assessment — not transformations (use aposd-simplifying-complexity to edit) and not new-design generation (use aposd-designing-deep-modules).
Transforms complex code by applying APOSD's pull-complexity-downward principle: resolves error hierarchies, collapses configuration, and moves caller-side logic into modules. Produces edited code; not for assessment-only review (use aposd-reviewing-module-design) or designing new modules from scratch (use…
Verifies implementation completeness across functional correctness, error handling, concurrency, and security dimensions using APOSD's post-implementation checklist. Run after a coding task is nominally complete, not during active bug investigation (use cc-debugging).
Applies Clean Architecture's dependency-direction and SRP-by-actor rules to system-level boundary design: separates business logic from infrastructure, identifies actor-coupling risks, and enforces inward-pointing dependency arrows. For system scope (multiple components, layers, or services), not routine or module…
Audits and restructures control flow using Code Complete's nesting, cyclomatic complexity, loop design, guard-clause, and boolean simplification rules. Covers deep nesting, loop exit design, index naming, and callback chains. For statement-level flow inside a routine; not for routine/class structure (use…
Applies Code Complete's scientific debugging method: STABILIZE → LOCATE → HYPOTHESIZE → EXPERIMENT → FIX → TEST → SEARCH. For active bug investigation, not QA process design or test coverage planning (use cc-quality-practices).
Applies Code Complete's defensive programming rules: barricade design, assertion vs error-handling selection, input validation policy, and correctness-vs-robustness strategy for the current context. For hardening code at trust boundaries; not for diagnosing an active failure (use cc-debugging) or post-completion…
Structures routine design through pseudocode-first iteration: clarifies naming and purpose before any code, catches design flaws cheaply, and prevents compile-debug loops on poorly understood routines. For designing a routine before writing it; not for assessing routines that already exist (use…
Applies Code Complete's QA process design: selects defect-detection techniques by phase, sizes the test suite, and designs review and inspection processes. For QA planning and process design, not active bug investigation (use cc-debugging).
Guides safe refactoring using Code Complete's fix-first-then-refactor discipline: decides between refactor, rewrite, and fix-first; enforces separate commits; applies small-change rigor to high-error-rate one-liners. Not for diagnosing the bug itself (use cc-debugging), transforming working code's complexity (use…
Applies Code Complete's routine and class design rules at the routine level: cohesion classification, parameter-count thresholds, LSP inheritance verification, and containment-vs-inheritance decision. For routine and class scope, not system architecture (use ca-architecture-boundaries).
Decomposes underspecified requests by classifying gaps (missing info, ambiguity, false premises) and generating targeted clarifying questions. Produces a confirmed problem statement before any implementation begins. For sharpening a request that already exists; not for open-ended requirement discovery from a vague…