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 +133 -77
- package/bin/install.js +10 -8
- package/build.md +1 -3
- package/help.md +72 -60
- package/new-project.md +178 -26
- package/package.json +1 -1
- package/tdd.md +215 -0
package/README.md
CHANGED
|
@@ -1,112 +1,168 @@
|
|
|
1
|
-
# TDD
|
|
1
|
+
# TDD
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
**Tests before code. Automatically.**
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
```bash
|
|
6
|
+
npx tdd-claude-code
|
|
7
|
+
```
|
|
6
8
|
|
|
7
9
|
<p align="center">
|
|
8
|
-
<img src="assets/terminal.svg" alt="TDD
|
|
10
|
+
<img src="assets/terminal.svg" alt="TDD" width="700">
|
|
9
11
|
</p>
|
|
10
12
|
|
|
11
|
-
|
|
13
|
+
---
|
|
12
14
|
|
|
13
|
-
|
|
14
|
-
|
|
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
|
-
|
|
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
|
|
22
|
-
npx tdd-claude-code --local # this project only
|
|
36
|
+
npx tdd-claude-code # Install
|
|
23
37
|
```
|
|
24
38
|
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
You use `/tdd:*` commands for everything. Never touch `/gsd:*` directly.
|
|
39
|
+
Then in Claude Code:
|
|
28
40
|
|
|
29
41
|
```
|
|
30
|
-
/tdd
|
|
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
|
-
|
|
44
|
-
|
|
45
|
-
This is where the magic happens:
|
|
45
|
+
That's it. One command. It knows what to do next.
|
|
46
46
|
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
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
|
-
|
|
51
|
+
---
|
|
53
52
|
|
|
54
53
|
## Commands
|
|
55
54
|
|
|
56
|
-
| Command | What
|
|
57
|
-
|
|
58
|
-
| `/tdd
|
|
59
|
-
| `/tdd:
|
|
60
|
-
| `/tdd:
|
|
61
|
-
| `/tdd:
|
|
62
|
-
| `/tdd:
|
|
63
|
-
| `/tdd:
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
134
|
+
## Philosophy
|
|
103
135
|
|
|
104
|
-
|
|
136
|
+
**Tests define behavior. Code makes tests pass.**
|
|
105
137
|
|
|
106
|
-
|
|
107
|
-
|
|
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
|
-
|
|
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.
|
|
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}
|
|
130
|
-
log(` ${c.cyan}/tdd
|
|
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(
|
|
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
package/help.md
CHANGED
|
@@ -1,103 +1,115 @@
|
|
|
1
1
|
# /tdd:help - Test-Led Development Commands
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
## Quick Start
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
```
|
|
6
|
+
/tdd
|
|
7
|
+
```
|
|
6
8
|
|
|
7
|
-
|
|
9
|
+
That's it. Detects where you are, tells you what's next.
|
|
8
10
|
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
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
|
-
###
|
|
15
|
+
### The Smart One
|
|
16
16
|
|
|
17
17
|
| Command | What It Does |
|
|
18
18
|
|---------|--------------|
|
|
19
|
-
| `/tdd
|
|
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
|
-
|
|
25
|
-
|
|
26
|
-
### Navigation
|
|
21
|
+
### Setup
|
|
27
22
|
|
|
28
23
|
| Command | What It Does |
|
|
29
24
|
|---------|--------------|
|
|
30
|
-
| `/tdd:
|
|
31
|
-
| `/tdd:
|
|
32
|
-
| `/tdd:
|
|
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
|
-
###
|
|
29
|
+
### Build (rarely needed directly)
|
|
35
30
|
|
|
36
31
|
| Command | What It Does |
|
|
37
32
|
|---------|--------------|
|
|
38
|
-
| `/tdd:
|
|
39
|
-
| `/tdd:
|
|
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
|
-
###
|
|
38
|
+
### Utility
|
|
42
39
|
|
|
43
40
|
| Command | What It Does |
|
|
44
41
|
|---------|--------------|
|
|
45
|
-
| `/tdd:
|
|
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
|
|
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
|
|
56
|
-
|
|
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
|
|
63
|
+
/tdd:complete Tag release
|
|
61
64
|
```
|
|
62
65
|
|
|
63
|
-
|
|
66
|
+
---
|
|
64
67
|
|
|
65
|
-
|
|
68
|
+
## What `/tdd` Does
|
|
66
69
|
|
|
67
|
-
|
|
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
|
-
|
|
72
|
+
```
|
|
73
|
+
> /tdd
|
|
73
74
|
|
|
74
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
##
|
|
98
|
+
## Philosophy
|
|
84
99
|
|
|
85
|
-
|
|
100
|
+
**Tests define behavior. Code makes tests pass.**
|
|
86
101
|
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
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
|
-
|
|
107
|
+
---
|
|
98
108
|
|
|
99
109
|
## Installation
|
|
100
110
|
|
|
101
|
-
|
|
111
|
+
```bash
|
|
112
|
+
npx tdd-claude-code
|
|
113
|
+
```
|
|
102
114
|
|
|
103
|
-
|
|
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
|
-
|
|
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
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
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
|
-
|
|
176
|
+
## Test Framework
|
|
177
|
+
- [Framework based on stack]
|
|
178
|
+
- Run: `npm test` / `pytest` / `go test`
|
|
179
|
+
```
|
|
29
180
|
|
|
30
|
-
|
|
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
|
-
|
|
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
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
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
|
-
|
|
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
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.
|