Stage 5: the final review

Several reviewers check the finished change at once

When the build is done and all tests pass, several specialist AI reviewers read the whole change at the same time. Only serious problems (CRITICAL and HIGH) get fixed, tests first. Smaller ones go on a list for you. TLM Forge tells Claude not to commit or publish until every reviewer has reported.

How it startsRuns automatically
Runs onMedium and Deep tasks (Light tasks skip it)

A pull request adds ship(order) to a payment webhook handler, and a dotted line runs from that line to a CRITICAL red-team-reviewer finding from TLM Forge's Stage 5 review wave (five reviewers in parallel): replaying the webhook ships the order twice, so the merge is held while the fix wave writes a failing test and then the fix.

How to use it

/tlmforge:build

You do not run this step yourself. It happens inside /tlmforge:build on Medium and Deep tasks, after the last phase is committed and the full test suite passes. Medium tasks get two reviewers and Deep tasks get five, plus a UX reviewer on either when UI files changed. Light tasks have no final review.

Words you will see on this page

Verdict: A reviewer's overall call, such as approve or needs revision, plus its list of findings.
verdict_sha: The ID of the exact commit a reviewer looked at, so any later change to the code can be spotted.
CRITICAL / HIGH / MEDIUM / LOW: Severity labels: blocks shipping, must fix before launch, should fix, nice to fix.
Fix wave: The single round where CRITICAL and HIGH findings get fixed, test first.
Residual list: The leftover list of smaller findings in STATUS.md, for you to decide on.
Rollback: The steps to undo a phase, written into the plan.

Who reviews on Medium vs Deep, and what each looks for

Reviewer	Medium	Deep	Looks for
Code reviewer	Yes	Yes	Tests written first, code that fits your project's patterns, security in the code, dead code
Phase auditor	Yes	Yes	Whether each phase delivered what it promised, by actually running its undo steps and proof commands
Tester	No	Yes	Whether every serious edge case from plan review has a test at the right level
Red team reviewer	No	Yes	How a malicious user who knows the code could abuse it
Architect reviewer	No	Yes	Broken agreements between phases, design debt and irreversible steps that slipped through
UX reviewer	If UI files changed	If UI files changed	Layout, interaction and accessibility problems
Threat modeler	No	No	Not part of the final review; on Deep it checks the design earlier, at plan review

What happens to each finding

Severity	What happens
CRITICAL	Fixed in the fix round, failing test first. If it cannot be fixed, you decide.
HIGH	Fixed in the fix round, failing test first
MEDIUM	Listed in STATUS.md; fixed only if it is free inside a CRITICAL or HIGH fix in the same file
LOW	Listed in STATUS.md, not fixed

What it does

This is one review, not a loop. All reviewers start at the same moment, each reads the same finished change once, and each returns one verdict. So you wait as long as the slowest reviewer, not all of them added up. Medium tasks get a code reviewer and a phase auditor. Deep tasks add a tester, a red team reviewer and an architect reviewer. The table below shows what each one looks for.

Before they start, Claude writes a short brief: which commits to review, where the risky parts are, and the saved output of one full test run. Reviewers cite that saved output instead of each re-running the tests. Each reviewer writes a report and a verdict tied to the exact version it reviewed. They are told to report only what breaks a stated goal or would fail in production.

Then comes one fix round. CRITICAL and HIGH findings are fixed, each with a failing test written first. MEDIUM and LOW findings are not fixed; they go on a leftover list in STATUS.md, a status file you get at the end. If the fixes were large, one more reviewer checks just the fixes. A CRITICAL that cannot be fixed comes to you: fix it and ask for a fresh review, accept it in writing, or drop the work.

How it works, step by step

Wait for the earlier reviewers
Every plan reviewer must be finished, and the full test suite must pass on the latest version.
Write the brief
Claude writes a short brief pointing reviewers at the exact commits, the risky areas and the saved test output.
Launch every reviewer at once
All reviewers start together in the background. Meanwhile, TLM Forge tells Claude it may draft write-ups but must not commit, push, deploy or publish.
Read the verdicts
Each reviewer returns a report and a verdict tied to the exact version it reviewed. A status line shows the CRITICAL, HIGH and leftover counts.
Fix the serious ones
CRITICAL and HIGH findings are fixed test first, and the full suite runs once more at the end. MEDIUM and LOW are listed, not fixed.
Check big fixes, then stop
One extra reviewer checks the fixes only if they changed more than 150 lines or touched a sensitive area. Then the run stops.

What it looks like

One reviewer's verdict file. The red team reviewer found a CRITICAL security problem: if the same payment webhook (a payment notice from the provider) is sent twice, the order ships twice. verdict_sha is the exact commit it reviewed. Real format, made-up content.

{
  "reviewer": "red-team-reviewer",
  "schema_version": "1.0",
  "iteration": 1,
  "verdict": "needs_revision",
  "verdict_sha": "3f9c2a1d8e47b05c6a9f12e3d4b5c6a7e8f90123",
  "findings": [{
    "severity": "critical", "category": "security",
    "file": "payments/webhook.py", "line": 42,
    "finding": "A replayed webhook event ships the order twice.",
    "suggested_fix": "Record handled event ids and return early on a repeat."
  }]
}

Why it is better

Every angle on the same change

Without TLM Forge, one review tries to hold every concern at once. With it, on Deep tasks, separate reviewers check code quality, test coverage, promises, attacks and overall design on the same final change. Medium gets the code and promise checks.

Promises are tested by running them

Reading a plan's undo steps does not prove they work. With TLM Forge, the phase auditor actually runs them, and TLM Forge notes that the auditor's most useful findings came from running the undo steps.

A review that knows when to stop

Without a limit, fixing and re-reviewing can go on and on. With TLM Forge there is one review, one fix round and at most two review rounds in total.

Tests run once for everyone

Without a shared run, each reviewer would pay for the slow tests again. With TLM Forge, the suite and slow checks run once and every reviewer cites the saved output.

Good to know

Not committing until every verdict is in is something TLM Forge tells Claude to do. After that, a check built into the plugin, the commit lock, stops commits, pushes and merges if the code moves past the reviewed version. Changes only to docs under specs/ and docs/ are allowed.
MEDIUM and LOW findings are not fixed by default. You get them as a list in STATUS.md at the end, and a MEDIUM is fixed only when it is free inside a bigger fix in the same file.
Medium tasks have no red team or architect reviewer here. The threat modeler never runs here; on Deep tasks it checks the design earlier, at plan review.
TLM Forge never starts a third review round on its own. You can ask for one after reading the leftover list.
You do not start these reviewers yourself. Their reports land in specs/<feature>/agent_verification/.

Related features

Get TLM Forge