Review Triage

---
name: review-triage
description: >
  Walks through a pull request's inline review comments one at a time, showing the code, the
  suggestion and an assessment, and waits for the user's decision on each; then applies the
  accepted fixes, verifies, commits, pushes, replies on each thread, and checks for comments
  newer than the last commit before merge. Use when the user wants to triage, go through or
  address PR review comments or findings.
---

# Review Triage

Not every review finding deserves a fix, and some are wrong. The user decides each one; this
skill makes each decision informed and makes sure none is missed.

## Pipeline context

Read `.claude/pipeline.md` before you start. A name in double braces below, such as `{{base}}`,
stands for that name's value in its table.
If a value this skill uses is missing there, stop and tell the user which; do not
guess it.

## Inputs

- **PR number** — if not given, use the PR for the current branch:
  - **On GitHub**: `gh pr view --json number`
  - **On GitLab** (a merge request): `glab mr view {branch} -F json --jq .iid`

## Workflow

### 1. Fetch

The host's way (`{{hosting}}`).

**On GitHub:**

```bash
gh api repos/{owner}/{repo}/pulls/{n}/comments --paginate \
  --jq '.[] | {id, user: .user.login, path, line, created_at, in_reply_to_id, body}'
gh api repos/{owner}/{repo}/issues/{n}/comments --jq '.[] | {user: .user.login, body}'
```

Top-level comments (`in_reply_to_id == null`) are findings; replies are discussion.

**On GitLab**, comments live in discussions. `glab api` has no `--jq`, so pipe it to `jq`:

```bash
glab api projects/:id/merge_requests/{n}/discussions --paginate --output ndjson \
  | jq -c 'select(.notes[0].system | not) | {discussion: .id, resolved: .notes[0].resolved,
      path: .notes[0].position.new_path, line: .notes[0].position.new_line,
      notes: [.notes[] | {id, user: .author.username, created_at, body}]}'
```

A discussion whose first note has a `position` is a finding on the diff; its later notes are the
replies. A discussion with no `position` is a general comment, like a review summary.

Tell the user how many findings there are and their severities.

### 2. One finding per message

Order them so a finding another depends on comes first (e.g. a state change before the preview
that uses it); otherwise most severe first. For each:

- **Location** as a clickable `path:line`, and the relevant code
- **The claim**, in plain words
- **Your assessment** — verify the claim against the code before agreeing. Say *valid*,
  *partly valid* or *wrong*, and why. Check whether the suggested fix would break something
  the reviewer didn't see.
- **Proposed change** — the concrete code or test
- Ask: accept, reject, or change?

Wait for the decision. Apply an accepted change before presenting the next finding; for a new
test, confirm it fails when the behaviour it guards is broken.

### 3. Verify, commit, push

After the last finding, run the CI mirror (`{{pre-flight}}`, read as `.claude/pipeline.md` says), then:

```bash
git add {files changed for the accepted findings}
git commit -m "{type}({feature-name}): address review feedback on PR #{n}"
git push
```

Only with the user's go-ahead: reply on each thread with what changed and the commit hash. For a
rejected finding, reply with the reason. Leave resolving threads to the user.
- **On GitHub**: `gh api -X POST repos/{owner}/{repo}/pulls/{n}/comments/{id}/replies -f body=…`
- **On GitLab**: `glab api -X POST projects/:id/merge_requests/{n}/discussions/{discussion}/notes -f body=…`

### 4. Before merge — late comments

A second review round can land after the fix commit, and it is easy to merge past. Before the
user merges:

**On GitHub:**

```bash
gh api repos/{owner}/{repo}/pulls/{n}/comments \
  --jq '.[] | select(.created_at > "{last commit time}") | {path, line, body}'
```

**On GitLab:**

```bash
glab api projects/:id/merge_requests/{n}/discussions --paginate --output ndjson \
  | jq -c '.notes[] | select((.system | not) and .created_at > "{last commit time}")
      | {path: .position.new_path, line: .position.new_line, body}'
```

Anything returned is unaddressed by definition — triage it the same way.