A senior design reviewer for Claude's plans
On bigger tasks, this agent writes the plan for the change, and a fresh copy of it then reviews that plan. It hunts for made-up functions, invented libraries, needless complexity and work nobody asked for. On Deep work, such as a new feature, it also checks the finished change at the end.
How to use it
You never start it yourself. Type /tlmforge:build, describe the task in plain English, and TLM Forge launches it when it is needed. On Medium and Deep work it writes the plan (Stage 2), then a separate copy reviews that plan in the background (Stage 3). On Deep work it also joins the final review of the finished change (Stage 5). Light work, such as a typo fix, 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.
- Plan (Stage 2)
- A written design listing which files change, in what order, and which tests prove the change works.
- Plan review (Stage 3)
- Independent reviewers check the plan in the background while the build starts.
- Final review (Stage 5)
- Reviewers check the whole finished change at the end of the build.
- Hallucinated API
- A function or library the AI made up that does not actually exist.
- CRITICAL / HIGH
- The top severity labels on a finding, on a scale that runs down to nit; these are the ones Claude is told to resolve.
What it looks for
| What it looks for | An example of what it catches |
|---|---|
| Made-up functions (hallucinated APIs) | The plan calls http.retry_with_backoff, but the version of the HTTP library your project uses has no such function. |
| Invented packages or wrong imports | The plan imports a package that does not exist, or uses an import path that is wrong. |
| Wrong signatures or outdated patterns | A function is called with the wrong arguments, or in a way the library has deprecated. |
| Over-engineering | A plugin registry for retry strategies when only one strategy was ever requested. |
| Scope creep or missed requirements | The plan adds work you never asked for, or quietly skips something you did ask for. |
| Unfinished work | Placeholder or TODO steps left where real design should be. |
| Parts that no longer fit (Deep, final review) | One part of the build changed what it hands to the next part, and the next part was never updated. |
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, twice | It writes the plan, then a fresh copy reviews that plan in the background as the build starts. |
| Deep (something new, or a change to how security decisions are made) | Yes, three times | It writes the plan, a fresh copy reviews it, and it returns at the final review to check how all the parts fit together. |
What it does
Think of the architect-reviewer as a very senior engineer whose only question is: would I ship this? Its instructions say to be blunt, be specific, skip style nitpicks, and verify instead of trust. That last rule matters because AI assistants sometimes invent functions and libraries that do not exist. It reads your original request first, then the plan, then your existing code, and checks every technical claim the plan makes.
It has two jobs. First, on Medium and Deep work, it writes the plan: every file to change, the order of edits and the tests to write, detailed enough that nobody has to make a design decision while coding. Anything it cannot settle is marked DESIGN-OPEN, with options and a recommendation. Then a separate copy, which never saw your chat, reviews that plan from the files on disk, next to the tester (plus the threat-modeler on Deep, and the ux-reviewer when the change touches a user interface).
On Deep work it returns once more, at the final review of the finished change. This is not a redesign. It reads in full only the files where the build's parts meet, sensitive code, and steps that cannot be undone. Then it asks what no single part could answer: did design shortcuts pile up, do the parts still fit together, and did an irreversible step slip in that no part's plan mentioned?
How it works, step by step
Write the plan (Stage 2)
It drafts the plan file: which files change, in what order, which tests to write, and which tests should fail first and then pass. Open decisions are marked DESIGN-OPEN with a recommendation, and Claude then reviews the draft and owns it.
Review it cold (Stage 3)
A separate copy, with no memory of your chat, reads only the plan and the spec audit (a written check of what your request actually asks for). It runs in the background, so the build starts without waiting for it.
Hunt common AI mistakes
Made-up methods, invented packages, wrong function signatures, outdated patterns, wrong import paths, over-engineering, circular dependencies, scope creep, missed requirements, and placeholder or TODO code.
Give a verdict
Approve, needs revision, or reject, with each problem ranked from critical down to nit. A machine-readable copy of the review is what TLM Forge acts on.
Send each problem to the right place
TLM Forge tells Claude to resolve CRITICAL and HIGH issues as they arrive. A critical flaw in the plan itself cannot be fixed in code, so it comes to you: revise the plan or explicitly accept it.
Check the whole build (Deep only)
One pass over the finished change at the final review (Stage 5): parts that no longer fit together, piled-up design debt, and unflagged steps that cannot be undone.
What it looks like
What a plan review looks like. The agent read a two-part plan for payment retries and found one critical problem (line 7 calls a function your HTTP library does not have) and one warning (line 12 adds a plugin system nobody asked for). The content is invented; the format is the real one.
## VERDICT: NEEDS REVISION
## Summary
Reviewed the payment-retries master plan (2 phases).
## Critical Issues (must fix before proceeding)
- README.md:7 http.retry_with_backoff is not in the pinned client.
## Warnings (should fix)
- README.md:12 StrategyRegistry adds plugins nobody asked for.Why it is better
The author is not the grader
Without TLM Forge, the same chat that wrote the plan checks it, with the same blind spots. With it, a separate copy that never saw your chat reviews the plan from the files on disk.
Made-up APIs get caught
Without it, a confident plan can rest on a function that does not exist, and you find out mid-build. With it, the reviewer is told to confirm that every API, library and pattern the plan names really exists and works as described.
Problems are cheap to fix
Without it, a wrong design choice tends to surface once code is written around it. With it, the problem is found at plan review, early in the build, when fixing it is mostly a plan edit.
Sees across the whole build
Without it, each part of a build can look fine on its own while the parts no longer fit together. With it, the final pass on Deep work checks exactly that.
Good to know
- It focuses on substance. It does not nitpick formatting or naming unless they cause confusion, and it says when it is unsure instead of guessing.
- Plan review happens once. There is no second round; Claude sorts the findings while the build runs.
- On Medium work it skips the final review. TLM Forge's reasoning: a fix needs checking that it does what was promised, not a design opinion. The code-reviewer and phase-auditor cover that review.
- At the final review it is not the one playing attacker. The red-team-reviewer does that in the same review, and the architect is told to stay on design.
- Say "go deeper" or "go lighter" to change the level (Light, Medium or Deep), which changes whether and where it runs.