- Evidence: <file:line or diff/context> - Why it matters: <production/user/developer impact> - Suggested fix: <specific action> - Acceptance criteria: <how re-review can verify it> ### P2 Medium - [ ] CR-002 (P2) <title> - Evidence: <file:line or diff/context> - Why it matters: <production/user/developer impact> - Suggested fix: <specific action> - Acceptance criteria: <how re-review can verify it> ### P3 Low None. ## Verification - Checks run: <commands or "not run"> - Recommended next checks: <commands/manual QA> ``` Rules: - Use `None.` for severities with no findings. - The checklist is the only status source. Do not add a separate re-review status template. - Keep `CR-*` ids stable across re-reviews; new findings continue the next unused number. - Add `## Re-review history` only after a re-review has happened. ## Re-review Workflow When the user asks for a re-review: 1. Require the branch name exactly as in a normal review. 2. Load `.ai-reviews/safe-code-review/<branch-slug>.md`. 3. Re-gather `git diff`, changed files, and relevant code context for `<base>...<branch>`. 4. For every saved checklist item, mark one status: - `- [x] CR-001 (P1) fixed - <evidence>` when the issue is addressed. - `- [ ] CR-001 (P1) still open - <evidence>` when the issue remains. - `- [-] CR-001 (P1) partially fixed - <remaining gap>` when some acceptance criteria are met, but risk remains. - `- [?] CR-001 (P1) not verifiable - <reason>` when local context cannot prove the result. 5. Update the same saved checklist in place and append a short `## Re-review history` entry with date, summary, and checks run. 6. Do not produce an unrelated fresh review unless new changes create new risks. Add new findings under the right severity with ids continuing the existing sequence. If no previous report exists, say so and run a normal review instead. ## Slack-Ready Output Write the user-facing result so it can be copied into Slack or a PR comment. Use this structure: ```markdown Production Safety: <one short paragraph> PR Score: <N>/5 - <short reason> Blast Radius: - <area>: <impact> - <area>: <impact> P0 Critical - [ ] CR-001 (P0) <title> - Evidence: <file:line or diff/context> - Why it matters: <production/user/developer impact> - Suggested fix: <specific action> - Acceptance criteria: <how re-review can verify it> P1 High - [ ] CR-002 (P1) ... P2 Medium - [ ] CR-003 (P2) ... P3 Low - [ ] CR-004 (P3) ... Verification: - Checks run: <commands or "not run"> - Recommended next checks: <commands/manual QA> ``` If a severity has no items, write `None`. For re-review, use this structure: ```markdown Re-review Summary: <one short paragraph> Production Safety: <updated safety assessment> PR Score: <N>/5 - <short reason> Checklist Status: - [x] CR-001 (P1) fixed - <evidence> - [ ] CR-002 (P2) still open - <evidence> - [-] CR-003 (P2) partially fixed - <remaining gap> - [?] CR-004 (P3) not verifiable - <why> New Findings: <same severity-grouped checklist format, or "None"> Verification: - Checks run: <commands or "not run"> - Recommended next checks: <commands/manual QA> ``` ## Review Heuristics Prioritize findings that affect correctness, production safety, security, data isolation, permissions, compatibility, architecture boundaries, runtime behavior, and missing tests for meaningful business logic. Also check loading, empty, error, permission-denied, and flag-off states for user-facing changes. Do not let automated checks replace review judgment. If checks are not run, state that clearly and explain what should be run.

--- description: Risk-first pull request review for a branch, with production safety score, blast radius, and re-review checklist memory allowed-tools: Read, Grep, Glob, Write, Bash --- # Safe Code Review Review a branch like a senior engineer with deep knowledge of this repository. Your goal is to decide how safe the PR is to merge, identify concrete production risks, and produce feedback the PR author can act on. ## Inputs - Required: branch name, passed as the command argument. - Optional: base branch, default `main`. - Optional: mode, default `review`; use `re-review` when the user asks to check whether previous checklist items were fixed. If no branch name is provided, stop and ask for the branch name. Do not infer it from the current branch. Examples: - `/safe-code-review feature/my-branch` - `/safe-code-review feature/my-branch --base main` - `/safe-code-review feature/my-branch --re-review` ## Repository Context Before judging the PR, read: - `README.md` - `AGENTS.md`, if present - `ARCHITECTURE.md`, if present - `CLAUDE.md`, if present - Any module/package files needed to understand touched code - Any nearest module/package `README.md`, `AGENTS.md`, or `CLAUDE.md` files for touched paths Apply the repository rules from those files, especially module boundaries, import style, package ownership, API/query conventions, feature flags, auth handling, multi-tenancy, and production safety. Treat module/package-local docs as narrower context for touched code. If local guidance conflicts with root guidance, surface the conflict instead of guessing. ## Project-Specific Review Standards This is where you add rules from your own codebase. Do not blindly copy these examples. Replace them with the conventions, boundaries, and risk areas that actually matter in your repo. Example rules: - Architecture: modules under `/src/modules/` should stay isolated; shared behavior belongs in approved shared packages or shared app folders. - API/data layer: UI code should use ``, typed schemas, existing query keys, and the repo's cache-invalidation patterns. - Auth and permissions: flag missing organization/workspace scoping, ownership checks, feature flag checks, permission bypasses, unsafe redirects, and leaked sensitive data. - UI/design system: use your design system components, theme tokens, copy patterns, loading/empty/error states, and accessibility conventions. - Tests: require focused tests for utilities, API controllers, complex hooks, permission-sensitive flows, and risky user workflows proportional to blast radius. ## Review Workflow 1. Validate inputs. - If branch is missing, ask for it and stop. - Use `main` as the base unless an explicit base was provided. - Confirm the branch exists locally or as a remote ref. If it does not, report that the branch must be fetched first. 2. Gather diff context. - Run `git diff --name-status ...`. - Run `git diff --stat ...`. - Run `git log --oneline ..`. - Run `git diff ...` and inspect the full diff. 3. Map the change. - Identify intent from commits, changed files, route/page names, tests, and surrounding code. - Read each human-authored touched file enough to understand the real behavior. - Check nearest module/package docs around touched paths and apply their local guidance. - Search for imports, callers, route registration, query keys, mutation invalidation, shared exports, feature flag definitions, permission checks, and related tests. 4. Build a blast-radius map. Include direct and indirect impact for: - Changed files and modules/packages - Routes, pages, dialogs, flows, and user-visible states - API controllers, schemas, query keys, hooks, stores, and invalidation paths - Auth, organization/workspace isolation, permissions, feature flags, and external integrations - Shared packages, reusable components, build configuration, dependencies, and tests 5. Assess production safety. Answer: if this branch were merged now, what could break in production, who would notice, and how quickly? Consider security, data isolation, regressions, runtime failures, missing flags, migration/compatibility issues, and test gaps. 6. Score the PR. - `1`: do not merge; critical production, security, auth, or data-isolation risk. - `2`: high risk; likely regression, unsafe missing coverage, or broad unverified behavior. - `3`: moderate risk; merge only after listed fixes or manual QA. - `4`: low risk; minor issues only. - `5`: ready; no blocking findings, low blast radius, checks aligned. 7. Produce stable checklist items. - Group by `P0 Critical`, `P1 High`, `P2 Medium`, `P3 Low`. - Each item must have a stable id: `CR-001`, `CR-002`, etc. - Each item must include file/line evidence when possible, why it matters, and a concrete suggested fix. - P0 and P1 items should include an example fix when it would make the requested change clearer. - Do not pad with low-value nits. Prefer no item over a vague item. 8. Save review memory. - Create `.ai-reviews/safe-code-review/` if needed. - Slug the branch by replacing `/`, `\`, spaces, and other non-alphanumeric characters with `-`. - Write `.ai-reviews/safe-code-review/.md`. - Use the exact saved report format below. Do not invent another saved report shape. ## Saved Report Format `.ai-reviews/safe-code-review/.md` is the source of truth for later re-review runs. It must use this structure every time: ```markdown # Code review: ## Review metadata - Branch: `` - Base: `` - Review date: - Head: `` ## Production safety ## PR score /5 - ## Blast radius - : - : ## Checklist by severity ### P0 Critical None. ### P1 High - [ ] CR-001 (P1) - Evidence: <file:line or diff/context> - Why it matters: <production/user/developer impact> - Suggested fix: <specific action> - Acceptance criteria: <how re-review can verify it> ### P2 Medium - [ ] CR-002 (P2) <title> - Evidence: <file:line or diff/context> - Why it matters: <production/user/developer impact> - Suggested fix: <specific action> - Acceptance criteria: <how re-review can verify it> ### P3 Low None. ## Verification - Checks run: <commands or "not run"> - Recommended next checks: <commands/manual QA> ``` Rules: - Use `None.` for severities with no findings. - The checklist is the only status source. Do not add a separate re-review status template. - Keep `CR-*` ids stable across re-reviews; new findings continue the next unused number. - Add `## Re-review history` only after a re-review has happened. ## Re-review Workflow When the user asks for a re-review: 1. Require the branch name exactly as in a normal review. 2. Load `.ai-reviews/safe-code-review/<branch-slug>.md`. 3. Re-gather `git diff`, changed files, and relevant code context for `<base>...<branch>`. 4. For every saved checklist item, mark one status: - `- [x] CR-001 (P1) fixed - <evidence>` when the issue is addressed. - `- [ ] CR-001 (P1) still open - <evidence>` when the issue remains. - `- [-] CR-001 (P1) partially fixed - <remaining gap>` when some acceptance criteria are met, but risk remains. - `- [?] CR-001 (P1) not verifiable - <reason>` when local context cannot prove the result. 5. Update the same saved checklist in place and append a short `## Re-review history` entry with date, summary, and checks run. 6. Do not produce an unrelated fresh review unless new changes create new risks. Add new findings under the right severity with ids continuing the existing sequence. If no previous report exists, say so and run a normal review instead. ## Slack-Ready Output Write the user-facing result so it can be copied into Slack or a PR comment. Use this structure: ```markdown Production Safety: <one short paragraph> PR Score: <N>/5 - <short reason> Blast Radius: - <area>: <impact> - <area>: <impact> P0 Critical - [ ] CR-001 (P0) <title> - Evidence: <file:line or diff/context> - Why it matters: <production/user/developer impact> - Suggested fix: <specific action> - Acceptance criteria: <how re-review can verify it> P1 High - [ ] CR-002 (P1) ... P2 Medium - [ ] CR-003 (P2) ... P3 Low - [ ] CR-004 (P3) ... Verification: - Checks run: <commands or "not run"> - Recommended next checks: <commands/manual QA> ``` If a severity has no items, write `None`. For re-review, use this structure: ```markdown Re-review Summary: <one short paragraph> Production Safety: <updated safety assessment> PR Score: <N>/5 - <short reason> Checklist Status: - [x] CR-001 (P1) fixed - <evidence> - [ ] CR-002 (P2) still open - <evidence> - [-] CR-003 (P2) partially fixed - <remaining gap> - [?] CR-004 (P3) not verifiable - <why> New Findings: <same severity-grouped checklist format, or "None"> Verification: - Checks run: <commands or "not run"> - Recommended next checks: <commands/manual QA> ``` ## Review Heuristics Prioritize findings that affect correctness, production safety, security, data isolation, permissions, compatibility, architecture boundaries, runtime behavior, and missing tests for meaningful business logic. Also check loading, empty, error, permission-denied, and flag-off states for user-facing changes. Do not let automated checks replace review judgment. If checks are not run, state that clearly and explain what should be run.