Finds the hidden risks in your request first
Before a plan is made, TLM Forge writes a risk check of your request: unstated assumptions, ways it could fail, costs and steps that cannot be undone. On Deep work, each risk is ranked and comes with a recommendation. Questions only you can answer pause the run until you reply.
![A feature request with "Retry the charge if a payment fails" highlighted, and a dotted line to a CRITICAL assumption from TLM Forge's Stage 1 spec audit: it doesn't say how many times or whether a customer can be charged twice, one of six findings surfaced before any code, raised as a [GATE-BLOCKING] question you answer before any code is written.](/images/features/R1_SpecAudit.webp)
How to use it
/tlmforge:buildThis runs on its own on Medium and Deep work, after you approve the design and before the plan is written. Deep work gets the full audit; Medium work gets a short one. Light work skips it.
Words you will see on this page
- Spec audit
- A written risk check of your request, saved as a file in your repo (specs/<feature>/spec_audit.md).
- CRITICAL, HIGH, MEDIUM, LOW
- How serious a finding is. In the audit, CRITICAL means a decision is needed before any code is written, and LOW is minor.
- Gate-blocking question
- A product or scope decision only you can make, so the run waits for your answer.
- Informational question
- A detail Claude will settle itself in the plan, with no decision needed from you.
- Rollback
- How to undo the change safely if something goes wrong.
- Stage 1
- This step. It runs after you approve the design and before the plan is written.
Light vs Medium vs Deep: what the audit covers
| Light | Medium | Deep | |
|---|---|---|---|
| Is there an audit? | No. | Yes, a short one. | Yes, the full one. |
| What it contains | Nothing. | What broke, the fix, the files involved, how to undo it, and the test plan. | Your request restated, how others usually solve it, and every risk ranked by severity. |
| Must cover the five risk areas below | No. | No. | Yes, and say why any area has no risks. |
| Asks you open questions | No audit questions. The check that it understood you still runs first. | Yes, and waits if any is gate-blocking. | Yes, and waits if any is gate-blocking. |
The five risk areas every Deep audit must cover
| Area | The question it asks | Example of a risk |
|---|---|---|
| Security | Could someone misuse this? | A user sees another user's data. |
| Running twice or at once | What if this happens twice, or at the same time? | A retry charges the customer twice. |
| Partial failure | What if one step fails halfway through? | The charge succeeds but the order is never saved. |
| Cost | What will this cost to run? | Every page view calls a paid service. |
| Rollback | Can we undo it safely? | A database change that cannot be reversed. |
What it does
A request that sounds precise is still full of decisions nobody made. "Retry the charge if a payment fails" does not say how many times, or whether a customer can be charged twice. This step finds those gaps before a plan is built around them. The result is a file in your repo. TLM Forge calls it the single most valuable file in the whole run, because the planner and the plan reviewers both work from it.
On Deep work, the audit restates your request, notes how similar systems usually handle it, then lists every risk from most to least serious. Each one shows what your request said, the way it could fail, a recommendation, and the yes or no decision it needs from you. It must cover five risk areas and say why any area has none. Inventing minor risks to fill space is called out as worse than listing fewer real ones.
On Medium work the audit is short: what broke, the fix, the files involved, how to undo it, and how it will be tested. Both versions end with open questions, each marked gate-blocking or informational. If any question is gate-blocking, the run stops and waits for you. If none are, it moves straight on to the plan.
How it works, step by step
Read past lessons
If your repo has a learnings.md file from earlier features, Claude reads the recent, relevant entries. If the file is missing or broken, the run carries on.
Restate and compare
The Deep audit opens with your request in plain English and how others usually solve the same problem.
Rank the risks
On Deep work, each risk is ranked CRITICAL, HIGH, MEDIUM or LOW, with the way it fails, a fix and the decision needed.
Cover all five areas
On Deep work the audit must address security, running twice or at once, partial failure, cost and rollback.
Label the open questions
Each question is gate-blocking (only you can decide) or informational (Claude handles it in the plan). When unsure, Claude is told to mark it gate-blocking.
Stop or continue
Any gate-blocking question pauses the run until you reply. Otherwise the plan starts right away.
What it looks like
Part of a real-format spec audit file: one CRITICAL risk with its recommendation and the decision you need to make, then the open questions and the line that pauses the run. The content is made up.
# Saved cards: Spec Audit
## Findings (severity-ranked)
### CRITICAL: Decisions needed before any code
#### F1. A retry can charge the customer twice
- Spec said: "Retry the charge if a payment fails."
- Problem: a timeout after the charge succeeds triggers a second charge.
- Recommendation: send an idempotency key with every charge attempt.
- Decision required: is a maximum of 3 retries acceptable?
## Open questions for the user
1. [GATE-BLOCKING] How many retries, and over what period?
2. [INFORMATIONAL] Webhook signatures will be verified; no decision needed.
SPEC_AUDIT_COMPLETE: [GATE-BLOCKING] questions require your input: 1Why it is better
Risks are caught before they are designed in
Without TLM Forge, Claude plans straight from your request as written. With it, the request is read critically first, so an unsafe assumption becomes a question for you instead of a bug in the plan.
No blind spots on big changes
Without a checklist, it is easy to skip thinking about security, failures, cost or rollback. With TLM Forge, a Deep audit must say something about each one, even if only why it does not apply.
You only answer what only you know
Without a rule for which questions matter, you can be asked about details that change nothing. With TLM Forge, only product and scope decisions reach you; everything else is handled in the plan.
A record that carries forward
Without TLM Forge, risks discussed in chat are soon lost. With it, the audit is a file the planner and plan reviewers read.
Good to know
- Light work skips this step. Medium work gets the short audit and does not have to cover all five risk areas.
- The audit is written by Claude itself, following TLM Forge's instructions, not by a separate review agent. The planner and plan reviewers then read it.
- The pause depends only on whether any question is marked gate-blocking, not on keywords. TLM Forge tells Claude to use that label whenever it is unsure.
- Past lessons are optional context. Old or unrelated entries are meant to be ignored, not copied into the audit.