/fetch-pr-review

name: fetch-pr-review
description: Fetch all reviewer comments left on your own pull request (GitHub, Azure DevOps, …) and save them as a self-contained markdown PR-REVIEW file in the task's planning directory. Fetch only — no fixing or replying.
license: MIT
metadata:
  version: "1.10"

PR review fetcher

**Fetch only** — capture the review feedback left on a pull request; never fix code, reply, or judge the comments. Output is a self-contained `.PR-REVIEW.md` a fresh session can pick up and act on (e.g. via `/refine-pr-review`). Someone else's PR to review is not this skill's job: use `review-code-assistant` or `maintainer-review` when available.

Source & access

Identify the platform from the PR URL (host shape) and fetch through the matching MCP server or CLI — e.g. **GitHub MCP / `gh`** for GitHub PRs, **Azure DevOps MCP** for ADO pull requests. Use whichever equivalent tools are connected; tool name prefixes vary by config. Fetch each stream through its last page, thread replies included: metadata, review verdicts, inline threads with their resolution and outdated flags (usually a thread-level API, not the flat comment list), conversation comments. If the input is ambiguous, or no matching MCP/CLI is available, ask the user / stop — don't guess.

Golden rule: never assume — ask

Every uncertainty is confirmed with the user before proceeding: a thread's resolved status, the planning directory, the slug, anything ambiguous in between. A plausible guess is a question, not an answer.

Your task

1. **Resolve the input.** Accept a full PR URL; extract repo/project and PR id. If unrecognizable, ask. 2. **Fetch the PR metadata** — title, description, source/target branch, head commit (short SHA), state, author, linked ticket/work item — and **all feedback**:

• inline review threads (file, line, code context, full reply chain, permalink);
• top-level review verdicts (approve / request changes / …) with their summary text — one per

submitted review, never one per reviewer;

• general conversation comments;
• bot comments (CI, linters, coverage, …) — captured too, but grouped separately from human

feedback. Mark every comment by the PR author `(author)`. 3. **Determine each thread's status** (see Status flags). 4. **Decide the output directory** — the planning directory of the task the PR belongs to, following the project's/user's convention for where plans live (default: `.agents/plans/`). Guess the task's existing home from PR context (linked ticket id, branch name, PR title) — its `<id>-<slug>/` subdirectory, or the shared parent/group directory holding its `<id>-<slug>.TICKET.md` when the ticket lives flat there — and **confirm the guess with the user**; when not sure, always ask. If no matching exists, propose a new `<id>-<slug>` (ticket id prefix when bound to one, kebab-case slug from the PR title), confirm, and create it. 5. **Pick the file name** — `<slug>.PR-REVIEW.md`, where `<slug>` is the planning directory name — in a shared directory, the ticket's own `<id>-<slug>` instead (e.g. `1234-some-task.PR-REVIEW.md`). If it already exists, a new review round (see Later rounds) writes `<slug>.PR-REVIEW-2.md`, `-3`, … — **never overwrite**; history per round is kept on purpose. 6. **Write the document** (see structure below). 7. **Print the result** — project-relative paths and the next-step line.

Later rounds

A review round is new reviewer activity since the latest PR-REVIEW file: a review, a thread, a reply, a reopened thread, a thread resolved or marked won't fix. A thread merely becoming outdated after a push is not activity. The `-N` file holds only that activity, each touched thread whole, plus a `## Since round N-1` block: head then and now, and a then/now status table for every earlier thread whose status changed — so a resolution-only round still gets its file. No activity is a refresh, not a round, even when the head moved: write nothing, say so with the current head without asking, and hand off the latest existing file (see Next step).

Status flags

Capture **every** comment, resolved or not, with its state from the platform's own signal (e.g. GitHub thread resolution, ADO thread status):

• **Open / active** → actionable; no flag needed.
• **Resolved** (closed, fixed, won't fix, …) → keep it, marked **resolved**, with the platform's

original status verbatim — `wontFix` is resolved but carries different intent than `fixed`.

• **Outdated** (anchored to code later commits changed) → distinct **outdated** flag, never merged

into resolved: the code moved, but **the concern may still be valid** — say so in the document.

• **Unclear** — the platform gives no clear signal, or the thread reads ambiguous (e.g. a reply

says "done" but the thread is still open) → **ask the user** how to mark it; never decide alone.

Document structure

Must stand on its own: a fresh session with no access to the PR must be able to locate every spot in the code and understand every piece of feedback without re-fetching.

# PR review: <title>

> **Source** [<PR id>](<url>)
> **Branch** <source> → <target>
> **Head** <short sha>
> **State** {open/merged/…}
> **Author** {display name}
> **Linked ticket** [<id>](<url>) — omit if none
> **Fetched** {now, ISO 8601 with UTC offset}

## Description            — verbatim, or one line saying it is empty
## Since round N-1        — `-N` files only (see Later rounds)
## Review verdicts        — one per submitted review, newest first: verdict + summary text, plus
                            the commit it was submitted against and its permalink when the
                            platform gives them
## Inline threads         — one ### per thread: `path:line` + the opening quote, the thread's
                            permalink, quoted code context/diff hunk, comments oldest first as
                            <author> — <date>, status flag
## General comme