improve-codebase-architecturelisted

> Source: [mattpocock/skills — engineering/improve-codebase-architecture](https://github.com/mattpocock/skills/tree/main/skills/engineering/improve-codebase-architecture) # 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 **why-not-mechanizable:** skill workflow guidance; each step requires understanding the surrounding context (repo, task shape, prior state). Use these terms exactly in every suggestion. Consistent language is the point — don't drift into "component," "service," "API," or "boundary." Full definitions in [LANGUAGE.md](LANGUAGE.md). - **Module** — anything with an interface and an implementation (function, class, package, slice). `(review-time: see section note)` - **Interface** — everything a caller must know to use the module: types, invariants, error modes, ordering, config. Not just the type signature. `(review-time: see section note)` - **Implementation** — the code inside. `(review-time: see section note)` - **Depth** — leverage at the interface: a lot of behaviour behind a small interface. **Deep** = high leverage. **Shallow** = interface nearly as complex as the implementation. `(review-time: see section note)` - **Seam** — where an interface lives; a place behaviour can be altered without editing in place. (Use this, not "boundary.") `(review-time: see section note)` - **Adapter** — a co