01
What this skill does
Use this skill for strict maintainability review. It writes a Markdown report, uses 350 lines as a trigger for cohesion, dependency, and ownership analysis, and sweeps structural candidates until coverage reaches a fixed point or is marked incomplete. The trigger calls for boundary diagnosis. Review-only requests end at the report; already-authorized repairs continue after the report is preserved. Invocation is explicit-only: a user must invoke `$thermo-review`; matching prompts do not activate it automatically.
02
When to use it
- 01Reviewing whether a diff makes the implementation more tangled, oversized, indirect, or hard to extend.
- 02Finding missed code-judo simplifications, cohesive responsibility splits, canonical-ownership moves, and clearer type boundaries.
- 03Producing a durable structural review artifact with findings, recursive coverage, line-count evidence, and residual blind spots.
03
How it works
- 01
Set the review scope and baseline, preferring staged changes before the working tree when the user does not name a scope.
- 02
Build a diff and line-count inventory; for 350-line candidates, map responsibilities, dependency seams, and canonical owners.
- 03
Seed a recursive candidate frontier from file growth, branches, helpers, abstractions, types, ownership boundaries, orchestration, tests, and duplicated blocks.
- 04
Trace each candidate inward and outward through local flow, call sites, contracts, tests, and canonical helpers.
- 05
Append newly discovered simplification candidates until the frontier reaches a fixed point or uncovered areas are explicitly marked.
- 06
Preserve a Markdown report with findings, decomposition gaps, coverage, and evidence, then follow the requested review-only or repair outcome.
04
What you get back
- 01A Markdown thermo-nuclear code-quality report.
- 02A short terminal summary with recommendation, completion status, severity counts, and top structural risks.
- 03A recursive coverage ledger, line-count ledger, candidate sweep log, and quality-gate recommendation.
05
Important boundaries
- 01Keep the review phase read-only; a completed report permits repairs only within existing user authorization.
- 02Do not treat passing tests as proof that the implementation is structurally sound.
- 03Do not silently waive a 350-line structural candidate; account for the boundary or mark the area uncovered.
- 04Do not accept dense formatting, arbitrary relocation, or another count-only tactic as a threshold remedy.
- 05Use `code-review` instead when correctness, security, privacy, data loss, or merge safety is the main question.
06