gsd-vscode-copilot 1.0.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/LICENSE +21 -0
- package/README.md +93 -0
- package/bin/init.js +184 -0
- package/package.json +32 -0
- package/templates/gsd-workflow.instructions.md +75 -0
- package/templates/planning-stubs/PROJECT.md +31 -0
- package/templates/planning-stubs/README.md +28 -0
- package/templates/planning-stubs/REQUIREMENTS.md +21 -0
- package/templates/planning-stubs/ROADMAP.md +43 -0
- package/templates/planning-stubs/STATE.md +33 -0
- package/templates/prompts/gsd-bootstrap-planning.prompt.md +52 -0
- package/templates/prompts/gsd-execute-plan.prompt.md +96 -0
- package/templates/prompts/gsd-plan-slice.prompt.md +105 -0
- package/templates/prompts/gsd-progress.prompt.md +50 -0
- package/templates/prompts/gsd-verify-work.prompt.md +60 -0
- package/templates/vendor/references/checkpoints.md +123 -0
- package/templates/vendor/templates/phase-prompt.md +242 -0
- package/templates/vendor/templates/summary.md +155 -0
|
@@ -0,0 +1,96 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "GSD: Execute a plan file (run verify, stop on checkpoints)"
|
|
3
|
+
argument-hint: "Provide the plan path (e.g., .planning/phases/03-auth/03-01-PLAN.md)"
|
|
4
|
+
agent: agent
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
Execute a GSD-style plan file.
|
|
8
|
+
|
|
9
|
+
## Instructions
|
|
10
|
+
|
|
11
|
+
1. If no plan path provided, ask which PLAN file to execute.
|
|
12
|
+
2. Read the PLAN file — it IS the executable prompt.
|
|
13
|
+
3. Execute tasks sequentially.
|
|
14
|
+
|
|
15
|
+
## For each task
|
|
16
|
+
|
|
17
|
+
### `type="auto"` tasks
|
|
18
|
+
|
|
19
|
+
1. Implement the changes described in `<action>`
|
|
20
|
+
2. Run the `<verify>` command(s)
|
|
21
|
+
3. If verification fails: stop and report the failure with proposed fixes
|
|
22
|
+
4. If verification passes: confirm `<done>` criteria met and continue
|
|
23
|
+
|
|
24
|
+
### `type="checkpoint:*"` tasks
|
|
25
|
+
|
|
26
|
+
1. **STOP immediately** (do not continue to next task)
|
|
27
|
+
2. Display a clear checkpoint message:
|
|
28
|
+
|
|
29
|
+
```
|
|
30
|
+
════════════════════════════════════════
|
|
31
|
+
CHECKPOINT: [Type]
|
|
32
|
+
════════════════════════════════════════
|
|
33
|
+
|
|
34
|
+
Task [X] of [Y]: [Task name]
|
|
35
|
+
|
|
36
|
+
[For human-verify]: What was built, how to verify
|
|
37
|
+
[For decision]: Options with pros/cons
|
|
38
|
+
|
|
39
|
+
Resume signal: [How to continue]
|
|
40
|
+
════════════════════════════════════════
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
3. Wait for my response before continuing
|
|
44
|
+
|
|
45
|
+
## After all tasks complete
|
|
46
|
+
|
|
47
|
+
1. Run the overall `<verification>` checks from the plan
|
|
48
|
+
2. Confirm all `<success_criteria>` are met
|
|
49
|
+
3. Create the SUMMARY file as specified in `<output>`
|
|
50
|
+
|
|
51
|
+
### SUMMARY format
|
|
52
|
+
|
|
53
|
+
Create `.planning/phases/NN-name/NN-PP-SUMMARY.md`:
|
|
54
|
+
|
|
55
|
+
```markdown
|
|
56
|
+
# Phase [X] Plan [Y]: [Name] Summary
|
|
57
|
+
|
|
58
|
+
**[One-liner describing what was accomplished]**
|
|
59
|
+
|
|
60
|
+
## Accomplishments
|
|
61
|
+
- [What was built]
|
|
62
|
+
|
|
63
|
+
## Files Created/Modified
|
|
64
|
+
- `path/to/file` - What it does
|
|
65
|
+
|
|
66
|
+
## Decisions Made
|
|
67
|
+
[Key decisions, or "None - followed plan as specified"]
|
|
68
|
+
|
|
69
|
+
## Issues Encountered
|
|
70
|
+
[Problems and resolutions, or "None"]
|
|
71
|
+
|
|
72
|
+
## Next Phase Readiness
|
|
73
|
+
[What's ready for next phase]
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
4. Update `.planning/STATE.md` with:
|
|
77
|
+
- Current position
|
|
78
|
+
- Any decisions made
|
|
79
|
+
- Next action
|
|
80
|
+
|
|
81
|
+
## Git commits
|
|
82
|
+
|
|
83
|
+
After verification passes, offer to create a commit:
|
|
84
|
+
- Show `git status` summary
|
|
85
|
+
- Propose a commit message following: `feat(NN-PP): [description]`
|
|
86
|
+
- Ask for explicit confirmation before committing
|
|
87
|
+
|
|
88
|
+
**Never commit without explicit "yes" from the user.**
|
|
89
|
+
|
|
90
|
+
## Output
|
|
91
|
+
|
|
92
|
+
Report:
|
|
93
|
+
- Tasks completed
|
|
94
|
+
- Verification results
|
|
95
|
+
- Summary path
|
|
96
|
+
- Any follow-ups or risks discovered
|
|
@@ -0,0 +1,105 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "GSD: Plan a small executable slice (2–3 tasks)"
|
|
3
|
+
argument-hint: "What slice are we planning? (e.g., 'Phase 03: User authentication')"
|
|
4
|
+
agent: agent
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
Plan the next small slice of work as a **GSD-style phase plan** (2–3 tasks max).
|
|
8
|
+
|
|
9
|
+
## Context to load
|
|
10
|
+
|
|
11
|
+
- Read `.planning/STATE.md` and `.planning/ROADMAP.md`.
|
|
12
|
+
- Identify the current phase directory under `.planning/phases/` (or ask me which phase).
|
|
13
|
+
- If a feature is mentioned, locate the relevant code and reference the specific files to be changed.
|
|
14
|
+
|
|
15
|
+
## Plan file location
|
|
16
|
+
|
|
17
|
+
Create a new plan file under:
|
|
18
|
+
- `.planning/phases/<NN-name>/` (create the directory if missing)
|
|
19
|
+
|
|
20
|
+
Name the file:
|
|
21
|
+
- `<NN>-<PP>-PLAN.md` (example: `03-01-PLAN.md` for Phase 3, Plan 1)
|
|
22
|
+
|
|
23
|
+
## Plan format
|
|
24
|
+
|
|
25
|
+
Follow the template in `.github/vendor/get-shit-done/templates/phase-prompt.md`.
|
|
26
|
+
|
|
27
|
+
### Required structure
|
|
28
|
+
|
|
29
|
+
```markdown
|
|
30
|
+
---
|
|
31
|
+
phase: NN-name
|
|
32
|
+
plan: PP
|
|
33
|
+
type: execute
|
|
34
|
+
wave: 1
|
|
35
|
+
depends_on: []
|
|
36
|
+
files_modified: []
|
|
37
|
+
autonomous: true
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
<objective>
|
|
41
|
+
[What this plan accomplishes]
|
|
42
|
+
|
|
43
|
+
Purpose: [Why this matters]
|
|
44
|
+
Output: [What artifacts will be created]
|
|
45
|
+
</objective>
|
|
46
|
+
|
|
47
|
+
<context>
|
|
48
|
+
@.planning/PROJECT.md
|
|
49
|
+
@.planning/ROADMAP.md
|
|
50
|
+
@.planning/STATE.md
|
|
51
|
+
[Relevant source files]
|
|
52
|
+
</context>
|
|
53
|
+
|
|
54
|
+
<tasks>
|
|
55
|
+
|
|
56
|
+
<task type="auto">
|
|
57
|
+
<name>Task 1: [Action-oriented name]</name>
|
|
58
|
+
<files>path/to/file.ext</files>
|
|
59
|
+
<action>[Specific implementation - what to do, how to do it, what to avoid and WHY]</action>
|
|
60
|
+
<verify>[Command or check to prove it worked]</verify>
|
|
61
|
+
<done>[Measurable acceptance criteria]</done>
|
|
62
|
+
</task>
|
|
63
|
+
|
|
64
|
+
<!-- Repeat for 2-3 tasks total -->
|
|
65
|
+
|
|
66
|
+
</tasks>
|
|
67
|
+
|
|
68
|
+
<verification>
|
|
69
|
+
Before declaring plan complete:
|
|
70
|
+
- [ ] [Specific test/build command]
|
|
71
|
+
- [ ] [Behavior verification]
|
|
72
|
+
</verification>
|
|
73
|
+
|
|
74
|
+
<success_criteria>
|
|
75
|
+
- All tasks completed
|
|
76
|
+
- All verification checks pass
|
|
77
|
+
- [Plan-specific criteria]
|
|
78
|
+
</success_criteria>
|
|
79
|
+
|
|
80
|
+
<output>
|
|
81
|
+
After completion, create `.planning/phases/NN-name/NN-PP-SUMMARY.md`
|
|
82
|
+
</output>
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
## Task types
|
|
86
|
+
|
|
87
|
+
| Type | Use for |
|
|
88
|
+
|------|---------|
|
|
89
|
+
| `auto` | Everything that can be done autonomously |
|
|
90
|
+
| `checkpoint:human-verify` | Visual/functional verification needed |
|
|
91
|
+
| `checkpoint:decision` | Implementation choice needed |
|
|
92
|
+
|
|
93
|
+
## Guidelines
|
|
94
|
+
|
|
95
|
+
- **2–3 tasks max** per plan
|
|
96
|
+
- Each task must have: `<files>`, `<action>`, `<verify>`, `<done>`
|
|
97
|
+
- `<verify>` should use actual commands for your stack (e.g., `npm test`, `dotnet build`)
|
|
98
|
+
- Prefer vertical slices (model + API + UI) over horizontal layers
|
|
99
|
+
|
|
100
|
+
## Output
|
|
101
|
+
|
|
102
|
+
Write the plan file, then reply with:
|
|
103
|
+
- Plan path
|
|
104
|
+
- Summary of what will be built
|
|
105
|
+
- Any open questions that block execution
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "GSD: Progress + next action (reads .planning/STATE.md)"
|
|
3
|
+
argument-hint: "What changed since last update? Any blockers?"
|
|
4
|
+
agent: ask
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
Read `.planning/STATE.md` and `.planning/ROADMAP.md` and give me a quick status update.
|
|
8
|
+
|
|
9
|
+
## Report
|
|
10
|
+
|
|
11
|
+
Tell me (concisely):
|
|
12
|
+
|
|
13
|
+
1. **Where we are now** (1–2 sentences)
|
|
14
|
+
- Current phase and plan
|
|
15
|
+
- What was last completed
|
|
16
|
+
|
|
17
|
+
2. **What's blocked** (if anything)
|
|
18
|
+
- Pending decisions
|
|
19
|
+
- External dependencies
|
|
20
|
+
- Technical blockers
|
|
21
|
+
|
|
22
|
+
3. **The next best action**
|
|
23
|
+
- Which prompt to run next
|
|
24
|
+
- What specific slice to work on
|
|
25
|
+
|
|
26
|
+
## If `.planning/` files are missing
|
|
27
|
+
|
|
28
|
+
Propose the minimal bootstrap steps:
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
.planning/ not initialized.
|
|
32
|
+
|
|
33
|
+
Run: gsd-bootstrap-planning.prompt.md
|
|
34
|
+
|
|
35
|
+
This will create:
|
|
36
|
+
- PROJECT.md
|
|
37
|
+
- REQUIREMENTS.md
|
|
38
|
+
- ROADMAP.md
|
|
39
|
+
- STATE.md
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
## Format
|
|
43
|
+
|
|
44
|
+
Keep it short — this is a quick status check, not a full report.
|
|
45
|
+
|
|
46
|
+
```
|
|
47
|
+
📍 Status: Phase 2 / Plan 1 complete
|
|
48
|
+
📋 Last: User auth endpoints implemented
|
|
49
|
+
⏭️ Next: Run gsd-plan-slice for "Phase 2 Plan 2: Protected routes"
|
|
50
|
+
```
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "GSD: Conversational UAT for a plan or slice"
|
|
3
|
+
argument-hint: "Which plan/slice should we verify? (optional plan path)"
|
|
4
|
+
agent: ask
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
Run a conversational verification session for the most recently executed plan (or a plan I specify).
|
|
8
|
+
|
|
9
|
+
## Instructions
|
|
10
|
+
|
|
11
|
+
1. If no plan specified, find the most recent `*-SUMMARY.md` in `.planning/phases/`
|
|
12
|
+
2. Read the SUMMARY and corresponding PLAN to understand what was built
|
|
13
|
+
3. Determine what "should happen" based on the plan + the changed files
|
|
14
|
+
|
|
15
|
+
## Verification flow
|
|
16
|
+
|
|
17
|
+
Test one thing at a time. For each test:
|
|
18
|
+
|
|
19
|
+
1. Tell me what to test and how
|
|
20
|
+
2. Ask: "Does it behave like this?"
|
|
21
|
+
3. Wait for my response:
|
|
22
|
+
- **yes/ok/pass** → record as PASS, continue to next test
|
|
23
|
+
- **describe an issue** → record as FAIL with details
|
|
24
|
+
|
|
25
|
+
## Record results
|
|
26
|
+
|
|
27
|
+
Create or update a UAT file: `.planning/uat/UAT-YYYYMMDD.md`
|
|
28
|
+
|
|
29
|
+
```markdown
|
|
30
|
+
# UAT Session - [Date]
|
|
31
|
+
|
|
32
|
+
**Plan(s) tested:** [plan IDs]
|
|
33
|
+
|
|
34
|
+
## Test Results
|
|
35
|
+
|
|
36
|
+
| # | Test | Result | Notes |
|
|
37
|
+
|---|------|--------|-------|
|
|
38
|
+
| 1 | [description] | PASS/FAIL | [details] |
|
|
39
|
+
| 2 | [description] | PASS/FAIL | [details] |
|
|
40
|
+
|
|
41
|
+
## Issues Found
|
|
42
|
+
|
|
43
|
+
### Issue 1: [Title]
|
|
44
|
+
- **Severity:** low/medium/high
|
|
45
|
+
- **Description:** [what's wrong]
|
|
46
|
+
- **Repro steps:** [how to reproduce]
|
|
47
|
+
|
|
48
|
+
## Summary
|
|
49
|
+
|
|
50
|
+
- **Passed:** X
|
|
51
|
+
- **Failed:** Y
|
|
52
|
+
- **Skipped:** Z
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
## Output
|
|
56
|
+
|
|
57
|
+
At the end, summarize:
|
|
58
|
+
- What passed
|
|
59
|
+
- What failed
|
|
60
|
+
- Suggested fixes (or propose a new plan to address issues)
|
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+
# Checkpoints Reference
|
|
2
|
+
|
|
3
|
+
Checkpoints are pause points where AI stops and asks for human input.
|
|
4
|
+
|
|
5
|
+
## Checkpoint Types
|
|
6
|
+
|
|
7
|
+
### checkpoint:human-verify
|
|
8
|
+
|
|
9
|
+
**Use for:** Visual/functional verification that requires human eyes.
|
|
10
|
+
|
|
11
|
+
```xml
|
|
12
|
+
<task type="checkpoint:human-verify" gate="blocking">
|
|
13
|
+
<what-built>[What was built]</what-built>
|
|
14
|
+
<how-to-verify>
|
|
15
|
+
1. Run: npm run dev
|
|
16
|
+
2. Visit: http://localhost:3000/login
|
|
17
|
+
3. Test: Enter credentials and submit
|
|
18
|
+
4. Confirm: Redirects to dashboard on success
|
|
19
|
+
</how-to-verify>
|
|
20
|
+
<resume-signal>Type "approved" or describe issues</resume-signal>
|
|
21
|
+
</task>
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
**AI behavior:**
|
|
25
|
+
1. Stop immediately when reaching this task
|
|
26
|
+
2. Display what was built and verification steps
|
|
27
|
+
3. Wait for user response
|
|
28
|
+
4. Continue if "approved", or address issues
|
|
29
|
+
|
|
30
|
+
### checkpoint:decision
|
|
31
|
+
|
|
32
|
+
**Use for:** Implementation choices that need human input.
|
|
33
|
+
|
|
34
|
+
```xml
|
|
35
|
+
<task type="checkpoint:decision" gate="blocking">
|
|
36
|
+
<decision>Choose authentication strategy</decision>
|
|
37
|
+
<context>Need to decide how to handle user sessions</context>
|
|
38
|
+
<options>
|
|
39
|
+
<option id="jwt">
|
|
40
|
+
<name>JWT Tokens</name>
|
|
41
|
+
<pros>Stateless, scalable, good for APIs</pros>
|
|
42
|
+
<cons>Can't revoke easily, larger payload</cons>
|
|
43
|
+
</option>
|
|
44
|
+
<option id="sessions">
|
|
45
|
+
<name>Server Sessions</name>
|
|
46
|
+
<pros>Easy revocation, smaller cookies</pros>
|
|
47
|
+
<cons>Requires session store, harder to scale</cons>
|
|
48
|
+
</option>
|
|
49
|
+
</options>
|
|
50
|
+
<resume-signal>Select: jwt or sessions</resume-signal>
|
|
51
|
+
</task>
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
**AI behavior:**
|
|
55
|
+
1. Stop and present options clearly
|
|
56
|
+
2. Wait for user to select
|
|
57
|
+
3. Record decision in STATE.md
|
|
58
|
+
4. Continue with chosen approach
|
|
59
|
+
|
|
60
|
+
### checkpoint:human-action
|
|
61
|
+
|
|
62
|
+
**Use for:** Truly unavoidable manual steps (rare).
|
|
63
|
+
|
|
64
|
+
```xml
|
|
65
|
+
<task type="checkpoint:human-action" gate="blocking">
|
|
66
|
+
<action>Complete OAuth app registration</action>
|
|
67
|
+
<context>Need client ID and secret from GitHub</context>
|
|
68
|
+
<instructions>
|
|
69
|
+
1. Go to GitHub > Settings > Developer settings > OAuth Apps
|
|
70
|
+
2. Click "New OAuth App"
|
|
71
|
+
3. Set callback URL to http://localhost:3000/auth/callback
|
|
72
|
+
4. Copy Client ID and Client Secret
|
|
73
|
+
5. Add to .env.local:
|
|
74
|
+
GITHUB_CLIENT_ID=xxx
|
|
75
|
+
GITHUB_CLIENT_SECRET=xxx
|
|
76
|
+
</instructions>
|
|
77
|
+
<verify>cat .env.local | grep GITHUB_CLIENT</verify>
|
|
78
|
+
<resume-signal>Type "done" when complete</resume-signal>
|
|
79
|
+
</task>
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
**AI behavior:**
|
|
83
|
+
1. Stop and show clear instructions
|
|
84
|
+
2. Wait for user to complete
|
|
85
|
+
3. Run verification if specified
|
|
86
|
+
4. Continue once confirmed
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
## When to Use Checkpoints
|
|
91
|
+
|
|
92
|
+
**DO use checkpoints for:**
|
|
93
|
+
- UI/UX verification (visual appearance)
|
|
94
|
+
- Deployment verification (site is live)
|
|
95
|
+
- Architecture decisions with trade-offs
|
|
96
|
+
- External service setup (OAuth, API keys)
|
|
97
|
+
|
|
98
|
+
**DON'T use checkpoints for:**
|
|
99
|
+
- Things that can be automated (tests, linting)
|
|
100
|
+
- Decisions that have obvious answers
|
|
101
|
+
- Steps AI can verify programmatically
|
|
102
|
+
|
|
103
|
+
---
|
|
104
|
+
|
|
105
|
+
## Display Format
|
|
106
|
+
|
|
107
|
+
When hitting a checkpoint, display clearly:
|
|
108
|
+
|
|
109
|
+
```
|
|
110
|
+
════════════════════════════════════════
|
|
111
|
+
CHECKPOINT: [Type]
|
|
112
|
+
════════════════════════════════════════
|
|
113
|
+
|
|
114
|
+
Task [X] of [Y]: [Task name]
|
|
115
|
+
|
|
116
|
+
[Checkpoint-specific content]
|
|
117
|
+
|
|
118
|
+
────────────────────────────────────────
|
|
119
|
+
→ YOUR ACTION: [Resume signal]
|
|
120
|
+
────────────────────────────────────────
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
Then **STOP** and wait for response.
|
|
@@ -0,0 +1,242 @@
|
|
|
1
|
+
# Phase Prompt Template
|
|
2
|
+
|
|
3
|
+
Template for `.planning/phases/XX-name/{phase}-{plan}-PLAN.md` — executable phase plans.
|
|
4
|
+
|
|
5
|
+
## File Template
|
|
6
|
+
|
|
7
|
+
```markdown
|
|
8
|
+
---
|
|
9
|
+
phase: XX-name
|
|
10
|
+
plan: NN
|
|
11
|
+
type: execute
|
|
12
|
+
wave: N # Execution wave (1, 2, 3...). Plans in same wave can run in parallel.
|
|
13
|
+
depends_on: [] # Plan IDs this plan requires (e.g., ["01-01"]).
|
|
14
|
+
files_modified: [] # Files this plan modifies.
|
|
15
|
+
autonomous: true # false if plan has checkpoints requiring user interaction
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
<objective>
|
|
19
|
+
[What this plan accomplishes]
|
|
20
|
+
|
|
21
|
+
Purpose: [Why this matters for the project]
|
|
22
|
+
Output: [What artifacts will be created]
|
|
23
|
+
</objective>
|
|
24
|
+
|
|
25
|
+
<context>
|
|
26
|
+
@.planning/PROJECT.md
|
|
27
|
+
@.planning/ROADMAP.md
|
|
28
|
+
@.planning/STATE.md
|
|
29
|
+
|
|
30
|
+
[Relevant source files:]
|
|
31
|
+
@src/path/to/relevant.ts
|
|
32
|
+
</context>
|
|
33
|
+
|
|
34
|
+
<tasks>
|
|
35
|
+
|
|
36
|
+
<task type="auto">
|
|
37
|
+
<name>Task 1: [Action-oriented name]</name>
|
|
38
|
+
<files>path/to/file.ext, another/file.ext</files>
|
|
39
|
+
<action>[Specific implementation - what to do, how to do it, what to avoid and WHY]</action>
|
|
40
|
+
<verify>[Command or check to prove it worked]</verify>
|
|
41
|
+
<done>[Measurable acceptance criteria]</done>
|
|
42
|
+
</task>
|
|
43
|
+
|
|
44
|
+
<task type="auto">
|
|
45
|
+
<name>Task 2: [Action-oriented name]</name>
|
|
46
|
+
<files>path/to/file.ext</files>
|
|
47
|
+
<action>[Specific implementation]</action>
|
|
48
|
+
<verify>[Command or check]</verify>
|
|
49
|
+
<done>[Acceptance criteria]</done>
|
|
50
|
+
</task>
|
|
51
|
+
|
|
52
|
+
<!-- Checkpoint example (use sparingly) -->
|
|
53
|
+
<task type="checkpoint:human-verify" gate="blocking">
|
|
54
|
+
<what-built>[What was built that needs verification]</what-built>
|
|
55
|
+
<how-to-verify>
|
|
56
|
+
1. Run: [command to start dev server/app]
|
|
57
|
+
2. Visit: [URL to check]
|
|
58
|
+
3. Test: [Specific interactions]
|
|
59
|
+
4. Confirm: [Expected behaviors]
|
|
60
|
+
</how-to-verify>
|
|
61
|
+
<resume-signal>Type "approved" to continue, or describe issues to fix</resume-signal>
|
|
62
|
+
</task>
|
|
63
|
+
|
|
64
|
+
</tasks>
|
|
65
|
+
|
|
66
|
+
<verification>
|
|
67
|
+
Before declaring plan complete:
|
|
68
|
+
- [ ] [Specific test command]
|
|
69
|
+
- [ ] [Build/type check passes]
|
|
70
|
+
- [ ] [Behavior verification]
|
|
71
|
+
</verification>
|
|
72
|
+
|
|
73
|
+
<success_criteria>
|
|
74
|
+
- All tasks completed
|
|
75
|
+
- All verification checks pass
|
|
76
|
+
- No errors or warnings introduced
|
|
77
|
+
- [Plan-specific criteria]
|
|
78
|
+
</success_criteria>
|
|
79
|
+
|
|
80
|
+
<output>
|
|
81
|
+
After completion, create `.planning/phases/XX-name/{phase}-{plan}-SUMMARY.md`
|
|
82
|
+
</output>
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## Frontmatter Fields
|
|
88
|
+
|
|
89
|
+
| Field | Required | Purpose |
|
|
90
|
+
|-------|----------|---------|
|
|
91
|
+
| `phase` | Yes | Phase identifier (e.g., `01-foundation`) |
|
|
92
|
+
| `plan` | Yes | Plan number within phase (e.g., `01`, `02`) |
|
|
93
|
+
| `type` | Yes | Always `execute` for standard plans |
|
|
94
|
+
| `wave` | Yes | Execution wave number (1, 2, 3...) |
|
|
95
|
+
| `depends_on` | Yes | Array of plan IDs this plan requires |
|
|
96
|
+
| `files_modified` | Yes | Files this plan touches |
|
|
97
|
+
| `autonomous` | Yes | `true` if no checkpoints, `false` if has checkpoints |
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
## Task Types
|
|
102
|
+
|
|
103
|
+
| Type | Use For | Behavior |
|
|
104
|
+
|------|---------|----------|
|
|
105
|
+
| `auto` | Everything that can be done independently | Execute, verify, continue |
|
|
106
|
+
| `checkpoint:human-verify` | Visual/functional verification | Stop, ask user, wait for approval |
|
|
107
|
+
| `checkpoint:decision` | Implementation choices | Stop, present options, wait for choice |
|
|
108
|
+
| `checkpoint:human-action` | Truly unavoidable manual steps (rare) | Stop, instruct user, wait for completion |
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## Scope Guidelines
|
|
113
|
+
|
|
114
|
+
**Plan sizing:**
|
|
115
|
+
- 2–3 tasks per plan
|
|
116
|
+
- ~50% context usage maximum
|
|
117
|
+
- Complex phases: Multiple focused plans, not one large plan
|
|
118
|
+
|
|
119
|
+
**When to split:**
|
|
120
|
+
- Different subsystems (auth vs API vs UI)
|
|
121
|
+
- More than 3 tasks
|
|
122
|
+
- Risk of context overflow
|
|
123
|
+
|
|
124
|
+
**Prefer vertical slices:**
|
|
125
|
+
```
|
|
126
|
+
PREFER: Plan 01 = User (model + API + UI)
|
|
127
|
+
Plan 02 = Product (model + API + UI)
|
|
128
|
+
|
|
129
|
+
AVOID: Plan 01 = All models
|
|
130
|
+
Plan 02 = All APIs
|
|
131
|
+
Plan 03 = All UIs
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
---
|
|
135
|
+
|
|
136
|
+
## Verification Examples by Stack
|
|
137
|
+
|
|
138
|
+
**Node.js / TypeScript:**
|
|
139
|
+
```xml
|
|
140
|
+
<verify>npm run build && npm test</verify>
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
**Python:**
|
|
144
|
+
```xml
|
|
145
|
+
<verify>pytest tests/ && mypy src/</verify>
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
**.NET:**
|
|
149
|
+
```xml
|
|
150
|
+
<verify>dotnet build && dotnet test</verify>
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
**Go:**
|
|
154
|
+
```xml
|
|
155
|
+
<verify>go build ./... && go test ./...</verify>
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
**Rust:**
|
|
159
|
+
```xml
|
|
160
|
+
<verify>cargo build && cargo test</verify>
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
---
|
|
164
|
+
|
|
165
|
+
## Example Plan
|
|
166
|
+
|
|
167
|
+
```markdown
|
|
168
|
+
---
|
|
169
|
+
phase: 02-auth
|
|
170
|
+
plan: 01
|
|
171
|
+
type: execute
|
|
172
|
+
wave: 1
|
|
173
|
+
depends_on: []
|
|
174
|
+
files_modified: [src/auth/login.ts, src/auth/login.test.ts]
|
|
175
|
+
autonomous: true
|
|
176
|
+
---
|
|
177
|
+
|
|
178
|
+
<objective>
|
|
179
|
+
Implement user login endpoint with JWT tokens.
|
|
180
|
+
|
|
181
|
+
Purpose: Enable authenticated access to protected routes.
|
|
182
|
+
Output: POST /auth/login endpoint returning JWT on success.
|
|
183
|
+
</objective>
|
|
184
|
+
|
|
185
|
+
<context>
|
|
186
|
+
@.planning/PROJECT.md
|
|
187
|
+
@.planning/ROADMAP.md
|
|
188
|
+
@.planning/STATE.md
|
|
189
|
+
@src/db/schema.ts
|
|
190
|
+
</context>
|
|
191
|
+
|
|
192
|
+
<tasks>
|
|
193
|
+
|
|
194
|
+
<task type="auto">
|
|
195
|
+
<name>Task 1: Create login endpoint</name>
|
|
196
|
+
<files>src/auth/login.ts</files>
|
|
197
|
+
<action>
|
|
198
|
+
Create POST /auth/login that:
|
|
199
|
+
- Accepts { email, password } in body
|
|
200
|
+
- Validates against users table
|
|
201
|
+
- Returns JWT token on success
|
|
202
|
+
- Returns 401 on invalid credentials
|
|
203
|
+
|
|
204
|
+
Use jose library for JWT (not jsonwebtoken - ESM issues).
|
|
205
|
+
Token should expire in 1 hour.
|
|
206
|
+
</action>
|
|
207
|
+
<verify>curl -X POST localhost:3000/auth/login -d '{"email":"test@example.com","password":"test"}' returns 200 or 401</verify>
|
|
208
|
+
<done>Login endpoint validates credentials and returns JWT</done>
|
|
209
|
+
</task>
|
|
210
|
+
|
|
211
|
+
<task type="auto">
|
|
212
|
+
<name>Task 2: Add login tests</name>
|
|
213
|
+
<files>src/auth/login.test.ts</files>
|
|
214
|
+
<action>
|
|
215
|
+
Write tests for:
|
|
216
|
+
- Valid credentials return 200 + token
|
|
217
|
+
- Invalid password returns 401
|
|
218
|
+
- Unknown email returns 401
|
|
219
|
+
- Missing fields return 400
|
|
220
|
+
</action>
|
|
221
|
+
<verify>npm test -- --grep "login"</verify>
|
|
222
|
+
<done>All login tests pass</done>
|
|
223
|
+
</task>
|
|
224
|
+
|
|
225
|
+
</tasks>
|
|
226
|
+
|
|
227
|
+
<verification>
|
|
228
|
+
- [ ] npm run build succeeds
|
|
229
|
+
- [ ] npm test passes
|
|
230
|
+
- [ ] Manual curl test works
|
|
231
|
+
</verification>
|
|
232
|
+
|
|
233
|
+
<success_criteria>
|
|
234
|
+
- Login endpoint works with valid credentials
|
|
235
|
+
- Invalid credentials properly rejected
|
|
236
|
+
- Tests cover main scenarios
|
|
237
|
+
</success_criteria>
|
|
238
|
+
|
|
239
|
+
<output>
|
|
240
|
+
After completion, create `.planning/phases/02-auth/02-01-SUMMARY.md`
|
|
241
|
+
</output>
|
|
242
|
+
```
|