pr-review

# PR Code Review (Local)

Perform a thorough local code review with full project context - reads source files directly, no API truncation limits.

**Announce at start:** "I'm using pr-review skill to review the pull request."

## Usage

```
/pr-review [pr_number]
```

`$ARGUMENTS` may contain an optional PR number and/or `--automation` flag.

- Without `--automation`: interactive mode (prompts for confirmation, comment, cleanup)
- With `--automation`: non-interactive mode (auto-post comment, auto-delete branch, output machine-readable result)

---

## Steps

### Step 1 - Determine PR Number

If `$ARGUMENTS` is non-empty, use it as the PR number.

Otherwise run:

```bash
gh pr view --json number -q .number
```

If this also fails (not on a PR branch), abort with:

> No PR number provided and cannot detect one from the current branch. Usage: `/pr-review <pr_number>`

Also parse `--automation` from `$ARGUMENTS`:

```bash
AUTOMATION_MODE=false
if echo "$ARGUMENTS" | grep -q -- '--automation'; then
  AUTOMATION_MODE=true
fi
```

### Step 2 - Check CI Status

```bash
gh pr view <PR_NUMBER> --json statusCheckRollup \
  --jq '.statusCheckRollup[] | {name: .name, status: .status, conclusion: .conclusion}'
```

**Required jobs to check:**

- `Code Quality`
- `Unit Tests (ubuntu-latest)`
- `Unit Tests (macos-14)`
- `Unit Tests (windows-2022)`
- `Coverage Test`
- `i18n-check`

(`build-test` is an optional job and is not included in the required check list.)

**Special cases:** Skip this step and proceed directly when either of the following is true:

- `statusCheckRollup` is empty (CI was never triggered)
- `statusCheckRollup` is non-empty, but none of the required jobs appear in the list (indicating the pr-checks.yml workflow was not triggered at all - e.g. a PR that only touches docs/md files)

**Parsing logic:** Handle three cases:

**Informational checks exclusion:** `codecov/patch` and `codecov/project` are configured as `informational: true` in `codecov.yml` - they never block merging and must be **excluded** from all failure checks below. Treat them as non-existent when evaluating CI status.

**Case 1 - All passing** (all required jobs satisfy `status == COMPLETED && conclusion == SUCCESS`, **and** no **non-informational** job in `statusCheckRollup` has a `conclusion` of `FAILURE` or `CANCELLED`; `codecov/*` failures do not affect this determination)

Proceed to the next steps without prompting.

**Case 2 - Some still running** (at least one required job has `status` of `QUEUED` or `IN_PROGRESS`; non-required jobs still running do not affect this determination)

Display a warning and ask:

> ⏳ The following CI jobs are not yet complete: [job list]
> Not all PR CI jobs have finished - it is recommended to wait before reviewing. Continue anyway? (yes/no)

- User selects **no** → abort
- User selects **yes** → continue to next steps

- **Automation mode:** do not prompt. Output signal and stop:
  ```
  <!-- automation-result -->
  CONCLUSION: CI_NOT_READY
  IS_CRITICAL_PATH: false
  CRITICAL_PATH_FILES: (none)
  PR_NUMBER: <PR_NUMBER>
  <!-- /automation-result -->
  ```
  Then exit.

**Case 3 - Failures exist** (any **non-informational** job in `statusCheckRollup` has a `conclusion` of `FAILURE` or `CANCELLED`, not limited to the required job list; `codecov/*` is always excluded)

Display a warning and ask:

> ❌ The following CI jobs did not pass: [job list with conclusions]
> PR CI has failures - review conclusions may be inaccurate. Continue anyway? (yes/no)

- User selects **yes** → continue, and append a CI status warning at the end of the "Change Summary" section in the final report (see the "Report Enhancement" section for format)
- User selects **no** → abort the review, then immediately ask:

  > Would you like to post a comment on PR #\<PR_NUMBER\> to notify the author to fix the failing CI jobs? (yes/no)
  - User selects **yes** → post the CI failure reminder comment (see "CI Failure Reminder Comment" section below), then exit
  - User selects **no** → exit directly

- **Automation mode:** do not prompt. Post CI failure comment automatically (same format as "CI Failure Reminder Comment"), then output signal and stop:
  ```
  <!-- automation-result -->
  CONCLUSION: CI_FAILED
  IS_CRITICAL_PATH: false
  CRITICAL_PATH_FILES: (none)
  PR_NUMBER: <PR_NUMBER>
  <!-- /automation-result -->
  ```
  Then exit.

#### CI Failure Reminder Comment

When CI has failed and the user chooses not to continue the review but opts to post a reminder, use this comment format:

```bash
gh pr comment <PR_NUMBER> --body "<!-- pr-review-bot -->

## CI Checks Failed

The following jobs did not pass at the time of this review. Please fix them:

| Job | Conclusion |
|-----|------------|
| <failing job name> | ❌ <FAILURE or CANCELLED> |

Code review is on hold until all CI checks pass, at which point it will be re-run."
```

(List only the jobs that actually failed; skip any that passed.)

#### Report Enhancement

When CI has failures but the user chooses to continue, append the following at the end of the "Change Summary" section in the final report:

```
> ⚠️ **CI Status Warning**: The following jobs did not pass at review time: `<job name>` (<conclusion>). This report's conclusions are for reference only - it is recommended to fix CI and re-review.
```

---

### Step 3 - Create Worktree

Create an isolated worktree for this PR review. The main repo stays on its current branch.

```bash
REPO_ROOT=$(git rev-parse --show-toplevel)
PR_NUMBER=<PR_NUMBER>
WORKTREE_DIR="/tmp/wayland-pr-${PR_NUMBER}"

# Clean up any stale worktree from a previous crash
git worktree remove "$WORKTREE_DIR" --force 2>/dev/null || true

# Fetch PR head AND base branch so the three-dot diff is accurate
git fetch origin pull/${PR_NUMBER}/head
BASE_REF=$(gh pr view ${PR_NUMBER} --json baseRefName --jq '.baseRefName')
git fetch origin "$BASE_REF"
git worktree add "$WORKTREE_DIR" FETCH_HEAD --detach

# Symlink node_modules so lint/tsc/test can