菜单
Review a ticket's branch diff freshly and independently — spec conformance, tests, correctness, quality, security, docs — producing blocking findings that must be fixed before a PR. Use after implement and before open-pr, or when the user asks to review changes / check the diff before shipping.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Run a bounded change → verify → fix cycle until an objective check passes (tests green, lint clean, build/type-check ok) or a hard iteration cap is hit. Use for any task that needs repeated attempts against a verifiable signal instead of a single one-shot edit.
Review code for behavior-preserving simplification — collapse duplication, remove dead code and over-engineering, cut verbose patterns down to idiomatic ones. Use when code is longer or more complex than it needs to be, or the user asks to simplify, shorten, refactor, or clean up.
Implement a planned ticket on its own branch using test-first development, updating docs as part of the change, looping change→verify→fix until the suite is green. Use when a ticket has a plan and is ready to build, or the user says "implement X" / "build the ticket" / "make it pass".
Use to store durable context (decisions, facts, preferences, todos, summaries) and to recall or reply from it across sessions. Load when something worth remembering appears, or when the user asks what you were doing, what was decided, or to continue prior work.
Choose the right model and effort per task phase and apply it when dispatching subagents — strong model + high effort for planning and review, a cheaper model + lower effort for mechanical execution. Use when a task splits into plan / execute / review phases or you're spawning subagents.
Push a reviewed ticket branch and open a pull request with a structured title and body, after review-changes has passed. Use when a ticket is reviewed and ready to ship, or the user says "open a PR" / "create the pull request". Stops at opening the PR — never merges.
| name | review-changes |
| description | Review a ticket's branch diff freshly and independently — spec conformance, tests, correctness, quality, security, docs — producing blocking findings that must be fixed before a PR. Use after implement and before open-pr, or when the user asks to review changes / check the diff before shipping. |
| model | opus |
| effort | high |
| allowed-tools | ["Read","Grep","Glob","Bash"] |
| argument-hint | <ticket id> |
| triggers | ["review the changes","review this diff","check before shipping","is this ready to merge"] |
| tags | ["review","verify","quality","security","pipeline"] |
Judge the change as a fresh reviewer, not as its author. This is pipeline step 4
(plan → track → implement → review → pr) and it IS the quality gate — nothing
opens a PR until this passes. Reviewing is judgment-heavy — strong model, high
effort.
Read the diff and the plan fresh. Do not trust the implementer's narrative — re-derive correctness from the code and re-run the checks yourself.
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" show <ticket-id>
DEFAULT=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|origin/||' || echo main)
git diff "$DEFAULT...HEAD"
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> review in_progress
# pass:
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> review done --note "0 findings"
# findings:
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> review failed --note "<n> findings: <summary>"
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" keep "<ticket-id> review: <key finding>" --kind note --tags review
Report pass/fail, the findings (or "none"), and the next step: open-pr on a pass, or back to implement on findings. Under ship, return the verdict + findings count.