Sample run: step 1 on our own idea
The first step of BDDtoTDD turns a raw idea into candidate goals, each with a plain statement of what success would mean. We ran it with Claude on the idea behind BDDtoTDD itself.
Run on 2026-08-14 · 13 turns · finishedIn
The idea, as the founder typed it:
An app that takes a raw idea for an app, one or more features, or a framework, and produces BDD specs + use cases + the test structure for TDD.
That sentence names a solution, not a problem. So Claude does not start from the list of things to build. It asks why, one level at a time, until it reaches the pain underneath.
Asking why, from the solution down to the pain
- Produce BDD specs, use cases and a test structure
- Reached for BDD, but does not know how to derive it
- Does not know whether the behaviour is covered
- TDD has no starting point: deciding what to test next is guesswork
- Notes written alone come out missing rules and scenarios
- Works solo, with nobody to push back
The deepest harm the founder named: false confidence, a green test suite that covers lines of code but not the behaviour.
Out: eight candidate goals
Each goal is a pain plus a statement of success the founder can check. Step 1 chooses nothing: the founder picks which goal goes on to step 2.
| The pain | Success means | |
|---|---|---|
| 1 | Starting TDD means inventing the next test yourself | Open the spec and the first test, and the order of the rest reads straight off it |
| 2 | A green suite that only covers lines of code | Every behaviour and edge case in the spec has a test pointing at it; green means those behaviours hold |
| 3 | Months later, no idea what the system does | Read a feature's documentation and say what it does and where it breaks, without opening the code |
| 4 | Blank-file paralysis | Sitting down to write, the shape of the first scenario is already there |
| 5 | Specs that turn into click-by-click scripts | No UI steps; one rule per scenario; business words, not technical ones |
| 6 | Spec in one place, tests in another | Every spec item names its test, and editing a spec item tells you which test must change |
| 7 | Tests bound to the code rather than the system | A description of what the system does exists, and every test traces to a step or an error path in it |
| 8 | No idea which story belongs to which feature | Given two stories, say whether they belong to the same feature and state the criterion |
How the list was reached
Claude keeps asking until two quiet turns in a row, each from a different angle. Three turns changed the result in ways a single pass would have missed:
| Turn | Angle | What changed |
|---|---|---|
| 1 | Discuss the pain | Seven goals proposed |
| 3 | Check against what the idea named | One goal split in two |
| 9 | Challenge: is each one a pain of its own? | One goal removed: it was a consequence of two others |
| 10–11 | Rewrite the list so the founder can read it | A new goal surfaced (goal 8) |
| 12–13 | Scan for gaps; then: any lost day in the last three months this list cannot name? | Nothing new: the founder declared it enough for now |
The challenge at turn 9 is the point: the list got shorter, not longer. The tool is built to keep only what a question earned.
This run used the step-1 rules as they stood on 2026-08-14. Running it, and the runs after it, changed several of those rules; the current version reads the founder's own list first and returns the goals as a tiered tree.