A tester that asks "what happens when..." for every change
The tester has one job: find what can go wrong, and make sure a test proves it won't. It reviews the plan on Medium and Deep work. On Deep work it also writes down the edge cases the build must test, then checks at the final review that each one really has a test.
How to use it
TLM Forge launches it for you after you type /tlmforge:build and describe the task. On Medium and Deep work it reviews the plan in the background (Stage 3). On Deep work it also writes an edge-case file and joins the final review of the finished change (Stage 5). 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.
- Edge case
- An unusual situation, like a double tap or a dropped connection, where code often breaks.
- 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.
- tester_edge_cases.json
- The tester's written list of edge cases on Deep work, used as the build's test checklist.
- Test level
- Where a test runs: unit (one function), integration (parts working together) or end to end (the whole flow).
What it looks for
| What it looks for | An example of what it catches |
|---|---|
| Timing and ordering | The user taps Pay, then taps again before the first response: two charges. |
| Repeated actions and half-finished state | The same save fires twice, or a step fails and leaves the data half-updated. |
| Bad data | Input that is empty, partial, garbage or out of date. |
| Cleanup on every exit | Something opened on the happy path is never closed when the request is cancelled or times out. |
| Stuck users | An error leaves the user on a screen with no way forward. |
| Failing services | A service the code depends on returns 500, 429 (too many requests), or times out. |
| Missing tests (Deep, final review) | Edge case EC3 from the plan review still has no test at any level. |
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 | It reviews the plan in the background. Claude builds tests from its written report. |
| Deep (something new, or a change to how security decisions are made) | Yes, twice | It reviews the plan and writes the edge-case list the build must test, then returns at the final review to check each case has a test. |
What it does
The tester is told it is not a code reviewer or an architect. It is a professional breaker of software, looking for the thing that works 999 times and fails on the 1000th. It ignores style, naming, architecture and docs. It tags each changed function by the kinds of risk it touches, such as user input, async work, network, concurrency and data, and treats three or more as high risk.
For each risky function it asks a fixed set of questions. What if the user acts before a slow call returns, or two things happen at once? What if the same action fires twice, or the data is empty, garbage or stale? Is everything cleaned up on every exit, can the user get stuck, and what if a service returns an error or times out? Its main output is the list of real edge cases with no test.
On Deep work its findings travel. At plan review it writes tester_edge_cases.json: one entry per CRITICAL or HIGH edge case, with the expected behavior and a starter test. Claude builds its tests from that list and adds any new cases found while coding. At the final review the tester reads the list back and checks that every case has a test at the right level.
How it works, step by step
Read everything
At plan review: the plan and the spec audit (a written check of what your request actually asks for). At the final review: the brief, Claude's notes on each part, and the changes, reading the risky files in full.
Rank the risk
It tags each function with the kinds of risk it touches. Three or more kinds means high risk, reviewed first.
Probe every failure mode
Timing and ordering, repeated actions, half-finished state, empty or stale data, cleanup on success, error, cancel and timeout, stuck users, and failing services.
Write the edge cases down (Deep)
Each CRITICAL or HIGH case goes into tester_edge_cases.json with the expected behavior and a starter test. On Deep, Claude waits for this file before writing the first tests.
Check coverage at the end (Deep)
At the final review it walks every entry, including ones added during the build, and confirms a passing test exists at the right level: unit, integration or end to end.
Give a verdict
Ship it, fix before shipping, or do not ship, with a runnable starter test for each CRITICAL and HIGH case.
What it looks like
One edge case from start to finish. At plan review the tester wrote entry EC3, "Pay tapped twice", into the edge-case file. At the final review it reported EC3 as a critical bug, because a second tap creates a second charge, and gave a fix plus a test that proves it. The content is invented; the format is the real one.
tester_edge_cases.json
{"id": "EC3", "title": "Pay tapped twice", "surface": "checkout/pay.py",
"expected": "exactly one charge", "test_stub": "...", "source": "design"}
## VERDICT: FIX BEFORE SHIPPING
#### [EC-3] Pay tapped twice
- Trigger: user taps Pay, then taps again before the response
- What happens: two charges are created
- Fix: guard pay() with an idempotency key
- Test: two concurrent pay() calls, assert one chargeWhy it is better
Edge cases decided up front
Without TLM Forge, failure modes are often found after the code ships. With it, the tester names them at plan review, and Claude writes tests against a list it did not invent itself.
A checklist the end review can hold Claude to
Without it, nobody checks that the edge cases raised early were ever tested. With it, on Deep work the same list is read back at the final review: each case is tested at the right level, or flagged.
One job, done well
Without a narrow focus, a reviewer asked to judge everything spreads its attention thin. With it, this reviewer only asks whether the code survives real users.
Findings come with a test
Without it, a bug report still leaves you to work out how to reproduce it. With it, each CRITICAL and HIGH finding comes with the trigger, the impact and a runnable starter test for the fix.
Good to know
- On Medium work it runs once, at plan review only. It does not write the edge-case file; Claude reads its written report directly.
- Plan review runs in the background. On Deep work the build waits only for the edge-case file before writing its first tests; everything else goes ahead.
- At the final review it does not re-run your tests. It cites the saved test run, and if Claude's notes and that run disagree on the numbers, that is CRITICAL.
- On Deep work its own instructions call its final review the last check before live testing on a real environment, and tell it to treat any HIGH or CRITICAL finding there as blocking. A corner case that needs an input nobody sends is marked LOW.
- It does not judge whether tests were written first. That is the code-reviewer's job.