Architecture Audit

Audit a codebase for architectural friction and propose refactors toward deep modules (simple interface, large implementation). Deep modules are more testable, more AI-navigable, and let you test at the seam instead of inside.

Uses the deep-module vocabulary and principles — call the Skill tool with codebase-design for the canonical glossary (module, interface, depth, seam, adapter, leverage, locality) and core principles (deletion test, interface-as-test-surface, one-adapter-is-hypothetical). Use those terms exactly in every suggestion. For audit-specific examples and anti-patterns (pass-through, temporal decomposition, classitis, signs a module is too shallow), see references/deep-modules.md.

Workflow

1. Explore

Scope first (YAGNI). Deepening pays off where code keeps changing. A direction in $ARGUMENTS (module, subsystem, pain point) → take it. Otherwise read a good stretch of git log --oneline for hot spots, the files and areas that keep coming up, and start there; no clear hot spot → widen the net. Read the ADRs in the area: a candidate an ADR already rejected comes back only when the friction is worth reopening it.

Use a read-only explore subagent to navigate the codebase organically. Note where you experience friction: