菜单
Re-review an incoming PR after the author responded — scoped to the delta since the last review, verifies prior requested changes, posts after confirmation
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/gittower/git-flow-next --skill follow-up-review命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | follow-up-review |
| description | Re-review an incoming PR after the author responded — scoped to the delta since the last review, verifies prior requested changes, posts after confirmation |
| argument-hint | <pr-number> |
| allowed-tools | Bash, Read, Write, Grep, Glob, mcp__github__get_pull_request, mcp__github__get_pull_request_files, mcp__github__get_pull_request_reviews, mcp__github__get_pull_request_comments, mcp__github__create_pull_request_review |
Re-review an incoming pull request after the author has responded to a prior
maintainer review. Unlike /handle-pr (a fresh full review), this skill is
round-aware: it reconstructs what the last review requested, reads the
author's replies, reviews only the delta since the last-reviewed commit, and
reports each prior item as Resolved / Still open / Partially addressed — plus
anything new introduced in the delta. Posts only after user confirmation.
Use this for every round after the first. For the first review of an
incoming PR, use /handle-pr. For addressing feedback on a PR you authored,
use /address-review.
/follow-up-review <pr-number>
Fetch in parallel (owner gittower, repo git-flow-next):
mcp__github__get_pull_request — current HEAD SHA, head branch, basemcp__github__get_pull_request_reviewsmcp__github__get_pull_request_commentsIdentify the most recent maintainer review (the last round we posted). Record:
event (was it REQUEST_CHANGES / COMMENT / APPROVE) and submitted_atcommit_id — this is the last-reviewed SHA. The delta to review is
lastReviewedSHA..HEAD.If no prior maintainer review exists, stop and tell the user to run /handle-pr
first — there is no round to follow up on.
Parse the last maintainer review (body + its inline comments) into a list of requested items, each with:
file:line (or inline thread) it was anchored toAlso pull the prior local artifact if present — check .ai/<folder>/ for the
pr-review-*.md or review-pr<number>-*.md from the last round — and use it to
recover any nuance the posted review compressed.
Before judging anything, read what the author said. For each prior inline thread, check for reply comments (any author) and whether the thread is resolved. Read general PR conversation comments since the last review too.
This matters: an author may have addressed a concern in code, or explained why they didn't ("intentional because X"). Account for the reply before you flag an item as still-open. If a reply makes a dismissal reasonable, note it rather than re-raising the same point.
git fetch origin <head-branch>
git checkout <head-branch>
Get the delta since the last review:
git diff <lastReviewedSHA>..<HEAD> --stat
git log <lastReviewedSHA>..<HEAD> --oneline
Scope rule — delta-only. Review the commits added since the last review, in the context of the prior asks. Do not re-scan the whole PR for pre-existing issues outside the delta that weren't flagged last round — re-surfacing untouched code as new must-fixes reads as moving goalposts to the author. New findings are limited to what the delta actually changed. (If you genuinely spot a serious pre-existing defect outside the delta, raise it to the user at the gate as an out-of-scope note, not as a blocking finding.)
Apply ../code-review/REVIEW_CRITERIA.md to the delta.
For every item from Step 2, assign a status backed by evidence:
APPROVE — every prior Must/Should item is Resolved or Withdrawn, and the
delta introduces no new Must-fix. (Outstanding Nits alone don't block.)REQUEST_CHANGES — any prior Must-fix is Still open / Partially addressed, or
the delta introduces a new Must-fix.COMMENT — no blocking items, but Should-fix items remain open or the delta
adds non-blocking findings.Determine the output folder (reuse the existing one from prior rounds):
# Extract issue number from branch name (feature/42-x -> 42); prefer the
# existing .ai/issue-<number>-* folder, else .ai/pr-<number>/
HEAD_SHA=$(gh pr view <number> --json headRefOid --jq '.headRefOid' | cut -c1-7)
Write to .ai/<folder>/followup-review-<HEAD_SHA>.md using this format — the
frontmatter matches /pr-review so /post-review can consume it directly:
---
pr: <number>
event: <APPROVE|COMMENT|REQUEST_CHANGES>
round: <N>
since: <lastReviewedSHA-short>
---
<Opening: one or two sentences. State the round and that this reviews the delta
since <since>. Lead with what still blocks merge, or say plainly that the prior
items are addressed and nothing new blocks. No generic praise. See GITHUB_GUIDELINES.md.>
**Since last round**
| Prior item | Severity | Status | Evidence |
|------------|----------|--------|----------|
| <short desc> — `file:line` | must fix | Resolved | `<sha>` |
| <short desc> — `file:line` | should fix | Still open | not addressed |
| <short desc> — `file:line` | nit | Withdrawn | intentional per author reply |
**Still Open**
- <item> — `file:line` — <what remains>
**New in this round**
- <finding > — `file:line` —
## Inline Comments
### `:`
Format rules:
<sha>, <sha>, <sha>;
nothing new blocks merge."), not a blind clean-approval.### \file:line`` form for parseability.Present to the user in one block:
Wait for confirmation. The user may re-verdict items, downgrade/upgrade the event, or decide not to post.
On confirmation, post via the /post-review pattern (read
.claude/skills/post-review/SKILL.md), passing the draft path explicitly:
parse the frontmatter for pr and event, use the body up to ## Inline Comments as the review body, map inline comments to delta diff lines, and post
with mcp__github__create_pull_request_review (include commit_id = HEAD SHA).
Verify the body against the posting checklist first.
/check-prs
tracks it; the next author response is another /follow-up-review <number>lastReviewedSHA..HEAD, so successive
followup-review-<sha>.md artifacts accumulate side by side and stay correlated
with the PR state they reviewed — mirroring /address-review's per-SHA plans./address-review is the author-side counterpart (implement
feedback on your own PR); do not confuse the two.