Tech Debt Map

Produce a debt map for one module: a ranked, evidence-backed list of what is worst about that module right now, and a plan to fix it a slice at a time.

One module per run, on purpose. A map of a whole project is a map nobody works through, and a refactor that spans everything is a refactor nobody starts. The project gets covered over time instead, module by module, and a committed review index remembers when each one was last looked at.

The map is a diagnosis, not a refactor. No code changes during this skill. What you hand back is a file the user works through over weeks, and re-runs against later to see what moved.

Two neighbours to stay out of the way of: /improve-codebase-architecture hunts one class of problem (shallow modules) and ends in a grilling session about a single candidate; /review-axes judges a diff. This one sweeps one module across every axis and ends in a written map.

Process

1. Map the modules

Before anything can be reviewed, the project has to be cut into modules. Some projects have already done it; many have not.

Detect in this order, stopping at the first that yields a real partition: