review-pr

What this skill does

Review a pull request and provide detailed feedback on the changes.

## Modes

The skill has three modes, selected by an optional argument:

- `findings` — display review findings only; never modify code or post to GitHub
- `fix` — display findings, then walk through each issue and apply local fixes as commits
- `post` — display findings, then post review comments to GitHub via `gh api`

If no argument is provided, run the findings phase first, then use `AskUserQuestion` to ask whether to `fix`, `post`, or `stop`.

## Review Steps (all modes)

1. Fetch PR details and full diff using `gh pr view` and `gh pr diff`. If the diff is empty, stop and tell the user.
2. Skip generated/vendored files: lock files (`*.lock`, `package-lock.json`, `yarn.lock`), `*.designer.cs`, auto-generated code, vendored dependencies
3. For large PRs, prioritize the most-changed files first
4. Focus on actionable issues, not positive feedback

## Findings Phase (always run first)

- Display all review findings in the CLI output only
- Label each comment with a severity emoji: 🔴 CRITICAL, 🟠 HIGH, 🟡 MEDIUM, 🟢 LOW
- Sort comments by severity (most critical first), then by file path and line number:
  1. 🔴 **CRITICAL**: Security vulnerabilities, data loss, crashes
  2. 🟠 **HIGH**: Logic errors, bugs, incorrect behavior
  3. 🟡 **MEDIUM**: Performance issues, missing error handling
  4. 🟢 **LOW**: Code style, minor improvements, suggestions
- Keep the summary concise: one line per issue with severity, `file_path:line_number`, and a brief description

If no issues were found, say so and stop regardless of mode.

## After Findings

Behavior after the findings phase depends on the mode:

- **`findings` mode**: stop here.
- **`fix` mode**: continue to "Fix Flow" below.
- **`post` mode**: continue to "Post Flow" below.
- **No mode argument**: use `AskUserQuestion` with options `fix`, `post`, `stop`. Then run the corresponding flow (or stop).

## Fix Flow

DO NOT post any comments to GitHub in this flow.

### Step 1 — Ask About Each Issue

For each issue in order, use `AskUserQuestion` to ask what to do. Offer options:
- **"Fix it"** — investigate and implement a fix
- **"Skip"** — do nothing for this issue

Collect answers for **all** issues before applying any fixes. Track each answer as `{issue index, severity, file:line, action}`.

### Step 2 — Apply Fixes

After all answers are collected, work through each "Fix it" issue in order (most critical first):

1. Make the code change
2. Stage and commit the change following the `git-commit` skill conventions (imperative mood, concise subject ≤ 50 chars)
3. Move to the next "Fix it" issue

Skipped issues are not touched.

### Step 3 — Final Summary

If any changes were committed, show a summary listing:
- Issues fixed, with the commit subject for each
- Issues skipped

If no changes were made, no summary is needed.

## Post Flow

- Use `gh api` to create a review with specific line comments
- Endpoint: `repos/OWNER/REPO/pulls/PR_NUMBER/reviews`
- Each comment must specify: `path`, `line` (or `start_line`/`end_line`), `body`
- Include footer in review body: `"\n\n---\n*Review by Claude Code*"`
- ALWAYS use event type: `COMMENT`
- NEVER use `REQUEST_CHANGES` or `APPROVE` — human review required
- Group related comments under a single review

### Comment body guidelines

- Reference code directly with `file_path:line_number`
- Explain why something is an issue, not just what
- Suggest a concrete fix when possible