jkappers Resolve PR Feedback
Process open review discussions in a GitHub pull request. Evaluate each for applicability and objective value. Fix valid feedback locally with conventional commits.
Input
$ARGUMENTS — GitHub PR URL (e.g., https://github.com/owner/repo/pull/123) or PR number for the current repository.
Parse owner, repo, and PR number from the URL. If a bare number, use the current repository context.
Workflow
- Checkout the PR branch
- Fetch all unresolved review threads
- Process each thread sequentially — evaluate, then act
- Report summary
Step 1: Checkout PR Branch
gh pr checkout <number>
Verify the local branch is up to date with the PR head.
Step 2: Fetch Unresolved Review Threads
gh api graphql -f query='
query($owner: String!, $repo: String!, $number: Int!) {
repository(owner: $owner, name: $repo) {
pullRequest(number: $number) {
reviewThreads(first: 100) {
nodes {
id
isResolved
isOutdated
path
line
startLine
comments(first: 50) {
nodes {
author { login }
body
createdAt
path
line
startLine
}
}
}
}
}
}
}' -f owner="<owner>" -f repo="<repo>" -F number=<number>
Filter to threads where isResolved is false.
Step 3: Process Each Thread
Evaluate each unresolved thread in order:
3a: Check Applicability
Read the file and lines referenced by the thread. Compare current code against what the reviewer commented on.
| Condition | Action |
|---|---|
| Referenced file no longer exists | Skip. Report: "File deleted — not applicable." |
| Referenced lines substantially changed | Skip. Report: "Code changed — feedback no longer applies." |
isOutdated is true and current code differs from comment context |
Skip. Report: "Outdated — code already modified." |
| Code matches what reviewer commented on | Proceed to value evaluation |
3b: Evaluate Objective Value
| Criterion | Examples |
|---|---|
| Correctness | Bug fix, logic error, off-by-one, null handling |
| Security | Input validation, injection prevention, auth check |
| Performance | N+1 query, unnecessary allocation, missing index |
| Standards compliance | Naming convention, code style, project pattern violation |
| Maintainability | Dead code removal, duplication, unclear naming |
Valuable: Feedback addresses at least one criterion with a concrete, actionable suggestion. Proceed to fix.
Not valuable: Feedback is subjective preference, bikeshedding, or stylistic without project convention backing. Report the specific reason and move to next thread.
3c: Fix and Commit
- Read full file context around the referenced lines
- Implement the fix with minimal, targeted changes
- Stage only the affected file(s)
- Compose a commit message following the Commit Format below
- Run
git commit -m "<message>"(use a HEREDOC for multi-line messages)
Scope each commit to a single discussion thread. Do not batch fixes across threads.
Step 4: Report Summary
| # | File:Line | Feedback | Result |
|---|-----------|----------|--------|
| 1 | src/api/users.ts:42 | Add null check | Fixed (abc1234) |
| 2 | src/utils/parse.ts:15 | Rename variable | Skipped — subjective preference |
| 3 | src/models/order.ts:88 | Fix SQL injection | Fixed (def5678) |
| 4 | src/api/auth.ts:22 | Use different pattern | Not applicable — code changed |
Commit Format
Follow Conventional Commits v1.0.0.
<type>[optional scope]: <description>
[optional body]
| Type | Purpose |
|---|---|
feat |
New feature |
fix |
Bug fix |
refactor |
Neither fix nor feature |
style |
Formatting, whitespace |
perf |
Performance improvement |
docs |
Documentation only |
test |
Adding or updating tests |
chore |
Maintenance tasks |
Description: Imperative mood ("add feature" not "added feature"). Lowercase after prefix. No trailing period. Max 50 characters.
Scope: Optional. Derive from project directory or module names. Omit for cross-cutting changes.
Body: Separate from description with one blank line. Wrap at 72 characters. Explain what and why, not how.
Prohibited: AI attribution, emoji, time estimates, TODO items, file lists, hedging language.
Constraints
- Do not force-push or amend existing commits. Create new commits only.
- Do not resolve threads on GitHub. The PR author decides when to mark discussions resolved.
- Do not modify files outside the scope of the feedback. No drive-by refactoring.