Review Pro

---
name: review-pro
description: "One-command AI code review. Runs triage -> relevant specialist reviewers -> synthesis on the current branch and returns the verdict + report. Stack-specific signals are loaded automatically from the repo's .review-pro/ directory. Use to review a branch or PR with review-pro."
version: 0.2.0
---

# Review-Pro (one-command review)

You are the **orchestrator**. Run the entire pipeline on the current branch in ONE pass and return the final verdict + report. Do everything with your own native tools — shell for git, Read/Glob/Grep for files. **Do NOT ask the user to run any scripts.** Do not hand off between stages.

## Procedure

### 1. Prep (native — you do this, not the user)
- **Base branch:** `main`, falling back to `master` if `main` doesn't exist.
- **Changed files:** run `git diff --name-only <base>...HEAD` in your shell. Read each changed file's full contents with Read. (git already excludes gitignored/generated paths from the diff.)
- **Argument (optional):** if the invocation carried an argument, it is either a base branch or ref, or a spec to review against (a file path or an issue URL). Forward a spec argument to triage as the first link of its spec resolution.
- **Installed stacks:** `Glob .review-pro/*/manifest.json`. Each match is a stack the user installed (via `npx review-pro`). These are the repo's **active stacks**. If `.review-pro/` is absent or empty, reviewers run on their core rubric only.

### 2. Triage (you, inline)
Follow the `review-pro-triage` skill. Classify the changed files, detect concern relevance, resolve the spec (emitting `spec_source`), and produce a **dispatch plan**: which reviewers to run + each one's scoped context (per `core/shared/context-policy.md`). Be conservative, when in doubt dispatch, with two exceptions: `spec` runs only when `spec_source.kind` is not `none`, because a spec reviewer with no spec is a guaranteed waste rather than a possible finding; and a reviewer that triage assigned an external premise to runs whether or not the signal map picked it, because a premise routed to a reviewer that never runs is verified by nobody.

### 3. Fan-out — reviewers (subagents, parallel)
For each reviewer in the dispatch plan:

1. **Gather its stack signals.** For each installed stack, Read `.review-pro/<stack>/<reviewer>.md` **if it exists**. Concatenate the ones you find — this is the reviewer's `### Stack signals` content. (The subagent auto-loads its own core skill, so you do NOT need to pass the core rubric — only the stack-specific signals.)
2. **Invoke the `<reviewer>-reviewer` subagent** — in parallel/background if your platform allows, else sequentially. Its prompt contains:
   - `### Stack signals` — the concatenated pack files from step 1 (omit the section if none).
   - `### Changed file contents` — the changed files relevant to this reviewer (from your prep).
   - `### Related context` — scoped extras per context-policy (callers, consumers, schema, repo search). Omit if none.
   - `### Spec text`, for the `spec` reviewer only: the resolved spec text from triage's `spec_source`. Omit this section for every other reviewer; none of them should be measuring intent. If `spec_source.kind` is `none`, do not dispatch this reviewer at all.
   - `### External premises`, for the owning reviewer only: the entries from triage's
     `external_premises` whose `owner` is this reviewer, verbatim. Omit the section for
     every other reviewer. Verification channels and the requirement to record which
     channel settled a premise live in `core/shared/context-policy.md`.
3. **Collect** its structured finding blocks, plus its `## Premise verification` block when one comes back. That block is not a finding: never dedup it against the finding blocks and never rank it alongside them.

If a reviewer subagent is unavailable on your platform, perform that review **inline**: apply the core skill (which you Read from the plugin) plus the stack signals to the scoped context, and emit findings in the shared schema.

### 4. Synthesis (you, inline)
Follow the `review-pro-synthesize` skill over ALL collected findings, passing it the `diff_class`, `changed_files`, `spec_source`, `external_premises`, and `premises_dropped` you determined in triage: dedup within each axis (code findings on `(file, line±5, category-root, overlap_hints)`, spec findings on `(quoted requirement, file, line)` per that skill's Spec axis section), weight overlaps, resolve conflicts by domain ownership, calibrate severity (anti-overreporting), and emit the verdict.

## Output
Return ONLY the final synthesis report:

```
## Verdict: <BLOCK | REQUEST CHANGES> (<code | spec | code + spec>) | APPROVE

Spec: measured against <spec_source.ref>
(or: skipped, no spec found / not measured, <ref> resolved but carried no text)

### Critical
- [Critical] <file>:<line> — <title>
  impact: ...
  remedy: ...
  flagged by: <reviewer>, <reviewer>

### High
...
### Medium / Low / Nitpick
...

## Spec (measured against <spec_source.ref>; or skipped, no spec found; or not measured, resolved but empty)

### Missing / Wrong / Scope creep
- [<severity>] <file>:<line>, <title>
  spec: "<the quoted requirement>"
  remedy: ...
```

Do not dump raw per-reviewer outputs. Lead with the verdict.

## Rules
- **Never present a finding with unfinished research** — if you can verify it in-repo (callers, schema, consumers), do.
- **Stack signals come only from `.review-pro/`.** If it's empty, reviewers use core rubrics. Never invent stack signals.
- If triage dispatches no reviewers (e.g. docs-only change), return `APPROVE` with a one-line note.
- Calibrate honestly: downgrade anything you cannot fully trace; never invent severity.
- **The spec axis is reported separately and never merged into the code findings.** If no spec was resolved, say so in one line rather than omitting the section.