tdd-claude-code 0.4.2 → 0.5.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,112 +1,168 @@
1
- # TDD Workflow for Claude Code
1
+ # TDD
2
2
 
3
- Test-Led Development powered by [GSD](https://github.com/glittercowboy/get-shit-done).
3
+ **Tests before code. Automatically.**
4
4
 
5
- **One interface. Tests happen automatically. You don't think about methodology.**
5
+ ```bash
6
+ npx tdd-claude-code
7
+ ```
6
8
 
7
9
  <p align="center">
8
- <img src="assets/terminal.svg" alt="TDD Installer" width="700">
10
+ <img src="assets/terminal.svg" alt="TDD" width="700">
9
11
  </p>
10
12
 
11
- ## Install
13
+ ---
12
14
 
13
- ```bash
14
- npx tdd-claude-code
15
+ ## The Problem
16
+
17
+ You tell Claude to build something. It builds it. You test it manually. It's broken. You debug. Repeat.
18
+
19
+ **That's backwards.**
20
+
21
+ ## The Solution
22
+
23
+ TDD writes tests *before* code exists. Every feature has a spec. Every spec is executable. When the code works, you know — because the tests pass.
24
+
25
+ ```
26
+ You describe → Tests are written → Code is implemented → Tests pass → Done
15
27
  ```
16
28
 
17
- GSD is installed automatically if missing.
29
+ No manual testing. No "does this work?" No vibes.
30
+
31
+ ---
32
+
33
+ ## Quick Start
18
34
 
19
- Options:
20
35
  ```bash
21
- npx tdd-claude-code --global # available in all projects
22
- npx tdd-claude-code --local # this project only
36
+ npx tdd-claude-code # Install
23
37
  ```
24
38
 
25
- ## Usage
26
-
27
- You use `/tdd:*` commands for everything. Never touch `/gsd:*` directly.
39
+ Then in Claude Code:
28
40
 
29
41
  ```
30
- /tdd:new-project New project from scratch
31
- OR
32
- /tdd:init Add TDD to existing codebase
33
- /tdd:coverage Write tests for existing code (optional)
34
-
35
- /tdd:discuss Shape how it gets built
36
- /tdd:plan Create task plans
37
- /tdd:build Write tests → implement → tests pass ← TDD happens here
38
- /tdd:verify Human acceptance testing
39
-
40
- /tdd:complete Tag release
42
+ /tdd
41
43
  ```
42
44
 
43
- ## What `/tdd:build` Does
44
-
45
- This is where the magic happens:
45
+ That's it. One command. It knows what to do next.
46
46
 
47
- 1. **Red** Spawns agents to write failing tests for each task
48
- 2. **Verify** Runs tests, confirms they fail (code doesn't exist yet)
49
- 3. **Green** Calls GSD to implement (you walk away)
50
- 4. **Verify** — Runs tests, confirms they pass
47
+ Starting fresh? It asks what you're building.
48
+ Have existing code? It finds untested files.
49
+ Mid-project? It picks up where you left off.
51
50
 
52
- You run one command. Tests get written before code. Automatically.
51
+ ---
53
52
 
54
53
  ## Commands
55
54
 
56
- | Command | What It Does |
57
- |---------|--------------|
58
- | `/tdd:new-project` | Start project with test infrastructure |
59
- | `/tdd:init` | Add TDD to existing codebase |
60
- | `/tdd:coverage` | Analyze gaps, write tests for existing code |
61
- | `/tdd:discuss` | Capture implementation preferences |
62
- | `/tdd:plan` | Create task plans |
63
- | `/tdd:build` | **Write tests → implement → verify** |
64
- | `/tdd:verify` | Human acceptance testing |
65
- | `/tdd:status` | Check test pass/fail |
66
- | `/tdd:progress` | Where am I? |
67
- | `/tdd:quick` | Ad-hoc task with tests |
68
- | `/tdd:complete` | Tag release |
69
- | `/tdd:new-milestone` | Start next version |
70
- | `/tdd:help` | Show all commands |
71
-
72
- ## For Vibe Coders
73
-
74
- No existing codebase? No problem.
75
-
76
- `/tdd:new-project` detects your stack and sets up the test framework:
77
-
78
- | Stack | Framework |
79
- |-------|-----------|
80
- | Next.js / React | Vitest |
81
- | Node.js | Vitest |
82
- | Python | pytest |
83
- | Go | go test |
84
- | Ruby | RSpec |
85
-
86
- You describe what you want. Tests and code get written. You verify it works.
87
-
88
- ## Why TDD?
89
-
90
- **Without TDD:**
55
+ | Command | What |
56
+ |---------|------|
57
+ | `/tdd` | **Smart entry point. Knows what's next.** |
58
+ | `/tdd:new-project` | Start fresh. Discuss stack, scaffold. |
59
+ | `/tdd:init` | Add TDD to existing code. |
60
+ | `/tdd:coverage` | Find untested write tests |
61
+ | `/tdd:quick` | One-off task with tests |
62
+ | `/tdd:status` | Pass/fail counts |
63
+
64
+ ---
65
+
66
+ ## What Makes This Different
67
+
68
+ ### 1. Tests First, Always
69
+
70
+ Other workflows: plan → build → "hope it works"
71
+
72
+ TDD: plan → **write failing tests** → build until tests pass
73
+
74
+ The tests *are* the spec. No ambiguity.
75
+
76
+ ### 2. Smart Stack Selection
77
+
78
+ Don't pick tech in a vacuum. TDD asks what you're building, who uses it, what scale — then suggests the right stack.
79
+
91
80
  ```
92
- Plan Implement → "Does it work?" → Debug → Repeat
81
+ Building: Internal dashboard
82
+ Scale: Small team
83
+ Data: Simple CRUD
84
+
85
+ → Suggested: Next.js + SQLite + Vercel
86
+ → Why: Fast to build, cheap to host, fits your needs
93
87
  ```
94
88
 
95
- **With TDD:**
89
+ ### 3. Parallel Agents
90
+
91
+ Up to 3 Claude instances working simultaneously. GitHub issues as task queue. Watch them go.
92
+
96
93
  ```
97
- Plan → Write tests (spec) → Implement (pass tests) → Verify
94
+ ┌──────────────────────────────────────────────────────┐
95
+ │ Agents │
96
+ │ [1] ● Working on #42: Auth flow │
97
+ │ [2] ● Working on #43: User CRUD │
98
+ │ [3] ○ Idle │
99
+ └──────────────────────────────────────────────────────┘
98
100
  ```
99
101
 
100
- Tests define expected behavior BEFORE code exists. Implementation has concrete pass/fail targets. Bugs surface immediately, not during manual testing.
102
+ ### 4. GitHub Integration
103
+
104
+ Plans approved → issues created automatically. Tasks complete → issues closed. Full audit trail.
105
+
106
+ ### 5. Live Preview
107
+
108
+ Docker container spins up. See your app as it's built. Not after.
109
+
110
+ ---
111
+
112
+ ## Dashboard (Coming Soon)
113
+
114
+ ```
115
+ ┌─────────────────────────────────┬──────────────────────┐
116
+ │ Chat │ GitHub Issues │
117
+ │ │ #42 Auth flow WIP │
118
+ │ Building login endpoint... │ #43 User CRUD │
119
+ │ ✓ Created tests/auth.test.ts │ #44 Dashboard │
120
+ │ ✓ Tests failing (expected) ├──────────────────────┤
121
+ │ Implementing... │ Agents (2/3) │
122
+ │ │ [1] ● #42 │
123
+ │ │ [2] ● #43 │
124
+ │ │ [3] ○ Idle │
125
+ ├─────────────────────────────────┼──────────────────────┤
126
+ │ > add password reset flow │ Tests: 23/23 ✓ │
127
+ └─────────────────────────────────┴──────────────────────┘
128
+ ```
129
+
130
+ TUI dashboard. Multiple panes. Real-time updates.
131
+
132
+ ---
101
133
 
102
- Human verification still happens — tests catch logic errors, you catch "not what I meant" issues.
134
+ ## Philosophy
103
135
 
104
- ## Safe from GSD Updates
136
+ **Tests define behavior. Code makes tests pass.**
105
137
 
106
- TDD lives in `.claude/commands/tdd/`
107
- GSD lives in `.claude/commands/gsd/`
138
+ - Tests written BEFORE code
139
+ - Tests are the spec, not an afterthought
140
+ - If it's not tested, it doesn't exist
141
+ - Human verification still happens — tests catch logic errors, you catch "not what I meant"
142
+
143
+ ---
144
+
145
+ ## vs Other Approaches
146
+
147
+ | Approach | Process | Result |
148
+ |----------|---------|--------|
149
+ | Vibe coding | Build → hope | Works until it doesn't |
150
+ | Manual TDD | Write tests yourself | Slow, easy to skip |
151
+ | **TDD Workflow** | Tests auto-generated first | Fast, guaranteed coverage |
152
+
153
+ ---
154
+
155
+ ## Install
156
+
157
+ ```bash
158
+ npx tdd-claude-code
159
+ ```
160
+
161
+ Options:
162
+ - `--global` — Available everywhere
163
+ - `--local` — This project only
108
164
 
109
- Running `npx get-shit-done-cc@latest` only touches GSD. Your TDD commands are untouched.
165
+ ---
110
166
 
111
167
  ## License
112
168
 
package/bin/install.js CHANGED
@@ -26,9 +26,10 @@ ${c.cyan} ████████╗██████╗ ██████
26
26
  ╚═╝ ╚═════╝ ╚═════╝${c.reset}
27
27
  `;
28
28
 
29
- const VERSION = '0.4.2';
29
+ const VERSION = '0.5.0';
30
30
 
31
31
  const COMMANDS = [
32
+ 'tdd.md',
32
33
  'new-project.md',
33
34
  'init.md',
34
35
  'coverage.md',
@@ -126,14 +127,15 @@ function install(targetDir, installType) {
126
127
  log('');
127
128
  log(`${c.green}Done!${c.reset} Restart Claude Code to load commands.`);
128
129
  log('');
129
- log(`${c.bold}Workflow:${c.reset}`);
130
- log(` ${c.cyan}/tdd:new-project${c.reset} Start project with test infrastructure`);
131
- log(` ${c.cyan}/tdd:discuss${c.reset} Shape implementation preferences`);
132
- log(` ${c.cyan}/tdd:plan${c.reset} Create task plans`);
133
- log(` ${c.cyan}/tdd:build${c.reset} Write tests → implement → verify`);
134
- log(` ${c.cyan}/tdd:verify${c.reset} Human acceptance testing`);
130
+ log(`${c.bold}Quick Start:${c.reset}`);
131
+ log(` ${c.cyan}/tdd${c.reset} Smart entry point - knows what to do next`);
135
132
  log('');
136
- log(`Run ${c.cyan}/tdd:help${c.reset} for full command list.`);
133
+ log(`${c.dim}Or use specific commands:${c.reset}`);
134
+ log(` ${c.cyan}/tdd:new-project${c.reset} Start new project`);
135
+ log(` ${c.cyan}/tdd:init${c.reset} Add TDD to existing code`);
136
+ log(` ${c.cyan}/tdd:coverage${c.reset} Find and fix test gaps`);
137
+ log('');
138
+ log(`Run ${c.cyan}/tdd:help${c.reset} for all commands.`);
137
139
  log('');
138
140
  }
139
141
 
package/build.md CHANGED
@@ -14,11 +14,9 @@ This is the core TDD command. Tests before code, automatically.
14
14
  ## Usage
15
15
 
16
16
  ```
17
- /tdd:build [phase_number]
17
+ /tdd:build <phase_number>
18
18
  ```
19
19
 
20
- Phase number is optional. Defaults to 1.
21
-
22
20
  ## Process
23
21
 
24
22
  ### Step 1: Load Plans
package/help.md CHANGED
@@ -1,103 +1,115 @@
1
1
  # /tdd:help - Test-Led Development Commands
2
2
 
3
- TDD-first workflow powered by GSD. You use `/tdd:*` for everything — tests happen automatically.
3
+ ## Quick Start
4
4
 
5
- ## Commands
5
+ ```
6
+ /tdd
7
+ ```
6
8
 
7
- ### Getting Started
9
+ That's it. Detects where you are, tells you what's next.
8
10
 
9
- | Command | What It Does |
10
- |---------|--------------|
11
- | `/tdd:new-project` | Start new project with test infrastructure |
12
- | `/tdd:init` | Add TDD to existing codebase |
13
- | `/tdd:coverage` | Analyze gaps, write tests for existing code |
11
+ ---
12
+
13
+ ## All Commands
14
14
 
15
- ### Core Workflow
15
+ ### The Smart One
16
16
 
17
17
  | Command | What It Does |
18
18
  |---------|--------------|
19
- | `/tdd:discuss` | Capture implementation preferences |
20
- | `/tdd:plan` | Research and create task plans |
21
- | `/tdd:build` | **Write tests → implement → verify tests pass** |
22
- | `/tdd:verify` | Human acceptance testing |
19
+ | `/tdd` | **Context-aware entry point. Knows what to do next.** |
23
20
 
24
- Phase number optional. Defaults to 1.
25
-
26
- ### Navigation
21
+ ### Setup
27
22
 
28
23
  | Command | What It Does |
29
24
  |---------|--------------|
30
- | `/tdd:progress` | Where am I? What's next? |
31
- | `/tdd:status [N]` | Check test pass/fail counts |
32
- | `/tdd:help` | Show this help |
25
+ | `/tdd:new-project` | Start new project (discusses stack, creates roadmap) |
26
+ | `/tdd:init` | Add TDD to existing code |
27
+ | `/tdd:coverage` | Find untested code, write tests |
33
28
 
34
- ### Milestones
29
+ ### Build (rarely needed directly)
35
30
 
36
31
  | Command | What It Does |
37
32
  |---------|--------------|
38
- | `/tdd:complete` | Archive milestone, tag release |
39
- | `/tdd:new-milestone [name]` | Start next version |
33
+ | `/tdd:discuss` | Shape implementation approach |
34
+ | `/tdd:plan` | Create task plan |
35
+ | `/tdd:build` | Write tests → implement → verify |
36
+ | `/tdd:verify` | Human acceptance testing |
40
37
 
41
- ### Quick Tasks
38
+ ### Utility
42
39
 
43
40
  | Command | What It Does |
44
41
  |---------|--------------|
45
- | `/tdd:quick` | Ad-hoc task with test-first flow |
42
+ | `/tdd:status` | Test pass/fail counts |
43
+ | `/tdd:quick` | One-off task with tests |
44
+ | `/tdd:complete` | Tag release |
45
+ | `/tdd:new-milestone` | Start next version |
46
+
47
+ ---
46
48
 
47
49
  ## Workflow
48
50
 
51
+ **Simple version:**
52
+ ```
53
+ /tdd <- just keep running this
54
+ ```
55
+
56
+ **Detailed version:**
49
57
  ```
50
- /tdd:new-project New project from scratch
51
- OR
52
- /tdd:init Existing codebase
53
- /tdd:coverage Write tests for existing code (optional)
58
+ /tdd:new-project New project
54
59
 
55
- /tdd:discuss Shape how it gets built
56
- /tdd:plan Create task plans
57
- /tdd:build Write tests → implement → tests pass
58
- /tdd:verify Human acceptance testing
60
+ /tdd Guides you through each phase:
61
+ → discuss → plan build → verify
59
62
 
60
- /tdd:complete Tag release
63
+ /tdd:complete Tag release
61
64
  ```
62
65
 
63
- ## What Happens in `/tdd:build`
66
+ ---
64
67
 
65
- This is where TDD happens:
68
+ ## What `/tdd` Does
66
69
 
67
- 1. **Red** Write failing tests for each task in the plan
68
- 2. **Verify** — Run tests, confirm they fail
69
- 3. **Green** — Implement code (via GSD execute-phase)
70
- 4. **Verify** — Run tests, confirm they pass
70
+ Checks project state and presents ONE action:
71
71
 
72
- You don't think about it. Just run `/tdd:build` and tests happen before code.
72
+ ```
73
+ > /tdd
73
74
 
74
- ## Philosophy
75
+ Phase 2: User Dashboard
76
+ Status: Planned, not built
77
+
78
+ 4 tasks ready. Tests will be written first.
79
+
80
+ → Build phase 2? (Y/n)
81
+ ```
82
+
83
+ Or if you have untested code:
75
84
 
76
- **Tests define behavior. Implementation makes tests pass.**
85
+ ```
86
+ > /tdd
87
+
88
+ Found 3 files without tests:
89
+ - src/utils/format.ts
90
+ - src/api/health.ts
91
+ - src/middleware/auth.ts
92
+
93
+ Add tests? (Y/n)
94
+ ```
77
95
 
78
- - Tests are written BEFORE code exists
79
- - Tests are the spec, not an afterthought
80
- - Human verification still happens at the end
81
- - You never invoke GSD directly — TDD wraps it
96
+ ---
82
97
 
83
- ## GSD Under the Hood
98
+ ## Philosophy
84
99
 
85
- TDD commands call GSD internally:
100
+ **Tests define behavior. Code makes tests pass.**
86
101
 
87
- | TDD Command | Calls |
88
- |-------------|-------|
89
- | `/tdd:new-project` | `/gsd:new-project` + test setup |
90
- | `/tdd:init` | scan + test setup (no GSD call) |
91
- | `/tdd:coverage` | scan + write tests (no GSD call) |
92
- | `/tdd:discuss` | `/gsd:discuss-phase` |
93
- | `/tdd:plan` | `/gsd:plan-phase` |
94
- | `/tdd:build` | write tests + `/gsd:execute-phase` |
95
- | `/tdd:verify` | test check + `/gsd:verify-work` |
102
+ - Tests written BEFORE code
103
+ - Tests are the spec, not afterthought
104
+ - Human verification still happens
105
+ - No phase numbers to remember
96
106
 
97
- GSD does the planning and execution. TDD ensures tests come first.
107
+ ---
98
108
 
99
109
  ## Installation
100
110
 
101
- Lives in `.claude/commands/tdd/` — separate from GSD.
111
+ ```bash
112
+ npx tdd-claude-code
113
+ ```
102
114
 
103
- GSD updates only touch `.claude/commands/gsd/`. Your TDD commands survive updates.
115
+ Lives in `.claude/commands/tdd/`
package/new-project.md CHANGED
@@ -4,14 +4,163 @@ Initialize a new project with test-led development.
4
4
 
5
5
  ## What This Does
6
6
 
7
- Calls `/gsd:new-project` with TDD conventions automatically added to PROJECT.md.
7
+ 1. Gather requirements and context
8
+ 2. Suggest tech stack based on your needs
9
+ 3. Create roadmap
10
+ 4. Set up test infrastructure
8
11
 
9
12
  ## Process
10
13
 
11
- 1. **Run GSD new-project flow**
12
- - Questions → Research → Requirements → Roadmap
13
-
14
- 2. **After PROJECT.md is created, append TDD conventions:**
14
+ ### Step 1: Understand What You're Building
15
+
16
+ Start by understanding the project:
17
+
18
+ **Core purpose:**
19
+ ```
20
+ What are you building? (1-2 sentences)
21
+ ```
22
+
23
+ **Target users:**
24
+ ```
25
+ Who uses this?
26
+
27
+ 1) Just me / internal tool
28
+ 2) Small team (<10 users)
29
+ 3) Startup scale (100-10K users)
30
+ 4) Growth stage (10K-100K users)
31
+ 5) Enterprise / high scale (100K+ users)
32
+ ```
33
+
34
+ **Data characteristics:**
35
+ ```
36
+ What kind of data?
37
+
38
+ 1) Simple CRUD - users, posts, etc.
39
+ 2) Relational - complex relationships, joins
40
+ 3) Document-oriented - flexible schemas
41
+ 4) Time-series - logs, metrics, events
42
+ 5) Graph - relationships are the data
43
+ 6) Minimal / stateless
44
+ ```
45
+
46
+ **Real-time requirements:**
47
+ ```
48
+ Do you need real-time features?
49
+
50
+ 1) No - standard request/response
51
+ 2) Some - notifications, live updates
52
+ 3) Heavy - chat, collaboration, streaming
53
+ ```
54
+
55
+ **Existing constraints:**
56
+ ```
57
+ Any constraints I should know?
58
+
59
+ - Team experience (what languages/tools do you know?)
60
+ - Existing infrastructure (AWS, GCP, on-prem?)
61
+ - Budget considerations
62
+ - Compliance requirements (HIPAA, SOC2, etc.)
63
+ - Timeline pressure
64
+ ```
65
+
66
+ ### Step 2: Suggest Tech Stack
67
+
68
+ Based on answers, suggest appropriate stack:
69
+
70
+ **Example: Internal tool, small team, simple CRUD**
71
+ ```
72
+ Suggested Stack:
73
+
74
+ | Component | Recommendation | Why |
75
+ |-----------|----------------|-----|
76
+ | Language | TypeScript | Type safety, good tooling |
77
+ | Framework | Next.js | Full-stack, fast to build |
78
+ | Database | SQLite or Postgres | Simple, reliable |
79
+ | Architecture | Monolith | No need for complexity |
80
+ | Hosting | Vercel or Railway | Easy deploy, free tier |
81
+
82
+ Alternatives to consider:
83
+ - Python + FastAPI if more comfortable with Python
84
+ - Supabase if you want auth + DB bundled
85
+ ```
86
+
87
+ **Example: Growth stage SaaS, real-time, complex data**
88
+ ```
89
+ Suggested Stack:
90
+
91
+ | Component | Recommendation | Why |
92
+ |-----------|----------------|-----|
93
+ | Language | TypeScript | Type safety at scale |
94
+ | Framework | Next.js + tRPC | Type-safe API layer |
95
+ | Database | PostgreSQL | Reliable, scalable |
96
+ | Cache | Redis | Sessions, real-time |
97
+ | Architecture | Modular monolith | Scale when needed |
98
+ | Hosting | Docker + K8s ready | Portable, scalable |
99
+
100
+ Alternatives to consider:
101
+ - Go if performance is critical
102
+ - Microservices if team is large enough
103
+ ```
104
+
105
+ **Example: High-performance API, minimal latency**
106
+ ```
107
+ Suggested Stack:
108
+
109
+ | Component | Recommendation | Why |
110
+ |-----------|----------------|-----|
111
+ | Language | Go or Rust | Performance, efficiency |
112
+ | Framework | stdlib or Axum | Minimal overhead |
113
+ | Database | PostgreSQL + Redis | Speed + reliability |
114
+ | Architecture | Microservices | Scale independently |
115
+ | Hosting | Kubernetes | Production-grade |
116
+ ```
117
+
118
+ ### Step 3: Confirm or Adjust
119
+
120
+ ```
121
+ Does this stack work for you?
122
+
123
+ 1) Yes, proceed with this
124
+ 2) I'd prefer [language] instead
125
+ 3) Let's discuss alternatives
126
+ ```
127
+
128
+ Allow user to override any decision with rationale captured.
129
+
130
+ ### Step 4: Record Decisions
131
+
132
+ Create PROJECT.md with tech decisions:
133
+
134
+ ```markdown
135
+ # Project Name
136
+
137
+ ## Overview
138
+ [From step 1 discussion]
139
+
140
+ ## Tech Stack
141
+
142
+ | Decision | Choice | Rationale |
143
+ |----------|--------|-----------|
144
+ | Language | TypeScript | Team familiarity |
145
+ | Framework | Next.js | Full-stack, good DX |
146
+ | Database | PostgreSQL | Relational data needs |
147
+ | Architecture | Modular monolith | Start simple |
148
+ | Hosting | Docker + Railway | Easy CI/CD |
149
+
150
+ ## Constraints
151
+ - Timeline: MVP in 4 weeks
152
+ - Team: Solo developer
153
+ - Budget: Minimal hosting costs
154
+ ```
155
+
156
+ ### Step 5: Run GSD for Roadmap
157
+
158
+ Call `/gsd:new-project` internals to:
159
+ - Generate requirements from discussion
160
+ - Create phase-based roadmap
161
+ - Define milestones
162
+
163
+ ### Step 6: Append TDD Conventions
15
164
 
16
165
  ```markdown
17
166
  ## Development Methodology: Test-Led Development
@@ -19,33 +168,31 @@ Calls `/gsd:new-project` with TDD conventions automatically added to PROJECT.md.
19
168
  This project uses TDD. All implementation follows Red → Green → Refactor:
20
169
 
21
170
  1. **Red**: Write failing tests that define expected behavior
22
- 2. **Green**: Write minimum code to make tests pass
171
+ 2. **Green**: Write minimum code to make tests pass
23
172
  3. **Refactor**: Clean up while keeping tests green
24
173
 
25
174
  Tests are written BEFORE implementation, not after.
26
- ```
27
175
 
28
- 3. **Detect or set up test framework** based on stack chosen during setup:
176
+ ## Test Framework
177
+ - [Framework based on stack]
178
+ - Run: `npm test` / `pytest` / `go test`
179
+ ```
29
180
 
30
- | Stack | Framework | Config |
31
- |-------|-----------|--------|
32
- | Next.js / React | Vitest | `vitest.config.ts` |
33
- | Node.js | Vitest or Jest | `vitest.config.ts` |
34
- | Python | pytest | `pytest.ini` or `pyproject.toml` |
35
- | Go | go test | (built-in) |
36
- | Ruby | RSpec | `.rspec`, `spec/spec_helper.rb` |
181
+ ### Step 7: Set Up Project Structure
37
182
 
38
- 4. **Create test directory structure** if it doesn't exist:
39
- - `tests/` or `__tests__/` or `spec/` depending on convention
40
- - Example test file showing project patterns
183
+ Scaffold based on chosen stack:
41
184
 
42
- 5. **Add test script** to package.json / pyproject.toml / Makefile:
43
- ```json
44
- "scripts": {
45
- "test": "vitest run",
46
- "test:watch": "vitest"
47
- }
48
- ```
185
+ ```
186
+ project/
187
+ ├── src/
188
+ ├── tests/
189
+ ├── .env.example
190
+ ├── docker-compose.yml
191
+ ├── Dockerfile
192
+ ├── [package.json | pyproject.toml | go.mod]
193
+ ├── [vitest.config.ts | pytest.ini]
194
+ └── PROJECT.md
195
+ ```
49
196
 
50
197
  ## Usage
51
198
 
@@ -53,4 +200,9 @@ Tests are written BEFORE implementation, not after.
53
200
  /tdd:new-project
54
201
  ```
55
202
 
56
- Same interactive flow as GSD, but you end up with test infrastructure ready to go.
203
+ Interactive flow that:
204
+ 1. Understands what you're building
205
+ 2. Suggests appropriate tech
206
+ 3. Lets you adjust
207
+ 4. Creates roadmap
208
+ 5. Sets up tests
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "tdd-claude-code",
3
- "version": "0.4.2",
3
+ "version": "0.5.0",
4
4
  "description": "TDD workflow for Claude Code - wraps GSD",
5
5
  "bin": {
6
6
  "tdd-claude-code": "./bin/install.js"
package/tdd.md ADDED
@@ -0,0 +1,215 @@
1
+ # /tdd - Smart Entry Point
2
+
3
+ One command. Context-aware. Tells you what to do next.
4
+
5
+ ## What This Does
6
+
7
+ Detects project state and suggests the right action. No memorizing commands.
8
+
9
+ ## Process
10
+
11
+ ### Step 1: Detect Project State
12
+
13
+ Check what exists:
14
+
15
+ ```
16
+ □ PROJECT.md exists?
17
+ □ .planning/ directory exists?
18
+ □ .planning/ROADMAP.md exists?
19
+ □ Test framework configured? (vitest.config.*, pytest.ini, etc.)
20
+ □ Test files exist?
21
+ □ Source files exist?
22
+ ```
23
+
24
+ ### Step 2: Route Based on State
25
+
26
+ **No PROJECT.md → New or Init**
27
+ ```
28
+ No project detected.
29
+
30
+ 1) Start new project (/tdd:new-project)
31
+ 2) Add TDD to existing code (/tdd:init)
32
+ ```
33
+
34
+ **PROJECT.md exists, no roadmap → Need Planning**
35
+ ```
36
+ Project exists but no roadmap.
37
+
38
+ Creating phases for your project...
39
+ [Run /gsd:new-project internals to create ROADMAP.md]
40
+ ```
41
+
42
+ **Roadmap exists → Check Phase Status**
43
+
44
+ Parse ROADMAP.md to find:
45
+ - Completed phases: `[x]` or `[completed]`
46
+ - Current phase: `[>]` or `[in progress]` or `[current]`
47
+ - Next pending phase: first without marker
48
+
49
+ ### Step 3: Determine Current Phase Action
50
+
51
+ For the current/next phase, check what exists:
52
+
53
+ ```
54
+ Phase {N}: {Name}
55
+ □ DISCUSSION.md exists? (.planning/phases/{N}-DISCUSSION.md)
56
+ □ PLAN.md exists? (.planning/phases/{N}-*-PLAN.md)
57
+ □ Tests written? (.planning/phases/{N}-TESTS.md or test files)
58
+ □ Implementation done? (check if tests pass)
59
+ □ Verified? (.planning/phases/{N}-VERIFIED.md)
60
+ ```
61
+
62
+ ### Step 4: Present Contextual Action
63
+
64
+ Based on phase state, show ONE clear action:
65
+
66
+ **Phase not discussed:**
67
+ ```
68
+ Phase 2: User Dashboard
69
+
70
+ Ready to discuss implementation approach.
71
+
72
+ → Continue? (Y/n)
73
+ ```
74
+ Then run discuss flow.
75
+
76
+ **Discussed but not planned:**
77
+ ```
78
+ Phase 2: User Dashboard
79
+
80
+ Discussion complete. Ready to create task plan.
81
+
82
+ → Continue? (Y/n)
83
+ ```
84
+ Then run plan flow.
85
+
86
+ **Planned but no tests:**
87
+ ```
88
+ Phase 2: User Dashboard
89
+
90
+ Plan ready. 4 tasks to implement.
91
+
92
+ Next: Write tests, then build.
93
+
94
+ → Continue? (Y/n)
95
+ ```
96
+ Then run build flow (tests first).
97
+
98
+ **Tests written, not implemented:**
99
+ ```
100
+ Phase 2: User Dashboard
101
+
102
+ Tests ready (12 tests, all failing - expected).
103
+
104
+ Next: Implement to make tests pass.
105
+
106
+ → Continue? (Y/n)
107
+ ```
108
+ Then run implementation.
109
+
110
+ **Implemented, not verified:**
111
+ ```
112
+ Phase 2: User Dashboard
113
+
114
+ Tests passing (12/12 ✓)
115
+
116
+ Next: Human verification.
117
+
118
+ → Continue? (Y/n)
119
+ ```
120
+ Then run verify flow.
121
+
122
+ **Phase complete:**
123
+ ```
124
+ Phase 2: User Dashboard ✓ Complete
125
+
126
+ Moving to Phase 3: Reports
127
+
128
+ → Continue? (Y/n)
129
+ ```
130
+
131
+ ### Step 5: Check for Untested Code
132
+
133
+ If project has source files without tests:
134
+
135
+ ```
136
+ Found 5 files without tests:
137
+ - src/utils/helpers.ts
138
+ - src/api/users.ts
139
+ - src/services/email.ts
140
+ ...
141
+
142
+ Add tests for existing code? (Y/n)
143
+ ```
144
+
145
+ If yes, run `/tdd:coverage` flow.
146
+
147
+ ### Step 6: All Phases Complete
148
+
149
+ ```
150
+ All phases complete! 🎉
151
+
152
+ Milestone ready for release.
153
+
154
+ 1) Tag release (/tdd:complete)
155
+ 2) Start next milestone (/tdd:new-milestone)
156
+ 3) Check test coverage (/tdd:coverage)
157
+ ```
158
+
159
+ ## Examples
160
+
161
+ **Fresh directory:**
162
+ ```
163
+ > /tdd
164
+
165
+ No project detected.
166
+
167
+ What would you like to do?
168
+ 1) Start new project
169
+ 2) Add TDD to existing code
170
+ ```
171
+
172
+ **Mid-project:**
173
+ ```
174
+ > /tdd
175
+
176
+ Phase 2: User Dashboard
177
+ Status: Planned, not built
178
+
179
+ 4 tasks ready. Tests will be written first.
180
+
181
+ → Build phase 2? (Y/n)
182
+ ```
183
+
184
+ **Has untested code:**
185
+ ```
186
+ > /tdd
187
+
188
+ Phase 3: Reports [current]
189
+
190
+ Also found: 3 files without test coverage
191
+ - src/utils/format.ts
192
+ - src/api/health.ts
193
+ - src/middleware/auth.ts
194
+
195
+ 1) Continue with Phase 3
196
+ 2) Add tests to existing code first
197
+ ```
198
+
199
+ ## Usage
200
+
201
+ ```
202
+ /tdd
203
+ ```
204
+
205
+ No arguments. Auto-detects everything.
206
+
207
+ ## Why This Exists
208
+
209
+ Instead of remembering:
210
+ - `/tdd:discuss 2`
211
+ - `/tdd:plan 2`
212
+ - `/tdd:build 2`
213
+ - `/tdd:verify 2`
214
+
215
+ Just run `/tdd`. It knows where you are.