review-orchestrator git:20260926.3185b84A

Immutable. This exact content never changes and is served at /api/v1/blob/4fbf7483d6a7872e.

---
name: review-orchestrator
description: Shared comprehensive review engine for the review commands. Use when running /changes-review or /project-review, or when a full multi-layer review is requested, to map scope, delegate to the relevant specialized skills, and produce one evidence-based report.
---
# Review Orchestrator

## Purpose

Provide one shared review engine so `/changes-review` and `/project-review` stay consistent and the specialized skills stay small. Coordinate skills; do not duplicate their instructions.

## Detect the scope

- For current work: staged, unstaged, and relevant untracked source files, plus branch changes needed to understand the work.
- For the whole project: the repository map, architecture, and major modules, excluding generated and vendor artifacts.
- Detect the stack first: language, framework, package manager, data layer, auth, deployment target, and available verification commands.

## Determine the impact radius

Do not review only changed lines. When a changed file depends on or affects another component, inspect enough surrounding code to verify the integration: shared types, callers, consumers, persistence, authorization rules, and tests.

## Delegate to the relevant skills

Load only the skills the detected code actually needs:

- `frontend-review` for UI, responsive behavior, accessibility, and frontend state.
- `backend-review` for handlers, services, jobs, webhooks, and async behavior.
- `database-review` for queries, schema, data integrity, and migration safety.
- `security-review` for authentication, authorization, secrets, input, and sensitive logging.
- `integration-review` for the seams between layers.
- `api-design` for contracts, pagination, versioning, and error shapes.
- `architecture-review` for structural risk in the change.
- `test-strategy` when verification is missing or insufficient.
- `performance-review` when measurement is available or cost is suspicious.
- `dependency-review` when dependencies change.

Do not run every skill because it exists. A CSS-only change does not need database review; a query change does not need frontend review.

## Read-only rule

During the initial review, do not edit files, create fixes, delete or format files, upgrade dependencies, change configuration, commit, push, merge, deploy, or mutate databases. Safe tests, lint, typecheck, build, and non-destructive diagnostics are allowed when useful.

## Evidence and severity

Base every finding on inspected code or an executed check. Distinguish confirmed issues from risks needing verification and label the latter `Needs verification`. Use Critical, High, Medium, Improvements, and Passed / No Issue Found. Avoid arbitrary numeric quality scores.

## Approval gate

End the report by stating that no project files were modified and asking whether to implement the findings. Wait for explicit approval such as `Fix finding #2` or `Implement critical findings only`. Never treat `okay`, `interesting`, `I see`, or `explain this` as approval. After approved fixes, rerun the relevant checks and report what remains.