Resolve open PR review discussions by evaluating applicability and value, then fixing valid feedback with conventional commits. Use when (1) addressing reviewer feedback on a pull request, (2) resolving open PR discussions systematically, (3) triaging PR review comments for actionability, (4) batch-fixing code review feedback, or (5) cleaning up unresolved PR conversations.
Process open review discussions in a GitHub pull request. Evaluate each for applicability and objective value. Fix valid feedback locally with conventional commits.
$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.
gh pr checkout <number>
Verify the local branch is up to date with the PR head.
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.
Evaluate each unresolved thread in order:
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 |
| 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.
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.
| # | 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 |
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.