pr-review

name	pr-review
description	Review a pull request. Accepts an optional GitHub PR number and/or scope (frontend | backend | db). Examples: /review · /review frontend · /review 123 · /review 123 db

You are executing the /review skill. Follow these steps exactly.

Step 1 — Parse arguments

From the args passed to this skill, extract:

• PR_NUMBER: the first token if it is all digits, otherwise absent
• SCOPE: the first token that is one of frontend, backend, db; otherwise general

Examples: (no args) → PR_NUMBER=none, SCOPE=general frontend → PR_NUMBER=none, SCOPE=frontend 123 → PR_NUMBER=123, SCOPE=general 123 db → PR_NUMBER=123, SCOPE=db

Step 2 — Gather context (run in parallel)

If PR_NUMBER is set: gh pr view {PR_NUMBER} --json title,body,author,baseRefName,files,number gh pr diff {PR_NUMBER}

If PR_NUMBER is absent: git diff main...HEAD git log main...HEAD --oneline gh pr view --json title,body 2>/dev/null || echo "NO_PR"

Step 3 — Understand the intent

Read the PR title and body (or commit messages). Note what the change is supposed to do. For large diffs (> 400 lines), use Read and Grep on the most critical changed files rather than reading the entire raw diff.

Step 4 — Run the scope checklist

Run only the checklist for the active SCOPE. For general, run all five lenses. Skip any lens with no real findings — do not pad the review.

frontend lens

• React correctness: missing key props, stale closures in hooks, effect dependency arrays
• Zustand stores: mutations outside actions, missing resets on unmount, store shape drift
• Drag-and-drop (DnD): missing droppable/draggable IDs, incorrect onDragEnd mutation order
• FeatureGate usage: new UI surfaces not wrapped in <FeatureGate flag="…"> where required
• Accessibility: interactive elements missing aria-* or keyboard handlers, color-only cues
• Network calls: raw fetch instead of the shared axios instance; missing error states in UI

backend lens

• Hono routes: missing requireAuth or requireFeature middleware on protected endpoints
• RBAC: canRead/canWrite/canManageUsers from lib/projectAccess.ts not called; epic access not checked via lib/epicAccess.ts
• Response envelope: responses not wrapped in { data: … } / { error: … } convention
• SSE / eventBus: mutations not emitting the right event type on lib/eventBus.ts
• Feature flags: new flag not registered in all four sync points (featureFlags.ts, adminSettings.ts, featureFlagStore.ts, env-var table in CLAUDE.md)
• Input validation: user-supplied values used in SQL or shell without sanitisation

db lens

• Schema safety: NOT NULL columns added without a DEFAULT on an existing table (breaks SQLite ALTER TABLE)
• Missing indexes: foreign key columns or frequently-queried columns without an index
• Cascade behaviour: FK without ON DELETE CASCADE / ON DELETE SET NULL where appropriate
• Default-item invariants: deleting or mutating a default project/sprint/epic/feature without the 409 guard
• Migration order: schema changes that would break existing rows if run on a live DB
• Data loss: DROP COLUMN, DROP TABLE, or destructive UPDATE without a backup note

general lens (all five of the original lenses)

• Correctness / logic: off-by-one, wrong conditions, unhandled edge cases, bad async/await, race conditions, missing null guards
• Security: unvalidated input to DB/filesystem/shell; secrets in source; missing auth; unsafe eval
• Code quality: functions doing too many things, duplicated logic, dead code, confusing names
• Test coverage: new paths with no test; happy-path-only tests when edge cases exist
• Docs completeness: public endpoints or exports without JSDoc; user-visible changes without README/changelog entry

Step 5 — Write the review

Output in this exact format:

---

PR Review — [<SCOPE>]

Summary

One to three sentences: what the change does, whether the approach is sound, and the top concern (or "looks good" if none).

Findings

[MUST]

File: path/to/file.ts (line N) What the problem is and why it matters. One concrete fix suggestion.

[SHOULD]

File: path/to/file.ts (line N) What could be improved and the recommended approach.

[NIT]

File: path/to/file.ts Minor suggestion. Keep brief. At most two NITs total — omit the rest.

Verdict

APPROVE / REQUEST CHANGES / COMMENT One sentence explaining the verdict.

Severity guide:

• [MUST] — Blocks merge. Bug, security issue, data-loss risk, or broken invariant.
• [SHOULD] — Strong recommendation: poor coverage, readability, or pattern inconsistency.
• [NIT] — Optional. Never more than two per review.

Verdict logic:

• Any [MUST] → REQUEST CHANGES
• Only [SHOULD] or [NIT] → COMMENT
• No findings or NIT only → APPROVE

If there are no findings at all: output "### Findings\nNone — looks good." and APPROVE.