Pull Feedback

Git Pull Feedback

Overview

Pulls review feedback on a PR the user authored into a working doc with per-thread triage slots. The point is rigor: every unresolved thread gets a tentative verdict (valid / invalid / nice-to-have / needs-clarification) with reasoning and a plan, so the user can work through feedback deliberately instead of rubber-stamping.

Announce: "Using git:pull-feedback to pull and triage feedback on PR #N."

Workflow

1. Fetch

./fetch.sh [ref]

ref accepts a bare number, #N, owner/repo#N, a PR URL, or nothing (auto-detects from current branch). The script writes a skeleton doc to .scratch/pr-reviews/<N>/threads.md with _pending triage_ placeholders and prints counts on stdout. Use this output location — don't invent your own filename.

2. Orient only if context is cold

Add a ## Summary section (1-2 sentences on what the PR does + state of the review) only if you don't already know the PR. If the user has been discussing it in conversation or the branch name tells you, skip — guessing wastes tokens and risks confabulation.

3. Triage each unresolved thread (shallow pass)

Each thread has a unique <!-- thread: N --> anchor. If a reviewer left feedback as a review body instead of (or in addition to) inline comments, it appears in its own ## Review comments section with a <!-- review: N --> anchor per review — triage those the same way. Use targeted Edit calls to fill three slots per thread or review:

• Verdict (tentative): pick one, based on whether the reviewer is right:
  • ✅ Valid — reviewer has a point, code needs to change
  • ❌ Invalid — disagree for a concrete technical reason (not because the fix is inconvenient)
  • 💡 Nice-to-have — reasonable suggestion, but out of scope for this PR
  • ❓ Needs clarification — comment is ambiguous; ask the reviewer instead of guessing
• Reasoning: 1-3 sentences. Reference the comment body or the code, not vibes. Severity ≠ verdict — a "should-fix" can still be Invalid if the reviewer is wrong.
• Plan: concrete next step — fix inline, deep-dive first, reply-and-defer, ask reviewer.

Keep the (tentative) label. It's the shallow-pass signal; it invites deep-dive on anything non-obvious.

4. Deep-dive on request

When the user asks to dig into a specific thread ("verify the race condition claim", "dig into thread 3"):

1. Read the referenced file at current HEAD
2. Check surrounding code for context the reviewer may not have seen
3. Re-evaluate, then upgrade **Verdict (tentative):** → **Verdict:**

Shallow pass catches obvious cases (typos, renames, style). Deep-dive is where the hard judgment lives — reserve it for threads with real technical substance.

5. Apply rigor to Invalid verdicts

For any Invalid, apply superpowers:receiving-code-review: verify the reviewer's claim is actually wrong (don't just disagree because fixing is annoying), acknowledge the concern even when disagreeing, and plan a reply that explains the reasoning. That skill was written for agent reviews; the core rigor applies equally to humans.

6. Report back

Summarize counts and offer a next step:

7 threads triaged: 4 valid, 2 invalid, 1 nit. Doc at .scratch/pr-reviews/603/threads.md. Walk through them, or dig deeper on specific ones?

Then stop. Addressing threads, making code changes, and replying are normal work from there — not this skill's job.

Stay in Scope

This skill is about review threads, not PR health. Do NOT drift into:

• Merge conflicts, CI status, approval gates, mergeable state
• Whether the PR needs a rebase
• Whether another reviewer should be added

If the user asks "catch me up on my PR", they mean the review feedback. Other PR state belongs to other tools (gh pr view, gh pr checks, git:pull-request).

Reviewer scoping: If the user asks specifically about one reviewer ("what did alice say?"), scope the doc to that reviewer's threads. Other reviewers' threads can be omitted or deferred — don't force all-threads mode.

When Not to Use

• PRs awaiting the user's review → git:inbox
• Writing PR body, description, or replies → git:pull-request
• Reviewing someone else's PR → pr-review-toolkit:review-pr or code-review:code-review
• Marking threads resolved, posting replies, or pushing commits — outside this skill's scope

Quick Reference

Common Mistakes

• Severity in place of verdict. "Should-fix" is urgency, not validity. A Should-fix comment can still be Invalid if the reviewer is wrong about the code. Keep the two axes separate.
• Filling ## Summary without real context. If you don't actually know what the PR does, either read enough to find out or leave the section off. Don't confabulate.
• Scope drift to PR health. Merge conflicts and CI aren't review feedback. Stay on threads.
• Confirming verdicts without deep-diving. The (tentative) marker isn't decoration — keep it until you've read the code for that thread.
• Addressing threads in the same turn as triaging. The skill ends at the filled doc. Code changes are a separate step; forcing both into one pass rushes both.