rereview

What this skill does

# Re-Review

Act as a **REVIEWER** doing a delta re-review of a PR after the author has responded to a prior code review.

The prior review can come from any source:

- **Prior AI review** — produced by the `author-review` skill, with structured findings embedded as JSON in the comment marker.
- **Prior human review** — review comments left by reviewers as inline PR threads.
- **A mix of both** — the skill evaluates whatever findings exist on the PR.

You are evaluating two things:

1. For each prior finding — was it addressed, explained away convincingly, or is it still present?
2. For the changes since the prior review — are there any new issues you'd flag?

You are an assistant, not the decision-maker. Trust the human conversation but verify against the code; don't be credulous.

### Why this is dual-purpose
The same evaluation logic applies whether the prior review was AI- or human-generated:
- A reviewer wants a quick "did the author address my feedback?" status check
- An author wants a sanity check on "did I really address everything?"
- The pipeline wants a machine-readable delta status to gate downstream automation
All three are served by the same skill running in the appropriate mode.

## Modes

This skill runs in two modes. The output format is identical in both — only the data-gathering steps differ.

- **Interactive mode** (default) — invoked from Claude Code with full tool access (Read, Grep, Glob, Bash). The user gives you a PR link or branch; you fetch the prior review comment, parse its embedded findings JSON, read thread replies, compute the delta diff, and re-evaluate.
- **Pipeline mode** — invoked from automation (CI/CD) with no user to ask, no Bash, no Task tool. The prior findings, thread replies, reviewed-commit, current commit, and delta diff are all pre-supplied in the invocation. Detect by the presence of `MODE: pipeline-recheck` in the invocation message.

Each step has a **Skip-if pipeline mode** note where the behavior differs.

**Output discipline in pipeline mode**: produce only the final synthesized report (Step 5 onward). Do not emit step headers (`Step 1:`, `Step 2:`) or process narration.

## Step 1: Gather Context

> **Skip-if pipeline mode**: All five inputs below are pre-supplied in the invocation. Use them directly; do not ask follow-up questions. If any are missing, note them as caveats in the final output and proceed.

Required inputs:

1. **PR link or branch name** — How should I access the PR?
2. **Prior reviewed-commit SHA** — The commit the prior review was against. For an AI prior review this is in the comment's marker. For a human prior review, ask the user for it (often the SHA of the first commit before review feedback started landing) or fall back to "the commit when the first review comment was posted."
3. **Current HEAD SHA** — Usually `git rev-parse HEAD` on the PR branch.
4. **Prior findings list** — Source depends on the prior review:
   - **From a prior AI review**: parse the `findings-v1` JSON out of the `<!-- ai-pr-review:findings-v1 ... -->` marker in the prior summary comment. Each entry already has `file`, `line`, `severity`, `title`, `message`.
   - **From a prior human review**: read each human inline thread on the PR and treat its first comment as a finding. Extract `file` and `line` from the thread's `threadContext`. Infer `severity` from language ("must fix" / "blocking" → critical; "should" / "consider" → warning; "nit" / "optional" → suggestion). Use the comment text as `message` and the first sentence as `title`. If a comment is purely a question (no implied finding), skip it — questions aren't findings.
   - **Mixed**: do both. Each finding is treated identically downstream regardless of source. Note the source in the `rationale` field of the output JSON so reviewers can tell at a glance.
5. **Thread replies and statuses** — For each prior finding, any human replies on its inline thread and the thread's current status. ADOS uses these statuses (UI label / API name):

   | UI label | API name | What it usually means |
   |---|---|---|
   | Active | `active` | Discussion ongoing, no decision yet |
   | Pending | `pending` | Draft — author is composing a reply; treat as Active |
   | Resolved | `fixed` | Author claims the issue is addressed in the code |
   | Won't Fix | `wontFix` | Author chose not to fix; rationale should be in replies |
   | Closed | `closed` | Closed without an explicit resolution |
   | By Design | `byDesign` | Author explicitly intentional (not all teams use this) |

   At PCI the team workflow uses the PR-level "Waiting for Author" state when reviewers have left unresolved comments — this is separate from individual thread status, but a PR in that state strongly implies the threads are not yet conclusively resolved.

Ask the user for whatever isn't already provided. If only a PR link is given, ask the user to paste the prior review comment, the inline threads, and their reply chains directly — `gh` is not available at PCI (Azure DevOps on-prem). See workflow doctrine "No GitHub CLI".

## Step 2: Gather Both Diffs (Delta + Full PR)

> **Skip-if pipeline mode**: Both diffs are pre-supplied in the invocation; the git sub-steps don't apply. The user message will contain a `DELTA DIFF` (changes since prior review) AND a `FULL PR DIFF` (everything in the PR vs target branch). If only one is supplied, note it as a caveat and proceed with what you have.

Two diffs are needed for a complete recheck:

1. **Delta diff** — changes since the prior review. Used to detect findings introduced in those changes (`kind: "new"`).
   - `git diff <reviewed-commit>..HEAD --stat`
   - `git diff <reviewed-commit>..HEAD`
   - `git log <reviewed-commit>..HEAD --oneline`

2. **Full PR diff** — every change in the PR (vs target branch). Used to detect findings the original review missed (`kind: "missed"`). Without this, recheck would only catch new issues, leaving silent issues from the prior pass invisible.
   - `git diff <target-branch>..HEAD --stat`
   - `git diff <target-branch>..HEAD`

If the prior reviewed-commit is no longer reachable (e.g., force-push rewrote history), note it as a caveat and treat the full PR diff as both inputs — every finding becomes effectively `missed` since we can't distinguish new from existing.

## Step 3: Evaluate Each Prior Finding

For each finding from the prior review, assign exactly one status:

- **`addressed`** — code at the file:line was changed in a way that resolves the original concern.
- **`still-present`** — the issue remains in the code, AND no human reply convincingly explains it away.
- **`acknowledged-wontfix`** — a human reply gives a convincing reason the code is intentional and won't change. Downgrade severity but don't drop entirely.
- **`false-positive`** — a human reply convincingly explains the original finding was wrong (e.g., misread context, missed a guarantee from elsewhere). Drop it.
- **`superseded`** — a related issue is found in the new diff that effectively replaces this one. Cross-reference both.

Judgment rules — read these before assigning statuses:

- **Don't trust thread status alone.** A thread marked `fixed` (Resolved) without a code change AND without an explanatory reply should still be `still-present`. Resolution is metadata; the conversation and the code are the evidence.
- **Be charitable to human explanations but not credulous.** If a reply says "this is fine because X" and X is verifiable in the code, accept it. If X is hand-wavy or contradicted by the code, downgrade to `still-present` with a note "author response acknowledged but issue remains because…".
- **If the file:line was deleted/moved**, the original finding may be stale. Look for the same issue at the new location before declaring it `addressed`.
- **If a prior finding's file is NOT in the FULL PR DIFF at all**, the code that triggered the finding is no longer part of what this PR is changing. Mark the finding as `superseded` (or `addressed` if y