| name | dev-tdd-loop |
| description | Use when shipping any non-trivial dev feature - chains brainstorm, plan, step-by-step execution, and verification before shipping |
| kind | workflow |
| audience | dev |
| ai-tools | any |
| complexity | chained |
| time | hours to weeks depending on feature |
| version | 1.0.0 |
| source | bundled |
| composes | ["brainstorming-a-feature","writing-an-implementation-plan","executing-a-plan-step-by-step","verifying-before-shipping"] |
Dev TDD Loop
What this does
The default chain for shipping any non-trivial dev feature. Runs four bundled spells in sequence: brainstorm the approach, write the implementation plan, execute step-by-step with per-step verification, and run a final verification pass before declaring "done." Equivalent in spirit to a TDD-rigorous engineering workflow.
When to use
- Shipping a feature beyond a one-line tweak
- Onboarding a team to a structured engineering workflow
- When "we shipped it but it broke" has happened more than once
- When the implementation will span more than a few hours
Do not use when
- Trivial fix (typo, copy change, single-line guard)
- Pure exploration / spike — use it AFTER the spike, when productionizing
- Emergency hotfix where the verification step happens via post-mortem instead
What you bring (Inputs)
- A feature request, ticket, or one-line description
- Codebase access
- A definition of "shipped" (deploy, merge to main, release tag, etc.)
What you get (Output)
- A brainstorm document
- An implementation plan with per-step verifications
- The implemented feature with all step verifications passing
- A verification pass against acceptance criteria, completed before shipping
How it works (Steps)
This is a chain of 4 spells. Each stage hands an artifact to the next.
Stages
Stage 1: Brainstorm (brainstorming-a-feature)
- Skill:
brainstorming-a-feature
- Input: feature request
- Output handoff: brainstorm doc with sharp problem statement, 3-5 candidate approaches, recommendation, alternative considered, top assumptions
- Gate: problem statement passes the "stranger could understand it" test; alternative is plausible
Stage 2: Plan (writing-an-implementation-plan)
- Skill:
writing-an-implementation-plan
- Input: chosen approach from Stage 1
- Output handoff: implementation plan with file-level changes, ordering, per-step verifications, risks, acceptance criteria
- Gate: every step has explicit verification; another engineer could execute without clarifying questions
Stage 3: Execute (executing-a-plan-step-by-step)
- Skill:
executing-a-plan-step-by-step
- Input: the plan from Stage 2
- Output handoff: implemented feature, plan marked done with deviations recorded, deferred-list captured
- Gate: every step's verification passes; no "while I'm here" changes mixed in
Stage 4: Verify before shipping (verifying-before-shipping)
- Skill:
verifying-before-shipping
- Input: implemented feature + acceptance criteria from Stage 2
- Output handoff: a documented verification pass
- Gate: every acceptance criterion verified or explicitly waived with a reason
Checkpoints
- After Stage 1: problem statement is sharp; alternative is plausible
- After Stage 2: every plan step has explicit verification
- After Stage 3: every step's verification has been run and passed; deferred list captured
- After Stage 4: every acceptance criterion verified or explicitly waived
Loop-back conditions
- Stage 1 chosen approach turns out infeasible mid-Stage 2: return to Stage 1 with the new constraints
- Stage 2 missing per-step verifications: do not start Stage 3 — fix the plan first
- Stage 3 verification fails repeatedly: pause execution; investigate; possibly return to Stage 2 to re-plan that segment
- Stage 4 surfaces an unmet acceptance criterion: return to Stage 3 to add steps; re-verify
Quality bar
- Every chain stage's gate passed before moving on
- The deferred list is captured (not lost)
- The verification pass at Stage 4 is documented, not just "I checked it"
- Future-you (or a teammate) can read the artifacts and understand why each decision was made
Variations
- Tiny feature: skip Stage 1 (problem is obvious); collapse Stages 2-3 into a 1-page plan + execute; keep Stage 4 always
- Spike followed by productionizing: run the spike unmanaged, then run the chain on the productionizing pass
- Multi-PR feature: run Stages 1-2 once for the whole feature; run Stages 3-4 per-PR
Example
Input: Ticket — "Add SSO for enterprise customers."
Flow:
- Stage 1 produces a brainstorm; recommends Auth0 SAML; alternative (SaaS auth) considered and rejected on lock-in cost
- Stage 2 produces a 12-step plan; 5 files, 1 migration, per-step verifications all defined
- Stage 3 executes the 12 steps; step 3 (middleware) fails initially because of XML/JSON parser confusion → diagnosed and fixed → continues; deferred list captures 3 unrelated improvements noticed along the way
- Stage 4 runs the 6 acceptance criteria; all pass; one criterion (rollback playbook) was added during implementation and explicitly verified
Output: SSO shipped, plan archived, deferred list filed, verification documented.
