メニュー
Verify that a PR author addressed prior review feedback — parses checklist items from the reviewer's comment and checks each against new commits.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Full PR review workflow — Copilot triage, automated checks, change requests or approval.
Pre-flight checks, approve, squash-merge, and delete branch for a PR.
Draft and post a structured PR comment requesting specific changes from the author.
Run all automated PR checks — code conventions, documentation sync, and holistic review.
Fetch and classify Copilot's review suggestions on a PR as incorporate, ignore, or discuss.
Check whether code changes need documentation updates.
| name | verify-review |
| description | Verify that a PR author addressed prior review feedback — parses checklist items from the reviewer's comment and checks each against new commits. |
| disable-model-invocation | true |
Verify that the author's new commits address the reviewer's prior feedback on a PR. This is the lightweight "re-review" workflow — use it when the author says "Ready for review" after pushing fixes.
The PR number is: $ARGUMENTS
If no PR number was provided, detect it from the current branch:
gh pr view --json number --jq .number
Identify the reviewer and find their structured feedback comment.
Get the current user (the reviewer running this skill):
gh api user --jq .login
Fetch PR comments:
gh pr view <PR> --json comments
Find the reviewer's most recent structured comment — scan comments from the current user (newest first) and select the first one that contains ### Required Changes or checkbox items (- [ ]).
Record the comment's body and createdAt timestamp.
If no structured comment found: present the most recent comment from the reviewer and ask them to confirm which items to verify. If the reviewer has no comments on the PR at all, report this and suggest running /review-workflow <PR> for a first-pass review instead.
Find commits the author pushed after the review comment.
Fetch the commit list:
gh api repos/bkelly-lab/jkp-data/pulls/<PR>/commits
Find all commits with commit.committer.date after the review comment's createdAt timestamp. These are the "response commits."
Identify the diff base and head:
If no response commits exist: report "No new commits found after the review comment. The author may not have pushed changes yet." and stop.
Get the scoped diff covering only the response commits. Use a git worktree so the reviewer's working tree and current branch are untouched regardless of whether they have uncommitted changes.
Create a worktree for the PR branch. This works for fork PRs via the pull/<PR>/head virtual ref:
git fetch origin pull/<PR>/head:pr-<PR>-review
git worktree add ../jkp-data-review-pr<PR> pr-<PR>-review
Get the overview (run git against the worktree via -C):
git -C ../jkp-data-review-pr<PR> diff <base>..<head> --stat
git -C ../jkp-data-review-pr<PR> diff <base>..<head> --name-only
Get the full diff per file:
git -C ../jkp-data-review-pr<PR> diff <base>..<head> -- <file>
Read each changed file's diff. For large diffs, focus on the files referenced in the review items first.
Parse the review comment body into individual checklist items using a tiered approach.
Tier 1 — Standard /draft-pr-comment format:
Split the comment by ### headings. Look for sections named "Required Changes", "Suggestions", and "Copilot Items to Address". Within each section, extract items matching:
- [ ] **[<location>]** <description>
or
- [ ] **[<location>] <description>**
Capture the category (Required/Suggestion/Copilot), location reference, and description for each item.
Tier 2 — Generic checkboxes:
If no standard sections are found, extract all - [ ] lines as items. Classify them all as "Review Items" (unknown category). Try to extract file references from bold text, backticks, or inline code.
Tier 3 — Unstructured:
If no checkboxes are found, present the full comment body and ask the reviewer: "This comment doesn't have a standard checklist format. Which specific items should I verify?" Wait for the reviewer to list items before proceeding.
For each parsed item:
Present the verification as a structured summary:
## Re-review: PR #<n>
### Review Comment
From @<reviewer> on <date> — [link to comment]
### Response Commits
<count> commit(s) after review (<base-sha>..<head-sha>), +<added>/-<removed> lines
### Checklist Verification
#### Required Changes
1. <verdict> **[file:line] Description** — <brief explanation of what changed or didn't>
2. ...
#### Suggestions
1. <verdict> **[file:line] Description** — <brief explanation>
2. ...
### Verdict
X/Y required items addressed, Z/W suggestions adopted.
Use checkmark/cross symbols for the verdicts to make the summary scannable.
If the response diff includes changed .py files, run @code-critic on the response diff only (not the full PR diff). The changed files live inside the worktree at ../jkp-data-review-pr<PR> — pass those paths to @code-critic. Present any findings under a "New Issues in Response" section. If no Python files changed, skip this step.
Before the decision point, remove the worktree and temporary ref so the reviewer's repo is left tidy:
git worktree remove ../jkp-data-review-pr<PR>
git branch -D pr-<PR>-review
Ask the reviewer:
Based on the verification above, how would you like to proceed? (a) Approve and merge — run
/approve-pr <PR>(b) Request further changes — draft a follow-up comment via/draft-pr-comment <PR>(c) Manual review — look at specific items more closely before deciding
If all required items are addressed and code-critic found no critical issues, recommend option (a). Otherwise, recommend option (b) and summarize what remains.
Wait for the reviewer's choice, then follow the corresponding skill.