code-quality

Seven dimensions, each named for what it measures rather than the tool that measured it:

Dimension	The question it answers	Measured against	Filled by
Verified behaviour	how much of the code runs under test	the suite	/code-coverage
Test strength	would the tests catch a bug, or only run past it	the suite	/mutation-test
Change risk	which functions are dangerous to edit	the code, crossed with the suite	/crap-test
Specified behaviour	does the written spec hold	the suite	/to-bdd, /wire-bdd, /run-bdd
Construction	what is wrong with the code as written	the code	/static-analysis
Single source	is one piece of knowledge living in several places	the code, crossed with git history	/dry-test
Readability	can the next person read this and change it safely	the code, read as a reader	/clean-code

These are the seven a developer can answer without deploying anything. Every one is measured against the code or the suite, so all seven work on a laptop, on a branch, at module scope, in the middle of an afternoon. That is what makes this the set to keep green during development rather than at a release gate.

Two sets sit outside this skill. /release-quality covers the five that need a running system; /visual-quality the two that need a rendered interface. Name both at the end of the report so nobody reads seven green rows as a whole-system pass.

Each dimension alone is easy to misread — 90% coverage looks like health until the mutation score says the tests assert nothing. On a repo with no reports at all this skill does not stop at "unproven": it works out which dimensions the project should cover and hands over the command for each. Three rules hold throughout.

Relevance comes before measurement. Grading a project against dimensions it has no surface for manufactures failures and buries the real ones.

The verdict is a floor, not an average. Sound on six and fragile on the seventh is fragile.

Absent evidence is never good news. No report, a skipped one, and a stale one all read as unproven.

1. Find the reports

Search every .reports/ folder in the repository. The seven siblings write coverage-report-, mutation-report-, crap-report-, bdd-report-, static-analysis-report-, dry-report-, and clean-code-report-, timestamped, one file per run, per module. Take the newest of each kind, per module — on a fix run a sibling writes a before and an after, and the after is the one that describes the code as it stands.

Set your own past reports aside. code-quality-report-* files are this skill's own output and they are the comparison in step 6, never a dimension. Grading one as evidence pins the new run to the old floor, so a codebase that has improved keeps reporting last month's grade.

quality-report-* is this skill's former name, from before the twelve dimensions were split across three phases. Treat one as the comparison too, and say in step 6 that it graded a wider set — a verdict that looks worse beside it may only be a narrower one, which is exactly the widened-standard case that step warns about, running in reverse.

Leave the other two phases' reports alone as dimensions too. release-quality-report-*, visual-quality-report-*, and the five release and two visual sibling reports belong to /release-quality and /visual-quality. Note in step 5 that they exist — a security-report- sitting there is worth cross-reading — but never grade one here.

Read anything else in there too. A dependency audit, a benchmark, a type-check log, a complexity report: each becomes an extra dimension in step 4 rather than a file you stepped over.

Done when: you have every report found with its kind, module, timestamp, and the commit named in its header; a list of the seven kinds that turned up nothing; the newest code-quality-report-* held aside as the comparison rather than counted as a dimension; and any release or visual reports noted as cross-reading material rather than as dimensions.