Improve Codebase Architecture

This skill exists to stop: broad refactors from being proposed without scoped architecture evidence, ranked candidates, or a clear decision owner.

🤖 0. HOW TO USE

• Discover (default): inspect a named area or recent hot spot, then rank deepening candidates in the HTML report.
• Review: test one proposed candidate against boundaries, locality, leverage, deletion evidence, and existing ADRs.
• Handoff: transfer an unsettled decision, accepted behavior change, or accepted cleanup using the canonical routing artifact.

Output: an evidence-backed candidate report. Discovery ranks possibilities; it does not silently accept product behavior, public contracts, migrations, or cleanup authority.

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:

• Run the /codebase-design skill 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 — don't drift into "component," "service," "API," or "boundary."
• Read engineering-philosophy.md when package/module ownership, placement, names, types, or dependency direction are part of the friction.
• The domain language in CONTEXT.md gives names to good seams; ADRs in .jimmy/adr/ record decisions this command should not re-litigate.