Improve Codebase Architecture

Find code that is hard to follow or change because callers must coordinate details that belong together. Propose modules that hide those details and make the behavior easier to test.

When the user has already selected a candidate or concrete target change, inspect that target and proceed directly to exploring it. Do not produce another candidate menu or ask them to select it again. A named subsystem may instead limit discovery when the user is still asking which change would help.

This command is informed by the project's domain model and built on a shared design vocabulary:

• Consult the codebase-design skill when available for deep-module principles, caller contracts, and seam justification. Use its architectural distinctions alongside established product and repository vocabulary. Evaluate what an interface hides and what callers gain; adapter count alone does not justify or rule out a seam.
• The project's glossary gives names to good seams; its ADRs record settled decisions. Do not propose a change that reverses one unless the friction is strong enough to reopen the decision (see ADR conflicts below). Follow the existing documentation locations rather than assuming CONTEXT.md and docs/adr/.

Locate companion skills by name in the available skill catalog, using its supplied locations or loading mechanism. If one is unavailable, continue with the procedure here; do not infer its installation path or fetch external guidance.

Process

1. Explore

Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that change often. Choose the area before reading code: