Change check entry point — dispatch the change-checker subagent to review this round's changes and iterate on its feedback until it passes; this should come to mind once this round's changes are done, before delivery. Use when the user says "review this round of changes", "wrap-up review", "check the changes I just made".
Installs into .claude/skills of the current project.
Sponsors
SSkills DirectorySkills Directory
Know which skills are safe — weekly.
SSkills DirectorySkills Directory
Is that skill safe to install?
Are you the author of Agent Change Check?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/baijunjie-agent-change-check)
---
name: agent-change-check
description: Change check entry point — dispatch the change-checker subagent to review this round's changes and iterate on its feedback until it passes; this should come to mind once this round's changes are done, before delivery. Use when the user says "review this round of changes", "wrap-up review", "check the changes I just made".
---
# Change check
1. **Dispatch the `change-checker` subagent to review this round of changes; do not review what you wrote
yourself**: your own context treats the structure you just wrote as settled fact. Its checklist and judgment
criteria live in its own definition; you only hand over what changed this round and what the requirement is,
plus the trade-offs the user settled over several rounds of revision — it cannot see your conversation, and
anything you leave out comes back reported as a problem.
2. **Work through the comments one by one**: fix the ones you agree with; explain your reasoning for the ones you
do not, and when you cannot reach agreement with it, or a comment would overturn a trade-off the user settled,
leave it to the user to decide.
3. **Dispatch it again once the fixes are in**, until it passes. In your final reply, state how many rounds of
review there were, what was changed, and which comments are left for the user to decide.
- When the volume of changes is large and spans several relatively isolated modules, split by scope and dispatch
one `change-checker` per scope, reviewing in parallel: one subagent given too much full text to read can only
skim, and details get missed. Where scopes share an interface contract, hand that contract to every side
involved; when fixing comments touches a cross-scope interface, re-dispatch a review for the scopes on both
sides of it.
- The subagent this skill dispatches is installed together with it: if there is a subagent mechanism but the
definition of the subagent to dispatch cannot be found, the installation is incomplete: stop and ask the user to
rerun the installer that installed this skill. With no subagent mechanism, read the installed definition and do the
work yourself following the rules inside.
When unsure, report back: stop, spell out what needs deciding (with the options) or what information is missing,
together with what you have already found out, and let the recipient of the report (the user, or the dispatcher
passing it on to the user) decide before going on; do not decide for yourself.