---
name: review
description: Structured code review with two-pass approach (spec compliance then code quality). Use when the user asks to review code, review a PR, audit changes, check for security/performance/reliability issues, or run a code quality check.
---

# Code Review

Run a structured, token-efficient code review. Two passes: spec compliance first, then code quality. Stop and report if spec compliance fails before moving to quality.

## When to Apply

- User asks to "review", "audit", "check", or "look over" code or a PR
- User asks for a specific review type (security, performance, etc.)
- User asks to review changes against a plan or spec

## Workflow

### 1. Identify review type(s)

Pick one or more from: Security, Performance, Reliability/Resilience, Load/Scalability, Storage/Data, Privacy/Compliance, Observability/Operations, Cost/Resource, Dependencies/Supply Chain, Data Structures, Code Quality, Accessibility/UX, AI Safety/Behavior.

If the user doesn't specify, infer from the changes being reviewed.

### 2. Locate start files

Use the review type to pick targeted entry points — don't scan the whole repo:

- **Security**: auth modules, API routes, file handling, config, DB schema — in this repo: `apps/web/src/lib/security/` (auth + `*-route-access.ts` guards), `apps/web/src/app/api/`
- **Performance**: hot paths, query-heavy code, loops, caching layers
- **Reliability/Resilience**: error handling, retry logic, timeout/retry settings, queue processing
- **Load/Scalability**: concurrency limits, resource pools, pagination, batch processing
- **Storage/Data**: DB schema, migrations, file handling, import/export
- **Privacy/Compliance**: API responses, data exposure, export routes, PII handling
- **Observability/Operations**: logging, metrics, health checks, status endpoints
- **Cost/Resource**: usage tracking, external API calls, resource allocation
- **Dependencies/Supply Chain**: `package.json`, lock files, dependency versions — in this repo: follow `docs/maintainers/dependency-upgrade-protocol.md`; check `apps/web/scripts/security/check-locked-min-versions.mjs` and `apps/web/scripts/quality/check-overrides-drift.mjs` still pass
- **Data Structures/Types**: type definitions, interfaces, shared models
- **Code Quality/Maintenance**: only files touched by the change
- **Accessibility/UX**: UI components, form handling, keyboard navigation
- **AI Safety/Behavior**: prompt construction, tool use, guardrails, model config

### 3. Two-pass review

**Pass 1 — Spec compliance**: Confirm requirements/plan coverage. Flag missing or extra behavior. If this pass fails, **stop and report before quality notes.**

**Pass 2 — Code quality**: Evaluate maintainability, correctness, tests, and error handling.

**SkyTest Agent quick checks** (apply in pass 2 when the change touches these areas):

- New/changed API route: `verifyAuth` at route start, ownership/access guard (`team-route-access` / `project-route-access` / `test-case-route-access`), input validated, no sensitive fields in responses
- User-facing text: i18n keys present in all three locales (`en`, `zh-Hant`, `zh-Hans`) in `apps/web/src/i18n/messages.ts`
- No new Prisma/queue instances (singletons from `lib/core/`), no `any` types, no hardcoded values (use `config/app.ts`)
- Runtime behavior changes: matching updates in `docs/operators/`, `docs/maintainers/`, `infra/`

### 4. Output format

Structure findings as:

```
## Spec Compliance

| # | Severity | Risk | Evidence (file:line) | Recommendation |
|---|----------|------|---------------------|----------------|
| 1 | High     | ...  | `src/auth.ts:42`    | ...            |

## Code Quality

| # | Severity | Risk | Evidence (file:line) | Recommendation |
|---|----------|------|---------------------|----------------|
| 1 | Medium   | ...  | `src/handler.ts:15` | ...            |

## Quick Wins (optional)
- ...

## Follow-ups (optional)
- ...
```

## Token-Saving Defaults

- Avoid repo-wide scans unless explicitly requested
- Prefer targeted search and small read windows
- Read only relevant files — don't read everything in a directory
- Use `git diff` to scope changes when reviewing a PR or recent work
