pull-feedback

What this skill does

# 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

```bash
./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. Use targeted `Edit` calls to fill three slots per thread:

- **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

| Action | Command |
|--------|---------|
| Fetch for current branch's PR | `./fetch.sh` |
| Fetch for specific PR | `./fetch.sh 123` or `./fetch.sh owner/repo#123` |
| Deep-dive on thread N | Read the file, update verdict + reasoning via Edit |
| Run internal tests | `./tests/run-tests.sh` |

## 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.