review-pr

name	review-pr
description	Review a pull request — interactive PR selection via `gh`, 4-dimension code review (hallucinated code, architecture, performance, test validity), then post severity-graded comments with fix suggestions on the PR. Not for spec-based review — use `review` instead.

Acceptance Criteria

• Every finding traceable to specific lines in the diff
• Findings presented to the user with suggested fixes before posting
• Each posted comment includes severity (P0–P3) and a concrete fix suggestion
• Verify: confirm every file in the diff was read before reporting findings
• Verify: confirm all gh pr comment posts completed successfully
• No code is modified

Severity Scale

Level	When to assign
P0 — Critical	Main functionality broken; business logic contradicts design intent
P1 — Major	Secondary functionality broken
P2 — Minor	Edge functionality broken
P3 — Trivial	Rare boundary conditions cause incorrect behavior

Review Dimensions

Examine every changed file through all four lenses. For each finding record: file, line range, severity, description, and suggested fix. Cross-reference dimensions — one change may have findings in multiple.

When reviewing, watch for:

• Hallucinated Code — APIs, imports, config keys, env vars, or endpoints that don't exist in this project's dependencies or runtime. Methods that don't exist on their target object, imports missing from dependency manifests, external contracts that don't match reality.
• Architecture Defects — Layer violations, circular dependencies, bypassing reusable abstractions, patterns inconsistent with the rest of the codebase.
• Performance Defects — N+1 queries, hot-path allocations, missing cache on repeated operations, blocking the event loop, loading more data than needed, hoistable computation.
• Test Validity — Business logic changes tested meaningfully (not tautologies, over-mocking, or coincidental setup). Edge cases (empty states, errors, boundaries) covered. Tests actually invoke the changed code.

Workflow

1. Identify the Target PR

If the user provided a PR number or URL, confirm it with gh pr view. Otherwise list open PRs, present a table, and let the user pick.

2. Fetch Full Context

Fetch PR title, body, files, diff, and existing comments. Note base and head branches — they frame scope.

3. Review Across All 4 Dimensions

Read every changed file. Group findings by severity (P0 → P3).

Verify completeness: cross-reference the list of changed files against your findings. For any file with no findings, confirm to the user it was reviewed and deemed clean before proceeding.

4. Present for Confirmation

Show the user the full finding list grouped by severity with a summary table. Ask explicitly whether to post — wait for confirmation.

5. Post Comments

Post one gh pr comment per finding. Each comment follows this format:

**P# — Dimension Name**
**File:** `path/file.ts:L42`
**Issue:** clear description
**Suggested Fix:** actionable suggestion (with code if applicable)

Verify posting: After all posts, check gh pr view --json comments to confirm every finding has a matching comment. Compare actual post count to expected. Then summarize: Posted N findings (P0: x, P1: y, P2: z, P3: w) on PR #N.

Requirements

• gh CLI installed and authenticated (gh auth status)
• Current directory is a git repo with origin, or user provides --repo owner/name
• Consult references/gh-pr-cheatsheet.md for exact gh pr flags