| name | forge-address-pr-feedback |
| description | Analyze and address unresolved feedback on a GitHub pull request. Use when the user has received PR review comments and wants to systematically address each piece of feedback, or when the user mentions PR feedback, review comments, or addressing reviewer concerns. |
| disable-model-invocation | true |
| allowed-tools | Read, Edit, Write, Bash, Grep, Glob |
Address PR Feedback
Systematically address unresolved review feedback on a pull request.
Input
PR number or URL (auto-detects from current branch if omitted). Optional: -- <additional context> for prioritization guidance.
Process
Step 1: Fetch Unresolved Threads
Use GraphQL — the REST API does NOT expose isResolved status on review threads.
gh api graphql -f query='
query {
repository(owner: "<OWNER>", name: "<REPO>") {
pullRequest(number: <PR_NUMBER>) {
reviewThreads(first: 100) {
nodes {
isResolved
isOutdated
path
line
id
comments(first: 10) {
nodes {
id
body
author { login }
url
}
}
}
}
}
}
}'
Filter for unresolved threads: select(.isResolved == false).
Step 2: Process Each Thread
For each unresolved thread, read the file and surrounding context, then categorize:
- Actionable — code change needed
- Question — respond with explanation
- Discussion — assess if change improves code
- Already addressed — thread not resolved but change was made
- Won't fix — current approach is preferred
- Follow-up — valid but out of scope — create linked issue
Step 3: Address and Reply Individually
Address each thread immediately, then reply before moving to the next. Do not batch.
For each thread:
- Make the change (if actionable)
- Run lint/format/checks
- Commit:
git commit -m "fix: address PR feedback — <brief description>"
- Reply to the thread:
gh api graphql -f query='
mutation {
addPullRequestReviewThreadReply(input: {
pullRequestReviewThreadId: "<THREAD_ID>"
body: "<response>"
}) {
comment { id }
}
}'
Reply format by category:
- Actionable: "Fixed in
<sha>. "
- Question: ""
- Discussion: ""
- Already addressed: "Addressed in
<sha>."
- Won't fix: "Keeping current approach because ."
- Follow-up: "Created # to track this."
Step 4: Create Follow-up Issues
For valid out-of-scope improvements, create an Issue in the project's Issue tracker (see issue-operations). Include the PR context: reviewer's comment, PR number, and proposed solution.
Step 5: Push and Summarize
git push
Report: feedback items addressed, commits created, follow-up issues created, items needing human decision.
Guidelines
- GraphQL for discovery — REST API doesn't show resolution status
- Address, reply, then next — don't batch
- Be specific — reference commits, line numbers, and code
- Test changes — run checks before committing
Related Skills
If the feedback required substantial changes: Use forge-reflect for one more self-review before re-requesting review.
Example Usage
/forge-address-pr-feedback 123
/forge-address-pr-feedback 123 -- prioritize security comments
/forge-address-pr-feedback