/review

description: Full code review with dynamic agent selection (up to 12 specialized agents). Analyzes changes first, selects relevant experts. Also reviews implementation plans.
argument-hint: "[PR-url-or-number|--local|--staged|--last-commit|--branch|--plan|--file <path>] [--json] [--workflow] [--spec <path>|none]"

Full Code Review

Comprehensive code review with dynamic agent selection based on change types. Up to 12 specialized agents, tiered severity scoring. Works with:

• GitHub and Bitbucket PRs (posts a summary comment to the PR)
• Local changes (saves to file)
• Implementation plans (reviews `.lets/plans/` files)

> **IMPORTANT:** If the spec below invokes any deferred tool (e.g. `AskUserQuestion`), you MUST load and call it as specified. Never skip the call, never substitute a default answer of your own — the tool invocation is part of the contract. This is critical.

Usage

/lets:review                     # Interactive - asks what to review
/lets:review <PR-url-or-number>  # GitHub or Bitbucket PR
/lets:review --local             # Uncommitted changes
/lets:review --staged            # Staged changes only
/lets:review --last-commit       # Last commit
/lets:review --branch            # Full branch vs $LETS_MERGE_BRANCH (three-dot, like a PR)
/lets:review --plan              # Review latest plan in .lets/plans/
/lets:review --plan <path>       # Review specific plan file
/lets:review --file <path>       # Review an existing file (full content, not diff)
/lets:review --workflow          # Run via Dynamic Workflow (off-context fan-out); combinable with any code mode + --json
/lets:review --spec <path>       # Use this file as the spec (skips the "where is the spec?" question)
/lets:review --spec none         # There is deliberately no spec - review at full strength, no caveat

Step 1: Determine Review Mode

**If argument provided:**

• PR URL/number -> **PR mode** (host resolved below)
• `--local` / `--staged` / `--last-commit` / `--branch` -> Local mode
• `--plan` / `--plan <path>` -> **Plan review mode** (skip to Plan Review section below)
• `--file <path>` -> **File review mode** - reviews entire file content, not a diff

**Host resolution (PR mode).** A PR argument picks the forge: a `github.com` URL -> `gh`; a `bitbucket.org` URL -> `bbb` (its PR number is in the `/pull-requests/<n>` path segment, not github's `/pull/<n>`); a bare number -> `{LETS_PR_FLOW}` (`github` -> `gh`, `bitbucket` -> `bbb`). Any other `LETS_PR_FLOW` with a PR argument: stop - PR review needs a github or bitbucket remote. Below, every step that shows a `gh` call has a `bbb` sibling for the bitbucket host; run whichever the resolution picked.

**If no argument**, use **AskUserQuestion**:

AskUserQuestion(
  questions=[{
    question: "What are we reviewing?",
    header: "Target",
    options: [
      { label: "Local changes", description: "Uncommitted changes in working tree" },
      { label: "Branch", description: "Full branch vs {LETS_MERGE_BRANCH} (three-dot, like a PR)" },
      { label: "Plan", description: "Review implementation plan from .lets/plans/" },
      { label: "Last commit", description: "Review the most recent commit" }
    ],
    multiSelect: false
  }]
)

**Handle response:**

• **Local changes** -> local mode with `git diff`
• **Branch** -> local mode, diffing against the base the Step 2 guards resolve and print (run them first)
• **Last commit** -> local mode with `git diff HEAD~1`
• **Plan** -> skip to Plan Review section
• **Other** (free text) -> treat as PR number or URL, use PR mode (host resolved above)

Note: `--staged` is flag-only (not in the interactive menu). Use `/lets:review --staged` directly.

**If plan mode selected:** skip to **Plan Review** section below.

Spec source flag

`--spec <path>` or `--spec none` pre-answers Step 2.5's spec question and skips it. `<path>` is read from disk and sanitized like any third-party value; `none` means the user has declared there is no spec, so no SPEC block and no "reviewed without a spec" caveat is rendered. A bare task id is also accepted (`--spec lets-abc`) and resolves through the tracker. Anything else: say what was passed and ask rather than guessing.

The flag exists so a project that always keeps its spec in the same place - or has none at all - is not asked the same question on every review. It is also how `/lets:check`, which has no question, gets the same control.

JSON output flag

If `--json` is present alongside any mode:

• Save review output as structured JSON instead of markdown
• File: `.lets/reviews/{date}-{mode}.json` (e.g., `2026-02-26-PR-42.json`, `2026-02-26-local-review.json`, `2026-02-26-branch-review.json`)
• Skip markdown report generation (Step 8)
• Skip GitHub PR comment posting (Step 9) - JSON mode implies the caller handles output

Workflow execution flag

**Preflight NOW, before anything touches the working tree.** If `--workflow` was passed explicitly and the `Workflow` tool is not available this session, stop here per W1 - Step 2.5 must not have checked out and stashed by the time that abort fires, or the user is stranded with Step 6.7 unreached.

If `--workflow` is present alongside any **code** mode (`--local` / `--staged` / `--last-commit` / `--branch` / `<PR>` / `--file`):

• Run the agent fan-out + aggregation inside a Dynamic Workflow instead of launching agents via the Task tool (Step 5/6).
• Combinable with `--json` (the workflow returns the aggregate; Claude still writes the JSON file in Step 8.5).
• NOT supported with `--plan` (the plan-review path is a separate follow-up) - if both are present, tell the user `--workflow` does not apply to plan review yet and run the standard plan-review path.

Choosing the execution path (interactive)

When `--workflow` was NOT explicitly passed, decide the execution path as follows - **for code modes only** (never for `--plan`), and **never when `--json` is set** (a programmatic caller cannot answer a qu