Review your changes

tsforge review reviews the change you’re working on and prints a focused list of functional problems, the things a linter can’t catch.

tsforge review                 # review the current diff
tsforge review --staged        # only staged changes (pre-commit)
tsforge review --base develop   # diff against a specific ref
tsforge review --with-gate     # run the gate first; skip what it already covers

Inside a session, the same review is available as /review.

Automatic after green

You don’t have to remember to run it. When a task lands green — in an interactive session and in headless runs alike — tsforge automatically reviews what just changed and surfaces its findings. The gate proves the change compiles, lints, and passes tests; this catches the substance the gate can’t — an inverted condition, an unhandled edge case, a secret in a log line.

It reports — it never edits your code on its own. Each finding comes with a concrete failure scenario and, when the reviewer is confident, a suggested fix. In an interactive session, if you want the agent to act on them, run /reviewfix and it hands the findings back to the agent to address (which then gets reviewed in turn). The auto phase reviews only the current unit of work (the files that turn touched), not the whole branch, so it stays fast and relevant.

Turn the phase off with TSFORGE_NO_REVIEW=1 — eval sweeps and cost-sensitive headless runs set this. The explicit tsforge review command and /review always work regardless.

Gate-aware review

With --with-gate, tsforge runs the gate once before reviewing and tells the reviewer which rules are already failing, so it won’t spend its attention re-reporting a type or lint error the gate loop will fix anyway. The review focuses on the behaviour of the code the gate already accepts (exactly the part the gate is blind to). The report notes how many gate rules were skipped. Without the flag, review runs as before (no gate run).

How it reviews

The reviewer is an agent, not a one-shot prompt. It’s given the whole change and the same tools you’d use: it reads the full diff (git_context), then navigates the codebase — opens the surrounding files, follows a changed function to its callers and definitions (find_references, go_to_definition, type_at, impact), checks types (diagnostics) — so it judges the change with real cross-file context instead of one file in isolation. A panel of reviewers each does this independently and their findings are pooled + deduped.

What it reviews

It looks at what you changed (working tree plus uncommitted edits, against the auto-detected base branch, no commit or push required) through a built-in senior-reviewer rubric:

• Correctness: inverted conditions, wrong operators, off-by-one.
• Regressions: a signature, return, or contract change that breaks existing callers.
• Edge cases: null/empty/boundary inputs, unhandled errors, a missing await.
• Business logic: money rounding, auth gating, invalid state transitions.
• Data and concurrency: races, partial writes.
• API and contracts: breaking a response shape or a serialized format.
• Security: injection (SQL/command/path/XSS), a leaked secret, an ungated privileged path, unsafe deserialization or SSRF.
• Consistency: a change that reimplements or diverges from how this codebase already does the same thing.

Types, structure, and style are out of scope. The gate already enforces those. Review is for judgment, not lint.

Why the findings are trustworthy

The usual failure of AI review is confident nonsense. Two things keep the findings grounded. First, the reviewer investigates before it speaks: it’s read-only and must cite a real file:line for every finding — anything without a concrete location it actually looked at is dropped, not shown. Second, a panel pools independent reviewers and dedupes, so a real issue that several reviewers land on stands out while one reviewer’s stray guess doesn’t. You get a short list of real issues instead of a wall of maybes.

When a tsconfig.json is present, the reviewer can follow the callers of each changed export through the type graph (find_references, go_to_definition, impact, type_at), so the regression check looks at concrete call sites instead of guessing.

Which model reviews

By default the main model reviews its own work. You can point review at a different model, or run a panel of several, in models.json:

{
  "active": "local",
  "models": {
    "local": { "baseUrl": "http://localhost:8000/v1", "model": "deepseek-v4-flash" },
    "haiku": { "baseUrl": "https://api.anthropic.com/v1", "model": "claude-haiku-4-5", "apiKeyEnv": "ANTHROPIC_API_KEY" }
  },
  "reviewModels": ["haiku"]
}

• One entry — a dedicated reviewer (e.g. a fast, sharp model; a small instruction-tuned model often reviews better and cheaper than a big one).
• Several entries — a panel: each reviews independently and their findings are pooled and deduped, which catches more real issues.
• Absent — the main model reviews.

For a quick one-off without editing the file, set TSFORGE_REVIEW_MODEL (naming a models entry) or the trio TSFORGE_REVIEW_BASE_URL / TSFORGE_REVIEW_MODEL / TSFORGE_REVIEW_API_KEY for an ad-hoc reviewer. While reviewing, the status bar shows ● reviewing… (or ● reviewing ×N for a panel).

Live progress. The review streams into the same agent-tree UI as delegated subagents: each reviewer appears as a node that goes pending → running → done, so you can watch it advance instead of waiting on a silent prompt. A panel’s reviewers run concurrently (they’re independent — usually different remote endpoints), so a panel isn’t one-reviewer-at-a-time.

Parallel review

A panel’s reviewers are independent, so they run concurrently. The number in flight at once is capped by agents.concurrency in tsforge.config.json (default 1):

{ "agents": { "concurrency": 4 } }

Keep the cap a couple below your endpoint’s max_num_seqs so an interactive session is never starved. With a single reviewer (the default) there’s nothing to fan out, so the cap has no effect.

In CI

tsforge review exits non-zero if any error-severity finding survives, so you can gate a PR on it. It uses git to find what changed, so run it inside a git repository.

→ Commands · Map the repo