A repeatable workflow for shipping Claude Code features: audit the spec, review the plan, build test-first, then clear a red-team gate before shipping.
Ad hoc prompting works fine for a script, a bug fix, or a one-off utility. Describe what you want, get code back, run it, move on. That loop breaks down the moment the task becomes a real feature: multiple files, existing tests, an API surface other code depends on, and production consequences if something is wrong. The output still looks finished. It compiles, it runs, and it may even pass the tests you thought to write. What it usually has not done is catch the authorization check you forgot to specify, the edge case nobody typed into the prompt, or the shortcut that will force a rewrite once real traffic hits it.
A workflow fixes this by replacing one prompt and one output with a sequence of checkpoints, each one gating the next: a spec that gets audited before anyone writes code, a plan that an independent reviewer signs off on, implementation built test-first, a diff that agents with no memory of the plan review cold, an adversarial pass that treats you as the attacker, a ship step, and a persistence step so the next session does not start from zero. TLM Forge exists to enforce that sequence directly in the terminal, so the discipline does not depend on whichever engineer remembers to apply it that day.
The seven checkpoints, in order
- Spec: write down what you are building and why, then have it audited for ambiguity, missing edge cases, and unstated assumptions before a single line of code exists.
- Plan: turn the spec into an implementation plan, then send that plan to a reviewer who did not write it, looking for over-engineering, hallucinated APIs, and architectural drift.
- Test-first implementation: write the failing test, then the code that makes it pass, one phase at a time, so every unit of work has a verification artifact attached to it.
- Independent diff review: route the finished change through reviewers who only see the code, not the conversation that produced it, checking correctness, test quality, and consistency with the rest of the codebase.
- Red-team gate: a reviewer plays a malicious user with full knowledge of the code, hunting for auth bypasses, injection points, and race conditions, and the change cannot ship while critical findings are open.
- Ship: deploy with the confidence that comes from having already survived the adversarial pass, not from hoping nobody notices a gap.
- Persist: write down what the spec, the review, and the red-team pass surfaced, so the next feature starts with that context instead of rediscovering it.
Stage 1 and 2: the spec and the plan both get audited before code exists
Most AI-assisted work skips straight to code because the model is happy to generate something from a two-sentence prompt. The problem is that a two-sentence prompt underspecifies almost everything: what happens on empty input, who is authorized to call this, what the existing code already does that a new implementation must not break. A spec audit forces those questions into the open while they are still cheap to answer. The plan review does the same thing one layer down: given an audited spec, does the proposed architecture actually solve it, or does it reach for a new abstraction, a new dependency, or a pattern that does not match the rest of the codebase? An independent reviewer, one that did not write the plan and has no investment in defending it, is far more likely to catch this than the same model asked to check its own work. For the deeper case on why specs need to exist as artifacts and not just chat history, see spec-driven development.
Stage 3: implementation is test-first, phase by phase
Once the plan clears review, implementation proceeds in small phases, each one starting with a failing test that encodes the behavior the phase is supposed to deliver. The model writes the test first, confirms it fails for the right reason, then writes the minimum code to make it pass. This is mechanical, not aspirational: a phase is done not because the code looks plausible, but because a test that did not exist an hour ago now passes and continues to pass alongside everything that came before it. Breaking the work into phases also keeps each diff small enough that the review stages that follow can actually reason about it, instead of skimming a five-hundred-line change and hoping nothing is wrong.
Keep the spec and the plan as committed files in the repository, not as chat history. Review stages need something durable to read, and a plan that only exists in a conversation cannot be audited by a reviewer who was never part of that conversation.
Stage 4 and 5: the diff gets reviewed, then red-teamed
A finished diff goes to reviewers who see only the code, not the plan or the back-and-forth that produced it. That separation matters: a reviewer with full context tends to rationalize decisions it half-remembers making, while a reviewer starting cold has no choice but to judge the code on what it actually does. This stage catches correctness bugs, weak or missing tests, and inconsistencies with existing patterns elsewhere in the codebase. The red-team gate goes further and assumes hostile intent: given full knowledge of the implementation, how would someone abuse it? This is where authorization checks get tested against the actual request path instead of the happy path, where injection surfaces in shell commands, SQL, or templates get probed, and where race conditions that only matter under concurrent access get flagged. The rule that makes this gate work is simple and non-negotiable: shipping is blocked until the count of critical findings is zero. See the convergence gate explained and red-teaming your AI code for what each of these passes actually looks for.
The point of the workflow is not to slow you down. It is to make production quality the default output of the first pass, instead of something you back into after an incident.
Stage 6 and 7: ship it, then make the next session smarter
Shipping after a change has cleared an audited spec, an independently reviewed plan, test-first implementation, cold-read code review, and a red-team gate is a materially different act than shipping after a single prompt and a glance at the diff. The last stage is the one teams skip most often: capturing what the process surfaced so it does not have to be rediscovered. Decisions the plan review overturned, edge cases the red-team pass found, patterns the codebase actually uses versus what the model assumed by default, all of that is context a fresh session has no way to know unless something persists it. This is the same problem that makes long AI coding sessions degrade over time: the model has no memory between sessions unless you give it one. A private, persistent memory layer like MemX is built for exactly this gap, keeping project context and decisions available across sessions instead of forcing every new conversation to start from a blank page.
| Dimension | Ad hoc prompting | Structured workflow |
|---|---|---|
| Before code is written | A prompt, sometimes a sentence or two | An audited spec and an independently reviewed plan |
| How correctness is checked | Skim the diff, run it once, hope | Test-first implementation plus cold-read multi-agent review |
| Who catches security gaps | Whoever notices in production | A dedicated adversarial red-team gate before shipping |
| What blocks shipping | Nothing, by default | Any open critical finding |
| What the next session knows | Nothing, context resets every time | Persisted decisions and edge cases from the last pass |
Frequently asked questions
01Does this workflow slow down shipping compared to prompting directly?
It adds structure, not necessarily time. Most of the cost of ad hoc prompting shows up later, as bugs, security gaps, and rewrites that a spec audit or a red-team gate would have caught before the code ever merged. The workflow front-loads that cost into stages that are cheap to run and easy to repeat.
02Do the review stages need a different model, or can the same model review its own output?
Independence matters more than which model you use. A reviewer that shares the same context and assumptions as the implementer tends to miss the same things the implementer missed. Routing the plan and the diff to reviewers that start without that shared context, a structurally separate pass rather than a second opinion in the same conversation, is what makes the review stages catch real issues.
03What counts as a critical finding that blocks the red-team gate?
Anything an attacker could use to bypass authorization, exfiltrate data, execute unintended code, or corrupt state through a race condition. The gate is deliberately narrow: it blocks on issues that would cause real harm, not on style preferences, so teams do not learn to route around it.