improve-codebase-architecture

Topics in the source

• Improve Codebase Architecture
• Process
• 1. Explore
• 2. Present candidates as an HTML report
• 3. Grilling loop

Surface architectural friction and propose deepening opportunities: refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability. This command is informed by the project's domain model and built on a shared design vocabulary: Call the Skill tool with "codebase-design" for the architecture vocabulary (module, interface, depth, seam, adapter, leverage, locality) and its principles (the deletion test, "the interface is the test surface", "one adapter = hypothetical seam, two = real"). Use these terms exactly in every suggestion, and don't drift into "component," "service," "API," or "boundary." The domain language in GLOSSARY.md gives names to good seams; ADRs in docs/adr/ record decisions this command should not re-litigate. Scope before you scan: YAGNI. Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that have recently changed. Decide where to look before you look: If the user named a direction (a module, a subsystem, a pain point), take it, and skip the inference below. Otherwise, walk back a good stretch of the commit history (git log --oneline) to find the codebase's hot spots, t

This is an excerpt. Refer to the complete source and its current requirements.