| name | post-refactor |
| version | 1.0.0 |
| description | Post-refactor clean-code check after recent refactors or a few merged PRs.
Use when the user says "post-refactor", "after the refactor", "we merged a
few PRs", "clean code checks", or wants a focused sweep for regressions,
vulnerabilities, duplicated abstractions, magic values, weak documentation,
missing coverage, or flaky tests without running a full PR/post-merge audit.
|
| allowed-tools | ["Bash","Read","Grep","Glob","Agent","TaskCreate","TaskUpdate","TaskList","AskUserQuestion"] |
Post-Refactor Clean-Code Sweep
Use this skill after a refactor, cleanup series, or a handful of related PRs
landed. It is not a full PR audit and should not re-litigate already merged
work. Keep the pass focused on the code that changed recently and on defects
that refactors commonly leave behind.
Primary goal: answer, "Did we leave the touched code cleaner, safer, and well
covered, or did we leave regressions and cleanup debt behind?"
Scope
Pick the narrowest useful range:
- If the user names a range, use it exactly.
- Else, if a release just happened, inspect changes since the previous tag:
git describe --tags --abbrev=0 HEAD^ → PREV_TAG..HEAD.
- Else, inspect the last 3-8 related commits or merged PRs.
- If the range spans unrelated areas, group by subsystem and review each group
separately.
Do not expand into full architecture review unless a finding shows a real risk.
