Improve Codebase Architecture

Surface architectural friction and propose deepening opportunities — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.

Glossary

Use the vocabulary and principles from codebase-design. Do not drift into "component," "service," "API," or "boundary."

This skill is informed by the project's domain model — CONTEXT.md and any docs/adr/. The domain language gives names to good seams; ADRs record decisions the skill should not re-litigate. See CONTEXT-FORMAT.md and ADR-FORMAT.md.

Process

1. Explore

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 — the files and areas that keep coming up — and let those paths pull your attention first. If the changes are scattered with no clear hot spot, widen the net.