← ClaudeAtlas

architecture-auditlisted

Surface architectural friction across a codebase and propose refactors toward deep modules as RFCs. Use when asked to audit architecture, find structural friction, or spot refactor opportunities. Don't use for one module's interface (/codebase-design) or a diff (/code-review).
helderberto/agent-skills · ★ 16 · Code & Development · score 81
Install: claude install-skill helderberto/agent-skills
# 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 — see [codebase-design](../codebase-design/SKILL.md) 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](references/deep-modules.md). ## Workflow ### 1. Explore Use the Agent tool with subagent_type=Explore to navigate the codebase organically. Note where you experience friction: - Understanding one concept requires bouncing between many small **modules** - A module's **interface** is nearly as complex as its **implementation** (shallow module) - Pure functions extracted just for testability, but real bugs hide in how they're called - Tightly-coupled modules create integration risk at the **seams** between them - A module fails the **deletion test** — deleting it makes complexity vanish (pass-through), or its complexity is duplicated across N callers (earning its keep but in the wrong place) - Areas that are untested or hard to test The friction