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.

3b: Evaluate Objective Value

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]

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.