resolve-pr-feedback

name	resolve-pr-feedback
description	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.
argument-hint	<PR URL or number>
user-invocable	true
compatibility	Requires gh CLI authenticated with repo access.

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

1. Checkout the PR branch
2. Fetch all unresolved review threads
3. Process each thread sequentially — evaluate, then act
4. 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

1. Read full file context around the referenced lines
2. Implement the fix with minimal, targeted changes
3. Stage only the affected file(s)
4. Compose a commit message following the Commit Format below
5. 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.