---
name: review-local-changes
description: Review staged or unstaged local repository changes before commit, especially when the user asks for a local PR-style review, pre-commit review, source-control review, changed-files review, or invokes /review-local-changes. Use to evaluate correctness, completeness, tests, coding standards, security/privacy risks, documentation, and American English spelling without requiring a GitHub PR.
---

# Review Local Changes

Perform a focused code-review pass over the local changes visible in the repo. Treat staged changes as the review target when any exist; otherwise review all unstaged and untracked local changes.

## Workflow

1. Read the repository instructions first:
   - `AGENTS.md`
   - `.claude/session_state.md` when present
   - any nested instructions that apply to changed files
2. Identify the review target:
   - Run `git status --short`.
   - If `git diff --cached --name-only` returns files, review staged changes with `git diff --cached`.
   - Otherwise review unstaged tracked changes with `git diff` and inspect untracked files listed by status.
3. Inspect the changed files enough to understand intent:
   - Read each changed file in full before making claims about it.
   - Compare against nearby tests, route handlers, schemas, prompts, and docs when the change touches those contracts.
4. Review for:
   - Correctness: broken logic, edge cases, state transitions, tenant isolation, auth/RBAC, async jobs, email behavior, migrations, and error handling.
   - Completeness: missing files, stale docs, config/schema drift, prompt-template violations, incomplete UI states, accessibility gaps, or unfinished placeholders.
   - Tests: required tests from project rules, stale assertions, hollowed-out tests, missing route/agent/state-machine coverage, and whether the right suite was run.
   - Standards: existing code style, local abstractions, no hardcoded long prompts outside `prompts/`, no unnecessary new variants/files, conventional project patterns.
   - Language: American English spelling in user-facing copy and docs: organization, behavior, color, canceled, customize, analyze.
   - Operational risk: secrets, production config accidents, destructive commands, deploy/migration ordering, memory-heavy workflows, and noisy generated artifacts.
5. Report findings only; do not edit files unless the user explicitly asks for fixes.

## Output

Lead with findings, ordered by severity. Use file and line references when possible.

Use this shape:

```text
Findings
- High: [file:line] ...
- Medium: [file:line] ...
- Low: [file:line] ...

Open Questions
- ...

Tests/Verification
- ...
```

If there are no findings, say that clearly and mention any residual risk or tests that were not run.

Keep summaries secondary and brief. The goal is to catch what would matter before committing, not to congratulate the diff.