/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] [--fix] [--solo]"

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
/lets:review --branch --fix     # apply the verified fixes when nothing needs deciding (not with --json)
/lets:review --branch --solo    # in a team worktree: one-shot agents only, not the team's members

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: the path from the `artifact-path` skill (`kind=review-{local|branch|pr-{number}} ext=json`) - e.g. `.lets/reviews/2026-08-22-0210-lets-05c4s-review-branch.json`. Task-scoped + `-vN` on collision; `.lets/` is shared across worktrees, so never a hand-built `{date}-{mode}` path
• Skip markdown report generation (Step 8)
• Skip GitHub PR comment posting (Step 9) - JSON mode implies the caller handles output
• In a team worktree `--json` passes `solo` to every route of the run (as `/lets:check`'s `--json` stays inline): a programmatic caller (`/lets:github-pr`) cannot answer the Members question or wait out a member's turn

Fix flag

`--fix` applies the verified findings to the working tree at the end, through the `apply-fixes` skill - the gates, the scope and the report live there. The user typing it is the write authorization for this run.

• With `--json` -> refused, one line: `--fix edits files - --json has no side effects`; stop.
• PR mode -> only when Step 2.5 found `HEAD == {headRefOid}` without switching. After `SWITCHED` / `CHECKOUT PARTIAL`, or from the diff, drop `--fix` with one line: Step 6.7 restores your branch, so the PR's files are not here to edit.
• `--pla