Git Pr Feedback

PR Feedback Handler

Fetch review comments on a GitHub PR, triage them, fix what's clear, ask about what's ambiguous, and reply to each comment on GitHub with what was done.

Workflow

1. Identify the PR

Determine the PR number from context:

# Current branch's PR
gh pr view --json number -q .number

# Or from a URL the user provided
# Or from a specific PR number they mentioned

2. Fetch All Comments

Pull both review comments (inline on code) and issue-level comments:

# Inline review comments (from Copilot and reviewers)
gh api --paginate repos/{owner}/{repo}/pulls/{pr}/comments

# General PR comments (not on specific lines)
gh api --paginate repos/{owner}/{repo}/issues/{pr}/comments

# Review summaries
gh api --paginate repos/{owner}/{repo}/pulls/{pr}/reviews

Use --paginate to ensure all comments are returned — the default page size is 30, which can silently miss comments on large PRs.

Parse each comment to extract:

• who: user.login — distinguish Copilot, copilot-pull-request-reviewer[bot], and human reviewers
• where: path and line — the file and line the comment targets
• what: body — the feedback text
• id: id — needed for replying
• replied: to detect already-handled comments, scan all comments for replies where in_reply_to_id == <top_level_id> and the reply author is the PR author.

3. Triage Each Comment

Classify every comment into one of these categories:

Triage guidelines:

• Read the actual code the comment references before deciding. The diff context in the comment may be stale after pushes.
• Copilot comments are usually technically accurate but sometimes miss context. Verify before acting.
• Human reviewer comments carry more weight. Treat these as higher priority.
• If a comment suggests a significant design decision, always escalate to the user.

4. Present the Triage

Before making changes, show the user a summary:

PR #34 — 3 review comments:

1. [BUG] Copilot on sync-skills.sh:426
   Broken symlink glob — --clean uses */ which skips broken symlinks
   → Will fix: change glob to /*

2. [IMPROVEMENT] Copilot on sync-skills.sh:101
   usage exits 0 on invalid options
   → Will fix: exit 1 for unknown options

3. [DOC] Copilot on SKILL.md:78
   Doc claims non-repo skills untouched but name collisions get replaced
   → Will fix: clarify the wording

Ready to fix all 3? Or want to discuss any of them?

For items classified as ambiguous/tricky, present the options and wait for the user's decision before proceeding.

5. Implement Fixes

For each actionable comment:

1. Read the file at the referenced path and line
2. Make the fix
3. Stage the changed files by name (not git add -p — interactive staging doesn't work in automated environments)

After all fixes are applied, commit following git-commit conventions:

git add path/to/fixed-file1 path/to/fixed-file2
git commit -m "$(cat <<'EOF'
fix: address review feedback on {context}

{brief description of changes}
EOF
)"

git push

6. Reply to Comments on GitHub

For each comment, post a reply using the GitHub API:

# Reply to an inline review comment (threaded)
gh api repos/{owner}/{repo}/pulls/{pr}/comments/{comment_id}/replies \
  -f body="Fixed in {sha} — {brief description of what changed}."

# Reply to a general PR comment (post a new issue comment)
gh api repos/{owner}/{repo}/issues/{pr}/comments \
  -f body="Re: {summary of original comment} — Fixed in {sha}."

Reply content by category:

• Bug/Improvement/Doc: "Fixed in {short sha} — {what changed}."
• Noise/false positive: "This is intentional — {reason}."
• Style adopted: "Good catch, fixed in {sha}."
• Style declined: "Keeping as-is — {reason}."

7. Check for New Comments

After pushing fixes, Copilot may generate new comments on the updated code. Don't block waiting for them — let the user know they can ask to check again later.

Handling Specific Reviewer Types

GitHub Copilot

• Copilot review is requested immediately when a PR is created or updated, but comments can take 30 seconds to several minutes to appear.
• Usually catches real issues: bugs, edge cases, doc inconsistencies.
• Sometimes suggests changes that miss project-specific context — verify first.
• May not comment at all on markdown-only or trivial PRs.

Human Reviewers

• May not appear immediately — check back when the user asks.
• Comments may be conversational rather than prescriptive.
• Look for approval/changes-requested status in the reviews endpoint.
• If a reviewer requested changes, prioritize their comments.

Edge Cases

• Already-replied comments: Skip any top-level comment that has a reply from the PR author (in_reply_to_id points back to the parent).
• Outdated comments: After pushing fixes, read the file fresh — don't trust the diff context in the comment.
• Multiple commits: Batch fixes into one commit unless the fixes are logically independent enough to warrant separate commits.
• No comments yet: If fetching after PR creation and getting zero comments, that's normal — let the user know and offer to check again later.