Resolve PR Feedback Skill

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.

Agent Skills: Resolve PR Feedback

Install this agent skill to your local

Skill Files