A written plan, checked by fresh reviewers, before any code
Before Claude writes any code, TLM Forge has it write a step-by-step plan that names every file it will change and every test it will add. Then AI reviewers who did not write the plan check it for flaws, so a bad design is caught while it is still cheap to fix.
How to use it
/tlmforge:buildYou do not run this step yourself. It happens inside /tlmforge:build on Medium and Deep tasks, right after the spec audit. Deep tasks get a full plan and three plan reviewers. Medium tasks get a shorter fix plan, held to the same standard, and two plan reviewers. Light tasks skip both.
Words you will see on this page
- Light / Medium / Deep
- How big and risky TLM Forge judges your task: Light is a tiny edit, Medium fixes or improves what exists, Deep adds something new.
- Spec audit
- The step just before this one, where Claude writes down the hidden risks and open questions in your request.
- Phase
- One small chunk of the build with its own goal, tests and commit.
- Plan reviewer
- A separate AI helper that reads the plan looking for one kind of problem, such as weak design, missing test cases or security holes.
- CRITICAL / HIGH
- Severity labels on a finding. CRITICAL means it blocks shipping; HIGH means it must be fixed before launch.
- notifications.md
- A notes file in your repo where reviewer findings are listed as they arrive.
Light vs Medium vs Deep: what planning you get
| What | Light | Medium | Deep |
|---|---|---|---|
| Kind of task | Typo, rename, config value | Fixes or improves something that exists | Adds something new, or changes a security decision |
| Written plan | None | Shorter fix plan | Full plan with threat model and diagrams |
| Plan reviewers | None | Architect reviewer, tester | Architect reviewer, tester, threat modeler |
| UX reviewer | No | When UI files are in scope | When the plan includes UI work |
| Does the build wait? | No review to wait for | No | Only the first tests wait for the tester's edge-case list |
What happens to a plan-review finding
| Finding | What happens |
|---|---|
| CRITICAL or HIGH, fixable in the current work | Fixed before the build moves on |
| CRITICAL or HIGH that means changing an already committed phase | Handed to you to decide (a CRITICAL also pauses the build) |
| CRITICAL flaw in the plan itself | Always handed to you: revise the plan or accept it |
| MEDIUM | Goes on the leftover list; fixed only if it is free inside a CRITICAL or HIGH fix in the same file |
| LOW | Goes on the leftover list; fixed only if trivial and in a file already being changed |
What it does
First, the plan is written (Stage 2) into specs/<feature>/README.md, a file in your repo. On Deep tasks it is a full plan: what is in and out of scope, a threat model (how someone could abuse the change), diagrams of every changed flow, numbered phases, risks, rejected alternatives, cost and a test plan. On Medium tasks it is a shorter fix plan. Either way, every phase lists its goal, steps, files, tests and how to undo it.
A separate design agent (an AI helper launched just for this) writes the draft. By default it gets the highest reasoning effort of any step, because a mistake here spreads into everything after. The bar is strict: every file, function signature, test name and expected result is named up front, so nobody invents the design mid-build. A draft that leaves a decision open goes back. Steps that cannot be undone are scheduled last, behind your approval.
Next comes the plan review (Stage 3). Reviewers who did not write the plan read it once, in the background, while the build starts. Deep tasks get an architect reviewer, a tester and a threat modeler. Medium tasks get the architect reviewer and the tester. A UX reviewer joins when there is UI work. Findings land in a notes file and are sorted between build phases. A CRITICAL flaw in the plan itself always waits for your decision.
How it works, step by step
Claude drafts the plan
The design agent reads the spec audit, your architecture doc and the diagrams you approved, then writes the plan.
Gaps are sent back
Claude reviews the draft and returns any part that leaves a design choice to be made later, during the build.
You sign off only if needed
The run stops for your approval only if the plan adds decisions you have not approved, or a production step that cannot be undone, such as a data migration. Otherwise it keeps going.
Reviewers start in the background
All plan reviewers launch at once, and the build (Stage 4) begins straight away instead of waiting for them.
Findings are sorted as they arrive
Serious problems that can be fixed in the current work get fixed. A CRITICAL flaw in the plan itself waits for you.
A summary is written
When every reviewer is done, a summary file records each verdict, what was broken and what was put off. On Deep, the tester's edge-case list also seeds the tests.
What it looks like
Two findings in the notes file, notifications.md. The first, a HIGH from the tester, is still open. The second is a CRITICAL flaw in the plan (it deletes a database column too early), so it waits for your answer. Real format, made-up content.
## OPEN
| # | Timestamp | Severity | Agent | Phase | Finding | Status |
|---|---|---|---|---|---|---|
| 2 | 2026-10-12T09:41:07Z | HIGH | tester | 1 | no test for an expired saved card | OPEN |
## BLOCKED_ON_USER
| # | Timestamp | Severity | Agent | Phase | Finding | Question for user |
|---|---|---|---|---|---|---|
| 1 | 2026-10-12T09:38:52Z | CRITICAL | architect-reviewer | 1 | README.md:14 drops orders.card_number in Phase 2 | Move the drop to a final phase behind your sign-off? |Why it is better
No design decisions made on the fly
Without a plan, design choices get made while the code is being typed. With TLM Forge, files, signatures and tests are named first, and any change from the plan is written down, never slipped in silently.
Checked by reviewers who did not write it
Without TLM Forge, asking Claude to check its own plan means reviewing it in the same conversation that wrote it. With it, separate reviewers check the plan, each looking for one kind of problem.
No waiting room
Without background review, you would wait for reviewers before building. With TLM Forge, the build starts at once and findings arrive as they are ready. You can read notifications.md at any time.
Risky steps surface early
Without a check, a step that cannot be undone can hide in the middle of a plan. With TLM Forge, reviewers are asked about exactly that, and such steps go last, behind your approval, while moving them is still a text edit.
Good to know
- Plan review happens once, with no second round, and the build does not wait for it. The one exception: on Deep tasks, the first tests wait for the tester's list of edge cases (unusual situations the code must handle).
- Say "pause for review" at any time to wait for the background reviewers and see how many findings are open. Say "resume" to carry on.
- The code reviewer, red team reviewer and phase auditor do not run here, because there is no code yet. They check the finished change in the final review (Stage 5).
- On Pro, the plan also lists which existing libraries were considered. A package name that cannot be found in its package registry is treated as not existing.
- You can change the model and effort for each reviewer in ~/.claude/tlmforge/models.json. A broken setting is ignored and the defaults apply, so it never blocks a run.