git-pr-feedback

What this skill does

## Context

- Repo: !`git remote -v`
- Current branch: !`git branch --show-current`
- Git status: !`git status --porcelain=v2 --branch`

## Parameters

Parse these parameters from the command (all optional):

| Parameter | Description |
|-----------|-------------|
| `$1` | PR number (if omitted, use PR of current branch; if no such PR, list actionable PRs). Mutually exclusive with `--all`. |
| `--commit` | Create commit(s) after addressing feedback. |
| `--push` | Push changes after committing (implies `--commit`). |
| `--all` | Address feedback on every actionable open PR. Dispatches one subagent per PR in an isolated worktree; the orchestrator pushes, replies, and resolves. Implies `--commit --push` unless `--dry-run` is set. Mutually exclusive with `$1`. |
| `--dry-run` | With `--all`, print the dispatch plan and stop — no subagents spawned, no commits, no pushes. Ignored without `--all`. |
| `--limit N` | Maximum concurrent subagents under `--all` (default `3`). Use a small number to stay under GitHub rate limits and avoid `[1m]`-model concurrency cascades (see [`skill-fork-context.md`](../../../.claude/rules/skill-fork-context.md)). |
| `--include-automation` | With `--all`, also surface automation-authored PRs (release-please, dependabot, renovate, `*[bot]`, `*-bot`). Excluded by default because they carry no human review feedback and their CI failures are resolved by automation re-running, not hand edits. |

**Mode selection**:

| Mode | Triggered when | Flow |
|------|----------------|------|
| Single-PR | No `--all` | Steps 1–7 below operate on one PR. |
| Multi-PR | `--all` is passed | **Step 1A** dispatches subagents; the orchestrator finalises (push, reply, resolve, re-request) and writes a combined summary. Skip Steps 1–6. |

If both `$1` and `--all` are given, error and stop with: `--all is mutually exclusive with a PR number argument.`

## When to Use This Skill

| Use this skill when... | Use another skill instead when... |
|------------------------|----------------------------------|
| A PR has reviewer comments to address | CI checks are failing with no review comments -> use `git-fix-pr` |
| You need to systematically work through review feedback | You're creating a new PR -> use `git-commit-push-pr` |
| A reviewer has requested changes | You want to understand PR workflow patterns -> use `git-branch-pr-workflow` |

## Your Task

Review PR workflow results and reviewer comments, then address substantive feedback.

For feedback categorization, decision trees, commit format, and report templates, see [REFERENCE.md](REFERENCE.md).

---

### Step 1: Determine PR and Gather All Data

> If `--all` is set, **skip this step** and jump to **Step 1A: Multi-PR Mode** below.

1. **Parse owner/repo** from the git remote URL.

2. **Resolve the PR number** in this order:
   1. If `$1` was provided, use it.
   2. Otherwise, try the PR for the current branch:
      ```bash
      gh pr view --json number -q '.number'
      ```
   3. If step 2 fails (no PR for the branch) **or** the command is on a detached/default branch, fall back to listing actionable PRs:
      ```bash
      bash ${CLAUDE_SKILL_DIR}/scripts/list-actionable-prs.sh <owner> <repo>
      ```
      The script emits a JSON array of open, non-draft PRs that have unresolved review threads, failing/errored CI, or `CHANGES_REQUESTED`. Handle the result as follows:

      | Result | Action |
      |--------|--------|
      | Empty array | Report "No PRs need attention." and stop. |
      | One entry | Use that PR number and continue. |
      | Multiple entries | Print a compact table (number, author, CI, unresolved, reviewDecision, title) ordered as returned, then stop and instruct the user to re-run `/git:pr-feedback <number>`. Do **not** guess which PR they meant. |

3. **Switch to PR branch** if not already on it:
   ```bash
   gh pr view $PR --json headRefName -q '.headRefName'
   git switch <branch-name>
   git pull origin <branch-name>
   ```

4. **Fetch ALL PR data** using the bundled script (single GraphQL query):
   ```bash
   bash ${CLAUDE_SKILL_DIR}/scripts/fetch-pr-data.sh <owner> <repo> <pr-number>
   ```

5. **For failed checks only**, fetch detailed logs:
   ```bash
   gh run view $RUN_ID --log-failed
   ```

| Check Status | Action |
|--------------|--------|
| All passing | Skip to Step 2 |
| Failed CI | Get logs with `gh run view`, may need fixes |
| Pending | Note status, focus on comments |

If the GraphQL query fails with a rate limit error, wait 60 seconds and retry once.

---

### Step 1A: Multi-PR Mode (--all)

Reached only when `--all` is passed. The orchestrator dispatches one subagent per actionable PR; subagents commit inside isolated worktrees but never push. The orchestrator handles all GitHub-side mutations.

1. **Parse owner/repo** from the git remote URL.

2. **List actionable PRs** with the bundled selector (append `--include-automation` if that flag was passed):
   ```bash
   bash ${CLAUDE_SKILL_DIR}/scripts/list-actionable-prs.sh <owner> <repo>
   ```
   The script returns a JSON array of open, non-draft PRs with unresolved review threads, failing/errored CI, or `CHANGES_REQUESTED`. Automation-authored PRs (release-please, dependabot, renovate, `*[bot]`, `*-bot`) are excluded by default — dispatching a subagent on one is almost always wrong (no review threads to act on, protected changelog/version files). Pass `--include-automation` to include them, or set `PR_FEEDBACK_AUTOMATION_AUTHORS` to extend the recognised author list. If the array is empty, report `No PRs need attention.` and stop.

3. **Print a compact dispatch table** (number, author, ci, unresolved, reviewDecision, head, title) so the user can see what is about to be processed.

4. **`--dry-run` short-circuit**: if `--dry-run` was also passed, additionally print the per-PR subagent prompt that *would* be dispatched (one per row, using the template in [REFERENCE.md](REFERENCE.md) "Multi-PR Subagent Prompt"), then stop. No subagents spawn, no commits, no pushes.

5. **Dispatch subagents**, capped at `--limit N` concurrent (default `3`). For each PR call the `Task` tool with:
   - `subagent_type: "general-purpose"`
   - `isolation: "worktree"` — each subagent gets its own git worktree
   - `description`: `Address review feedback for PR #<n>`
   - `prompt`: see [REFERENCE.md](REFERENCE.md) "Multi-PR Subagent Prompt" for the canonical template. The prompt must instruct the subagent to switch its worktree to the PR's `headRefName`, run the single-PR feedback flow with `--commit` (not `--push`), and return a structured JSON summary.

   Dispatch one batch of `N` `Task` calls in a single message (per the parallel-dispatch contract). When all return, dispatch the next batch until the queue is empty.

6. **Collect subagent results**. Each subagent returns JSON with: `pr`, `branch`, `worktree_path`, `commits[]`, `addressed[]` (each with `thread_id`, `database_id`, `action`, `reply`, `resolve`), `deferred_issues[]`, `co_authors[]`, `blockers[]`. Treat any subagent that fails to return parseable JSON as blocked — record its raw output and continue with the rest of the batch.

7. **Orchestrator finalisation** — for each PR with successful commits, run sequentially (push and the GitHub mutation tools share the same rate-limit pool):
   1. `git push origin <branch>` from the **main checkout** — worktrees share the underlying `.git/`, so commits made by the subagent are already visible by branch name. No `cd` into the subagent's worktree is required.
   2. Capture the resolving SHA (`git rev-parse origin/<branch>` after the push).
   3. For each `addressed[]` entry, post the reply via `mcp__github__add_reply_to_pull_request_comment`, substituting the resolving SHA into any `{{SHA}}` placeholder the subagent left in the reply text.
   4. Resolve threads via the GraphQL `resolveReviewThread` mutation per Step 6's rules. Resolution is the default after a reply — only skip when the subagent set `resolve: false`