# Review Pro > 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. - Skill: `tufantunc/review-pro` (Agent Skill) - Install (CLI): `npx skillmds@latest add tufantunc/review-pro` - Raw SKILL.md: https://api.skillmd.com/api/skills/tufantunc/review-pro/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: tufantunc (https://skillmd.com/u/tufantunc) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tufantunc/review-pro --- # 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 ...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//.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` 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: () | APPROVE Spec: measured against (or: skipped, no spec found / not measured, resolved but carried no text) ### Critical - [Critical] : — 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.