菜单
Address PR review comments and resolve threads. Use when CHANGES_REQUESTED is set, working through unresolved review threads, or replying to reviewer feedback.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/laurigates/claude-plugins --skill git-pr-feedback命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
Install, configure and troubleshoot MCP servers. Use when adding/enabling servers, editing .mcp.json, fixing OAuth, or when a server runs stale code after an upstream fix.
FinOps snapshot — org billing, workflow stats, cache usage. Use when you want a high-level view of CI spending or workflow health before diving deeper.
GitHub Actions billing, workflow efficiency, and waste analysis at org or repo level. Use when investigating CI/CD costs, wasted runs, or optimizing triggers.
正在显示 SKILL.md
| created | "2026-01-30T00:00:00.000Z" |
| modified | "2026-06-21T00:00:00.000Z" |
| reviewed | "2026-06-21T00:00:00.000Z" |
| allowed-tools | Bash(gh pr checks *), Bash(gh pr view *), Bash(gh pr diff *), Bash(gh run view *), Bash(gh run list *), Bash(gh api *), Bash(gh repo view *), Bash(gh issue create *), Bash(git status *), Bash(git diff *), Bash(git log *), Bash(git add *), Bash(git commit *), Bash(git push *), Bash(git switch *), Bash(git pull *), Bash(git fetch *), Bash(pre-commit *), Bash(npm run *), Bash(uv run *), Bash(bash *), Read, Edit, Write, Grep, Glob, TodoWrite, Task, mcp__github__pull_request_read, mcp__github__add_reply_to_pull_request_comment, mcp__github__pull_request_review_write, mcp__github__issue_write |
| args | [pr-number] [--commit] [--push] [--all] [--dry-run] [--limit N] [--include-automation] |
| argument-hint | [pr-number | --all] [--commit] [--push] [--dry-run] [--limit N] [--include-automation] |
| disable-model-invocation | true |
| description | Address PR review comments and resolve threads. Use when CHANGES_REQUESTED is set, working through unresolved review threads, or replying to reviewer feedback. |
| name | git-pr-feedback |
| agent | general-purpose |
git remote -vgit branch --show-currentgit status --porcelain=v2 --branchParse these parameters from the command (all optional):
| Parameter | Description |
|---|---|
$1 | PR number (if omitted, use PR of current branch; if no such PR, list actionable PRs). Mutually exclusive with --all. |
--commit | Create commit(s) after addressing feedback. |
--push | Push changes after committing (implies --commit). |
--all | Address feedback on every actionable open PR. Dispatches one subagent per PR in an isolated worktree; the orchestrator pushes, replies, and resolves. Implies --commit --push unless --dry-run is set. Mutually exclusive with $1. |
--dry-run | With --all, print the dispatch plan and stop — no subagents spawned, no commits, no pushes. Ignored without --all. |
--limit N | Maximum concurrent subagents under --all (default 3). Use a small number to stay under GitHub rate limits and avoid [1m]-model concurrency cascades (see skill-fork-context.md). |
--include-automation | With --all, also surface automation-authored PRs (release-please, dependabot, renovate, *[bot], *-bot). Excluded by default because they carry no human review feedback and their CI failures are resolved by automation re-running, not hand edits. |
Mode selection:
| Mode | Triggered when | Flow |
|---|---|---|
| Single-PR | No --all | Steps 1–7 below operate on one PR. |
| Multi-PR | --all is passed | Step 1A dispatches subagents; the orchestrator finalises (push, reply, resolve, re-request) and writes a combined summary. Skip Steps 1–6. |
If both $1 and --all are given, error and stop with: --all is mutually exclusive with a PR number argument.
| Use this skill when... | Use another skill instead when... |
|---|---|
| A PR has reviewer comments to address | CI checks are failing with no review comments -> use git-fix-pr |
| You need to systematically work through review feedback | You're creating a new PR -> use git-commit-push-pr |
| A reviewer has requested changes | You want to understand PR workflow patterns -> use git-branch-pr-workflow |
Review PR workflow results and reviewer comments, then address substantive feedback.
For feedback categorization, decision trees, commit format, and report templates, see REFERENCE.md.
If
--allis set, skip this step and jump to Step 1A: Multi-PR Mode below.
Parse owner/repo from the git remote URL.
Resolve the PR number in this order:
If $1 was provided, use it.
Otherwise, try the PR for the current branch:
gh pr view --json number -q '.number'
If step 2 fails (no PR for the branch) or the command is on a detached/default branch, fall back to listing actionable PRs:
bash ${CLAUDE_SKILL_DIR}/scripts/list-actionable-prs.sh <owner> <repo>
The script emits a JSON array of open, non-draft PRs that have unresolved review threads, failing/errored CI, or CHANGES_REQUESTED. Handle the result as follows:
| Result | Action |
|---|---|
| Empty array | Report "No PRs need attention." and stop. |
| One entry | Use that PR number and continue. |
| Multiple entries | Print a compact table (number, author, CI, unresolved, reviewDecision, title) ordered as returned, then stop and instruct the user to re-run /git:pr-feedback <number>. Do not guess which PR they meant. |
Switch to PR branch if not already on it:
gh pr view $PR --json headRefName -q '.headRefName'
git switch <branch-name>
git pull origin <branch-name>
Fetch ALL PR data using the bundled script (single GraphQL query):
bash ${CLAUDE_SKILL_DIR}/scripts/fetch-pr-data.sh <owner> <repo> <pr-number>
For failed checks only, fetch detailed logs:
gh run view $RUN_ID --log-failed
| Check Status | Action |
|---|---|
| All passing | Skip to Step 2 |
| Failed CI | Get logs with gh run view, may need fixes |
| Pending | Note status, focus on comments |
If the GraphQL query fails with a rate limit error, wait 60 seconds and retry once.
Reached only when --all is passed. The orchestrator dispatches one subagent per actionable PR; subagents commit inside isolated worktrees but never push. The orchestrator handles all GitHub-side mutations.
Parse owner/repo from the git remote URL.
List actionable PRs with the bundled selector (append --include-automation if that flag was passed):
bash ${CLAUDE_SKILL_DIR}/scripts/list-actionable-prs.sh <owner> <repo>
The script returns a JSON array of open, non-draft PRs with unresolved review threads, failing/errored CI, or CHANGES_REQUESTED. Automation-authored PRs (release-please, dependabot, renovate, *[bot], *-bot) are excluded by default — dispatching a subagent on one is almost always wrong (no review threads to act on, protected changelog/version files). Pass --include-automation to include them, or set PR_FEEDBACK_AUTOMATION_AUTHORS to extend the recognised author list. If the array is empty, report No PRs need attention. and stop.
Print a compact dispatch table (number, author, ci, unresolved, reviewDecision, head, title) so the user can see what is about to be processed.
--dry-run short-circuit: if --dry-run was also passed, additionally print the per-PR subagent prompt that would be dispatched (one per row, using the template in REFERENCE.md "Multi-PR Subagent Prompt"), then stop. No subagents spawn, no commits, no pushes.
Dispatch subagents, capped at --limit N concurrent (default 3). For each PR call the Task tool with:
subagent_type: "general-purpose"isolation: "worktree" — each subagent gets its own git worktreedescription: Address review feedback for PR #<n>prompt: see REFERENCE.md "Multi-PR Subagent Prompt" for the canonical template. The prompt must instruct the subagent to switch its worktree to the PR's headRefName, run the single-PR feedback flow with --commit (not --push), and return a structured JSON summary.Dispatch one batch of N Task calls in a single message (per the parallel-dispatch contract). When all return, dispatch the next batch until the queue is empty.
Collect subagent results. Each subagent returns JSON with: pr, branch, worktree_path, commits[], addressed[] (each with thread_id, database_id, action, reply, resolve), deferred_issues[], co_authors[], blockers[]. Treat any subagent that fails to return parseable JSON as blocked — record its raw output and continue with the rest of the batch.
Orchestrator finalisation — for each PR with successful commits, run sequentially (push and the GitHub mutation tools share the same rate-limit pool):
git push origin <branch> from the main checkout — worktrees share the underlying .git/, so commits made by the subagent are already visible by branch name. No cd into the subagent's worktree is required.
Capture the resolving SHA (git rev-parse origin/<branch> after the push).
For each addressed[] entry, post the reply via mcp__github__add_reply_to_pull_request_comment, substituting the resolving SHA into any {{SHA}} placeholder the subagent left in the reply text.
Resolve threads via the GraphQL resolveReviewThread mutation per Step 6's rules. Resolution is the default after a reply — only skip when the subagent set resolve: false for a documented exception (follow-up question, partial fix, reviewer asked to keep open, or a third-party PR without user approval). Treat any resolve: true paired with a successful reply as a mandatory call. Use:
gh api graphql -f query='mutation($id:ID!){resolveReviewThread(input:{threadId:$id}){thread{isResolved}}}' -F id="$THREAD_ID"
Re-request review per Step 5a's rules.
Skip Steps 2–6. Go directly to Step 7 with a combined summary that includes a per-PR section plus a top-level rollup: dispatched, succeeded, blocked, total threads resolved, total commits pushed.
| Subagent state | Orchestrator action |
|---|---|
| Returned valid JSON, has commits, no blockers | Push + reply + resolve as above |
| Returned valid JSON, no commits (only questions / declined nitpicks) | Skip push; still post replies and resolve declined nitpick threads |
Returned valid JSON, has blockers[] | Surface in the summary; do not push partial work — let the user decide |
| Failed to return parseable JSON | Surface its raw output in the summary as blocked: parse-error; do nothing further for that PR |
Reported a merge conflict on git pull --ff-only | Surface in the summary as blocked: branch-out-of-sync; user resolves manually |
A blocked subagent does not abort the whole batch; the orchestrator continues with the others.
Categorize all comments from the GraphQL response (see REFERENCE.md for category definitions):
isResolved: true or isOutdated: true — already handled.id, top-level comment databaseId, file, line, scope, and whether the body contains a ```suggestion block.id and databaseId so Steps 3–5 can reply and resolve.Verify before accepting — especially claims from an automated reviewer. Before accepting or acting on any suggestion, independently verify the claim against the actual source, the live system, or upstream documentation. This matters most for automated reviewers (Gemini Code Assist, Copilot, and other bot authors), whose suggestions are frequently confidently-wrong: read the code/config the claim is about, check the rendered/live behaviour, and confirm against docs rather than applying a bot suggestion on trust. A claim that fails verification is refuted — reply with the refutation and the supporting evidence, and do not change the code. A written refutation with evidence is a legitimate way to resolve a thread (see Step 6).
Work through actionable items systematically. For each thread, decide using the table below — see REFERENCE.md for the full decision tree.
| Comment shape | Action |
|---|---|
Contains a ```suggestion block, fix is correct | Accept the suggestion: apply the suggestion's exact replacement to the file (see REFERENCE.md "Accepting Suggestions"). Record the comment author's login and name/email for co-author attribution in Step 4. |
Contains a ```suggestion block, fix needs adjustment | Implement an improved variant; explain the deviation in the reply. Record the suggester for co-author attribution. |
| Inline code comment without suggestion | Read context, implement fix, verify no regressions |
| Claim that verification refutes (wrong on the facts) | Refuted: do not change the code. Reply with the refutation and the evidence that disproves it (the source line, rendered config, live behaviour, or doc that contradicts the claim), then resolve. Apply this whenever a bot/automated-reviewer suggestion does not survive verification. |
| Question / clarification | Skip code change; draft an inline reply for Step 4 |
Blocking review (REQUEST_CHANGES) | Address every concern before resolving any thread |
| Failed CI check | Identify failure type (lint/type/test/build), fix locally, run to verify |
| Out-of-scope feedback | Do not implement in this PR. Open a follow-up issue (see Step 3a) and reference its number in the reply. |
Mark each todo in_progress while working it and completed once the file change (if any) lands locally. Do not resolve threads yet — replies and resolution happen after the commit so reviewers see the linked SHA.
For any thread categorised as out-of-scope (or where the user opts to defer rather than implement now):
mcp__github__issue_write (action create) or gh issue create -R <owner>/<repo> --title "<title>" --body "<body>" to file the issue.Deferred to #<n> — <reason>.).Skip this step if the user has explicitly said not to file follow-ups. When ambiguous, ask via AskUserQuestion before creating an issue.
Group related fixes into logical commits — one commit per logical group of accepted suggestions, not one per suggestion. See REFERENCE.md for commit message format.
For any commit that contains an accepted (or adapted) suggestion, append a Co-authored-by: trailer for each unique suggester. This mirrors GitHub's "Commit suggestion" / "Add suggestion to batch" behaviour, which credits the suggester as co-author. See REFERENCE.md "Co-author Attribution" for how to construct the trailer line and resolve the suggester's email.
Run pre-commit hooks if configured, then stage any formatter changes.
git push origin HEAD
After a successful push that addresses substantive feedback, re-request review from any reviewer whose threads were resolved or who left a CHANGES_REQUESTED review. Skip this step when only nitpicks or questions were addressed.
Determine reviewers to re-request from the GraphQL response captured in Step 1:
latestReviews entries with state == "CHANGES_REQUESTED"Then call:
gh api -X POST \
/repos/<owner>/<repo>/pulls/<pr>/requested_reviewers \
-f 'reviewers[]=<login1>' \
-f 'reviewers[]=<login2>'
If gh api returns 422 ("Reviews may only be requested from collaborators"), the reviewer cannot be re-requested via the API — note it in the Step 7 summary and continue.
For every actionable thread tracked in Step 2, post a reply and then resolve the thread by default. Owner/repo/PR are the same values used in Step 1.
Resolving is the default action after replying — leaving threads open is the exception, reserved for the explicit cases listed in step 3. A reply alone does not end the conversation in GitHub's UI: the thread stays in the reviewer's "unresolved" queue until someone clicks Resolve conversation. Without this step the PR will continue to show unresolved feedback even after every concern has been addressed.
Reply with mcp__github__add_reply_to_pull_request_comment using the top-level comment's databaseId (a number, not the GraphQL node ID). Keep replies short — see REFERENCE.md "Reply Templates".
Fixed in <sha> by <one-line summary>.Accepted suggestion in <sha>.Applied a variant in <sha>: <reason>.Deferred to #<issue> — <reason>.Leaving as-is: <reason> — <evidence that disproves the claim>.Always resolve with the GraphQL resolveReviewThread mutation using the thread id (a PRRT_… GraphQL node ID). Resolution is the default after a reply — only skip when one of step 3's "leave open" exceptions applies. Call:
gh api graphql -f query='mutation($id:ID!){resolveReviewThread(input:{threadId:$id}){thread{isResolved}}}' -F id="$THREAD_ID"
Resolve when any of these completion conditions hold and none of step 3's "leave open" exceptions apply:
Fixed in <sha>, Accepted in <sha>, Applied a variant in <sha>).Resolving must happen in the same turn as the reply. Treat "reply posted but thread unresolved" as an incomplete step — re-run the resolve call before reporting Step 7.
Leave the thread open only when one of these holds:
If --commit/--push was not passed, still post replies for questions and refutations, but defer resolution until a future invocation with --push lands the SHA. Note these pending resolutions in the Step 7 summary so they're not forgotten.
Provide a summary table of feedback addressed, replies posted, threads resolved, and next steps. See REFERENCE.md for the report template.
| Context | Command / Tool |
|---|---|
| All PR data (single query) | bash ${CLAUDE_SKILL_DIR}/scripts/fetch-pr-data.sh <owner> <repo> <pr> |
Actionable PRs (selector / --all source) | bash ${CLAUDE_SKILL_DIR}/scripts/list-actionable-prs.sh <owner> <repo> |
| Actionable PRs incl. automation | bash ${CLAUDE_SKILL_DIR}/scripts/list-actionable-prs.sh --include-automation <owner> <repo> |
Dispatch a per-PR subagent (--all) | Task({subagent_type: "general-purpose", isolation: "worktree", prompt: <REFERENCE.md template>}) |
| Failed check logs | gh run view $ID --log-failed |
| Quick check status (fallback) | gh pr checks $PR --json name,state,conclusion |
| Reply to a review comment | mcp__github__add_reply_to_pull_request_comment (commentId = databaseId) |
| Resolve a review thread | gh api graphql -f query='mutation($id:ID!){resolveReviewThread(input:{threadId:$id}){thread{isResolved}}}' -F id="$THREAD_ID" (threadId = PRRT_… node ID) |
| Re-request review after push | gh api -X POST /repos/<owner>/<repo>/pulls/<pr>/requested_reviewers -f 'reviewers[]=<login>' |
| File follow-up issue for deferred feedback | mcp__github__issue_write (action create) or gh issue create -R <owner>/<repo> --title <t> --body <b> |