Stats
Actions
Available In
Tags
Plugin
code-foundations
Guides structured software engineering via classic texts: research vague requests, build phased implementation plans with adaptive gates, then execute through build-review-commit cycles with agent dispatch. Covers design exploration, code auditing, refactoring, debugging, and test-first legacy modification.
What's Inside
Slash Commands4
Command: build
/build
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.
Command: debug
/debug
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.
Command: plan
/plan
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.
Command: research
/research
Extract and document what the user wants — even when they don't know yet. Use before plan, or standalone when exploring an idea.
Agents2
build-agent
/build-agent
Discovery, design, and implementation in one pass. Scopes phase work, makes design decisions, stubs the interface, implements it, then validates with tests.
post-gate-agent
/post-gate-agent
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.
Skills19
aposd-designing-deep-modules
/aposd-designing-deep-modules
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 design (use cc-routine-and-class-design).
aposd-reviewing-module-design
/aposd-reviewing-module-design
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).
aposd-simplifying-complexity
/aposd-simplifying-complexity
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 just assessment.
aposd-verifying-correctness
/aposd-verifying-correctness
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).
ca-architecture-boundaries
/ca-architecture-boundaries
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 scope (use cc-routine-and-class-design).
Stats
Version5.3.1
LanguagePython
Stars274
Forks24
Copy clicks1
MaintenanceExcellent
LicenseMIT
Last Commit
Added
Safety Signals
Caution
Uses power tools
Uses Bash, Write, or Edit tools
Tags
