A code reviewer that reads the code around the change
The code-reviewer checks the finished change the way a careful senior engineer would. It wants tests for every change, code that does what its name says, and new code that fits your repo's existing patterns. It runs once, at the final review, and matches every changed file to its tests.
How to use it
TLM Forge launches it for you after you type /tlmforge:build and describe the task. It runs once, in the background, at the final review (Stage 5) on Medium and Deep work, over everything that changed since the build started. It is deliberately not used at plan review, because at that point there is no finished code to review. Light work runs no review agents.
Words you will see on this page
- Light, Medium, Deep
- TLM Forge's three levels of care: Light is a tiny edit, Medium fixes or improves what exists, Deep adds something new or changes a security decision.
- Final review (Stage 5)
- Reviewers check the whole finished change at the end of the build.
- Fix step
- One round where Claude fixes the CRITICAL and HIGH findings, writing a failing test before each fix.
- Test gap table
- A required list matching each changed file to its tests, showing what is not covered.
- CRITICAL / HIGH / MEDIUM / LOW
- How serious a finding is: CRITICAL blocks shipping, HIGH must be fixed before launch, MEDIUM should be fixed, LOW is nice to fix.
- verdict_sha
- The ID of the exact commit the reviewer looked at, so later changes can be spotted.
What it looks for
| What it looks for | An example of what it catches |
|---|---|
| Surprises: code that does more than its name says | get_customer quietly creates a customer when it cannot find one. |
| Missing tests | A new branch with no test, or a bug fix with no test proving the bug stays fixed. |
| Tests that check nothing | A test that runs the code but never checks the result, or breaks whenever internals change. |
| Callers left behind | A function's inputs changed, but one place that calls it still passes the old ones. |
| Backend basics | A database query run once per item in a loop, a migration with no way back, or an auth check in the wrong layer. |
| Duplicate code | A new helper that does what an existing helper in your repo already does. |
| Small hygiene issues | Dead code, or a hard-coded number with no name explaining what it means. |
When it runs
| Level | Does it run? | When, in plain words |
|---|---|---|
| Light (tiny edit: typo, rename, config value) | No | Claude makes the change directly, with a test first. No review agents run. |
| Medium (fix or improve something that exists) | Yes, once | At the end, on the whole finished change, next to the phase-auditor (plus the ux-reviewer if the change has a user interface). |
| Deep (something new, or a change to how security decisions are made) | Yes, once | At the end, on the whole finished change, as one of five reviewers working at the same time (six if the change has a user interface). |
What it does
The code-reviewer follows four rules. No surprises: a function does exactly what its name says, so a getUser that quietly creates a user is exactly the kind of surprise it flags. Tests or it did not happen. Read the room: never judge changed lines alone, but read each changed file in full, the files around it, and any docs describing your conventions. Patterns over cleverness: new code should look like the code already there.
Tests come before style. It looks for a test for every new function and a regression test (a test that proves an old bug stays fixed) for every fix. It also reads the tests to see whether they check results or merely run the code. A real change with no tests is always critical. Then it checks backend basics and traces data end to end to find callers that were not updated.
It runs once per build, at the final review, next to the phase-auditor on Medium and in a five-reviewer group on Deep. It starts from a written brief, reads in full the risky files (where the build's parts meet, sensitive code, steps that cannot be undone) and skims the changes elsewhere. It reports only what breaks a stated goal or would fail in production, then stops.
How it works, step by step
Read the context
It starts from the final-review brief and Claude's notes on each part of the build. It reads the risky files in full and the changed lines everywhere else.
Check the tests
A test for every new function, a regression test for every fix, clear structure, edge cases such as empty input and errors, and no fragile tests tied to internal details.
Run the checklists
API design, error handling, input checks, database queries and migration rollback, where auth checks live, naming, dead code, unexplained hard-coded values, logging and null safety.
Connect the dots
It traces data from start to end for mismatched types and lost fields, checks every caller of a changed function, and looks for code that copies something already in your repo.
List the test gaps
For every changed source file: the changed lines, its test file, and whether the change is covered. A changed file with no test file is CRITICAL.
Write the verdict
Approve, needs revision, or reject, plus a record of the exact commit it reviewed. CRITICAL and HIGH findings go to the fix step, where each is fixed test first.
What it looks like
What a final review looks like. The reviewer found that get_customer, a lookup, quietly creates a customer when none exists, and that no test covers that branch. The last line records the exact commit it reviewed. The content is invented; the format is the real one.
## VERDICT: NEEDS REVISION
## Test Assessment
- Coverage gaps: get_customer create branch untested
- TDD compliance: Tests appear to be an afterthought
## Critical Issues (must fix)
- billing/customers.py:11 get_customer silently creates a customer
| File | Changed lines | Test file | Coverage |
| billing/customers.py | 8-12 | test_customers.py | create branch not tested |
final_audit_code-reviewer.json verdict_sha: <full 40-char HEAD SHA>Why it is better
Fresh eyes on the code
Without TLM Forge, the chat that wrote the code reviews it while remembering what it meant to write. With it, the reviewer starts from the files on disk and a written brief, so it judges what the code actually does.
Missing tests are a finding, not a preference
Without it, untested code can slip through as a matter of taste. With it, every changed file is matched to its tests, and a real change with none is CRITICAL by rule.
Context beyond the changed lines
Without it, a review of just the changed lines misses a caller that was not updated or a helper that already existed. With it, the reviewer traces callers and reads the risky files in full.
Focused, then done
Without limits, a reviewer can bury real problems in trivia. With it, the reviewer runs once, reports what would fail, and marks a corner case nobody can trigger as LOW.
Good to know
- It does not run at plan review (Stage 3), because there is no finished code yet. Other reviewers cover the plan.
- It reviews the whole feature once, at the end. There are no separate reviews after each part of the build.
- It does not re-run your test suite. TLM Forge runs it once at the reviewed commit and every reviewer cites that saved run.
- MEDIUM and LOW findings usually go to a list in STATUS.md (the build's status file) for you to decide on, rather than another round of fixes. If the fixes change more than 150 lines or touch sensitive code, one extra reviewer checks just the fixes.
- If code (not just docs) changes after this review, a check built into the plugin stops git commit, git push and gh pr merge until the new commits are re-reviewed, you accept the leftover findings in your own words, you say an override phrase such as "just do it", or you turn the checks off with TLMFORGE_HOOKS=0.