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.

resolve-pr-feedback