01
What this skill does
Use this skill for a user-visible behavior gate. It separates intended changes from regressions, uses scoped graphs when they clarify paths, and records findings and coverage. Simple paths can use direct traces and output comparisons. Review-only requests end at the report; authorized repairs continue after the report is preserved. Invocation is explicit-only: a user must invoke `$regression-review`; matching prompts do not activate it automatically.
02
When to use it
- 01Checking whether refactors or feature work broke user-facing flows.
- 02Auditing loading, error, permission, retry, ordering, export, email, or CLI-output changes.
- 03Tracing changed inputs, guards, transforms, and outputs without building a whole-repo call graph.
- 04Producing a review artifact with severity tied to the strongest unresolved finding.
03
How it works
- 01
Set or infer the review scope and read requirements when available.
- 02
Map touched user-visible surfaces before judging behavior.
- 03
Trace changed behavior with direct evidence; build scoped graphs when branching, effects, or ownership changes need them.
- 04
Compare current behavior against baseline, intent, and user expectations.
- 05
Write all distinct findings, not only the top few.
- 06
Record intentional visible changes and uncovered surfaces in the coverage ledger.
04
What you get back
- 01A Markdown regression-review report.
- 02A gate recommendation aligned to findings and coverage.
- 03A complete findings index and coverage ledger, with behavior graph deltas where useful.
05
Important boundaries
- 01Do not silently sample a large review scope.
- 02Do not treat implementation ugliness as a regression unless it changes visible behavior.
- 03Use `hack-review` instead when the main concern is brittle implementation structure.
06