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.
@@ -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
+ ```