get-shit-done-cc 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 +192 -0
- package/bin/install.js +53 -0
- package/commands/gsd/add-phase.md +201 -0
- package/commands/gsd/complete-milestone.md +105 -0
- package/commands/gsd/discuss-milestone.md +45 -0
- package/commands/gsd/discuss-phase.md +47 -0
- package/commands/gsd/execute-plan.md +108 -0
- package/commands/gsd/help.md +252 -0
- package/commands/gsd/insert-phase.md +218 -0
- package/commands/gsd/list-phase-assumptions.md +49 -0
- package/commands/gsd/new-milestone.md +58 -0
- package/commands/gsd/new-project.md +177 -0
- package/commands/gsd/pause-work.md +123 -0
- package/commands/gsd/plan-phase.md +60 -0
- package/commands/gsd/progress.md +182 -0
- package/commands/gsd/resume-work.md +50 -0
- package/get-shit-done/references/checkpoints.md +594 -0
- package/get-shit-done/references/cli-automation.md +527 -0
- package/get-shit-done/references/git-integration.md +126 -0
- package/get-shit-done/references/plan-format.md +397 -0
- package/get-shit-done/references/principles.md +97 -0
- package/get-shit-done/references/questioning.md +138 -0
- package/get-shit-done/references/research-pitfalls.md +215 -0
- package/get-shit-done/references/scope-estimation.md +451 -0
- package/get-shit-done/templates/config.json +17 -0
- package/get-shit-done/templates/context.md +385 -0
- package/get-shit-done/templates/continue-here.md +78 -0
- package/get-shit-done/templates/issues.md +32 -0
- package/get-shit-done/templates/milestone-archive.md +123 -0
- package/get-shit-done/templates/milestone.md +115 -0
- package/get-shit-done/templates/phase-prompt.md +290 -0
- package/get-shit-done/templates/project.md +207 -0
- package/get-shit-done/templates/research-prompt.md +133 -0
- package/get-shit-done/templates/roadmap.md +196 -0
- package/get-shit-done/templates/state.md +226 -0
- package/get-shit-done/templates/summary.md +200 -0
- package/get-shit-done/workflows/complete-milestone.md +490 -0
- package/get-shit-done/workflows/create-milestone.md +379 -0
- package/get-shit-done/workflows/create-roadmap.md +443 -0
- package/get-shit-done/workflows/discuss-milestone.md +144 -0
- package/get-shit-done/workflows/discuss-phase.md +254 -0
- package/get-shit-done/workflows/execute-phase.md +1261 -0
- package/get-shit-done/workflows/list-phase-assumptions.md +178 -0
- package/get-shit-done/workflows/plan-phase.md +783 -0
- package/get-shit-done/workflows/research-phase.md +293 -0
- package/get-shit-done/workflows/resume-project.md +248 -0
- package/get-shit-done/workflows/transition.md +488 -0
- package/package.json +30 -0
|
@@ -0,0 +1,594 @@
|
|
|
1
|
+
<overview>
|
|
2
|
+
Plans execute autonomously. Checkpoints formalize the interaction points where human verification or decisions are needed.
|
|
3
|
+
|
|
4
|
+
**Core principle:** Claude automates everything with CLI/API. Checkpoints are for verification and decisions, not manual work.
|
|
5
|
+
</overview>
|
|
6
|
+
|
|
7
|
+
<checkpoint_types>
|
|
8
|
+
|
|
9
|
+
<type name="human-verify">
|
|
10
|
+
## checkpoint:human-verify (Most Common)
|
|
11
|
+
|
|
12
|
+
**When:** Claude completed automated work, human confirms it works correctly.
|
|
13
|
+
|
|
14
|
+
**Use for:**
|
|
15
|
+
- Visual UI checks (layout, styling, responsiveness)
|
|
16
|
+
- Interactive flows (click through wizard, test user flows)
|
|
17
|
+
- Functional verification (feature works as expected)
|
|
18
|
+
- Audio/video playback quality
|
|
19
|
+
- Animation smoothness
|
|
20
|
+
- Accessibility testing
|
|
21
|
+
|
|
22
|
+
**Structure:**
|
|
23
|
+
```xml
|
|
24
|
+
<task type="checkpoint:human-verify" gate="blocking">
|
|
25
|
+
<what-built>[What Claude automated and deployed/built]</what-built>
|
|
26
|
+
<how-to-verify>
|
|
27
|
+
[Exact steps to test - URLs, commands, expected behavior]
|
|
28
|
+
</how-to-verify>
|
|
29
|
+
<resume-signal>[How to continue - "approved", "yes", or describe issues]</resume-signal>
|
|
30
|
+
</task>
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
**Key elements:**
|
|
34
|
+
- `<what-built>`: What Claude automated (deployed, built, configured)
|
|
35
|
+
- `<how-to-verify>`: Exact steps to confirm it works (numbered, specific)
|
|
36
|
+
- `<resume-signal>`: Clear indication of how to continue
|
|
37
|
+
|
|
38
|
+
**Example: Vercel Deployment**
|
|
39
|
+
```xml
|
|
40
|
+
<task type="auto">
|
|
41
|
+
<name>Deploy to Vercel</name>
|
|
42
|
+
<files>.vercel/, vercel.json</files>
|
|
43
|
+
<action>Run `vercel --yes` to create project and deploy. Capture deployment URL from output.</action>
|
|
44
|
+
<verify>vercel ls shows deployment, curl {url} returns 200</verify>
|
|
45
|
+
<done>App deployed, URL captured</done>
|
|
46
|
+
</task>
|
|
47
|
+
|
|
48
|
+
<task type="checkpoint:human-verify" gate="blocking">
|
|
49
|
+
<what-built>Deployed to Vercel at https://myapp-abc123.vercel.app</what-built>
|
|
50
|
+
<how-to-verify>
|
|
51
|
+
Visit https://myapp-abc123.vercel.app and confirm:
|
|
52
|
+
- Homepage loads without errors
|
|
53
|
+
- Login form is visible
|
|
54
|
+
- No console errors in browser DevTools
|
|
55
|
+
</how-to-verify>
|
|
56
|
+
<resume-signal>Type "approved" to continue, or describe issues to fix</resume-signal>
|
|
57
|
+
</task>
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
**Example: UI Component**
|
|
61
|
+
```xml
|
|
62
|
+
<task type="auto">
|
|
63
|
+
<name>Build responsive dashboard layout</name>
|
|
64
|
+
<files>src/components/Dashboard.tsx, src/app/dashboard/page.tsx</files>
|
|
65
|
+
<action>Create dashboard with sidebar, header, and content area. Use Tailwind responsive classes for mobile.</action>
|
|
66
|
+
<verify>npm run build succeeds, no TypeScript errors</verify>
|
|
67
|
+
<done>Dashboard component builds without errors</done>
|
|
68
|
+
</task>
|
|
69
|
+
|
|
70
|
+
<task type="checkpoint:human-verify" gate="blocking">
|
|
71
|
+
<what-built>Responsive dashboard layout at /dashboard</what-built>
|
|
72
|
+
<how-to-verify>
|
|
73
|
+
1. Run: npm run dev
|
|
74
|
+
2. Visit: http://localhost:3000/dashboard
|
|
75
|
+
3. Desktop (>1024px): Verify sidebar left, content right, header top
|
|
76
|
+
4. Tablet (768px): Verify sidebar collapses to hamburger
|
|
77
|
+
5. Mobile (375px): Verify single column, bottom nav
|
|
78
|
+
6. Check: No layout shift, no horizontal scroll
|
|
79
|
+
</how-to-verify>
|
|
80
|
+
<resume-signal>Type "approved" or describe layout issues</resume-signal>
|
|
81
|
+
</task>
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
**Example: Xcode Build**
|
|
85
|
+
```xml
|
|
86
|
+
<task type="auto">
|
|
87
|
+
<name>Build macOS app with Xcode</name>
|
|
88
|
+
<files>App.xcodeproj, Sources/</files>
|
|
89
|
+
<action>Run `xcodebuild -project App.xcodeproj -scheme App build`. Check for compilation errors in output.</action>
|
|
90
|
+
<verify>Build output contains "BUILD SUCCEEDED", no errors</verify>
|
|
91
|
+
<done>App builds successfully</done>
|
|
92
|
+
</task>
|
|
93
|
+
|
|
94
|
+
<task type="checkpoint:human-verify" gate="blocking">
|
|
95
|
+
<what-built>Built macOS app at DerivedData/Build/Products/Debug/App.app</what-built>
|
|
96
|
+
<how-to-verify>
|
|
97
|
+
Open App.app and test:
|
|
98
|
+
- App launches without crashes
|
|
99
|
+
- Menu bar icon appears
|
|
100
|
+
- Preferences window opens correctly
|
|
101
|
+
- No visual glitches or layout issues
|
|
102
|
+
</how-to-verify>
|
|
103
|
+
<resume-signal>Type "approved" or describe issues</resume-signal>
|
|
104
|
+
</task>
|
|
105
|
+
```
|
|
106
|
+
</type>
|
|
107
|
+
|
|
108
|
+
<type name="decision">
|
|
109
|
+
## checkpoint:decision
|
|
110
|
+
|
|
111
|
+
**When:** Human must make choice that affects implementation direction.
|
|
112
|
+
|
|
113
|
+
**Use for:**
|
|
114
|
+
- Technology selection (which auth provider, which database)
|
|
115
|
+
- Architecture decisions (monorepo vs separate repos)
|
|
116
|
+
- Design choices (color scheme, layout approach)
|
|
117
|
+
- Feature prioritization (which variant to build)
|
|
118
|
+
- Data model decisions (schema structure)
|
|
119
|
+
|
|
120
|
+
**Structure:**
|
|
121
|
+
```xml
|
|
122
|
+
<task type="checkpoint:decision" gate="blocking">
|
|
123
|
+
<decision>[What's being decided]</decision>
|
|
124
|
+
<context>[Why this decision matters]</context>
|
|
125
|
+
<options>
|
|
126
|
+
<option id="option-a">
|
|
127
|
+
<name>[Option name]</name>
|
|
128
|
+
<pros>[Benefits]</pros>
|
|
129
|
+
<cons>[Tradeoffs]</cons>
|
|
130
|
+
</option>
|
|
131
|
+
<option id="option-b">
|
|
132
|
+
<name>[Option name]</name>
|
|
133
|
+
<pros>[Benefits]</pros>
|
|
134
|
+
<cons>[Tradeoffs]</cons>
|
|
135
|
+
</option>
|
|
136
|
+
</options>
|
|
137
|
+
<resume-signal>[How to indicate choice]</resume-signal>
|
|
138
|
+
</task>
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
**Key elements:**
|
|
142
|
+
- `<decision>`: What's being decided
|
|
143
|
+
- `<context>`: Why this matters
|
|
144
|
+
- `<options>`: Each option with balanced pros/cons (not prescriptive)
|
|
145
|
+
- `<resume-signal>`: How to indicate choice
|
|
146
|
+
|
|
147
|
+
**Example: Auth Provider Selection**
|
|
148
|
+
```xml
|
|
149
|
+
<task type="checkpoint:decision" gate="blocking">
|
|
150
|
+
<decision>Select authentication provider</decision>
|
|
151
|
+
<context>
|
|
152
|
+
Need user authentication for the app. Three solid options with different tradeoffs.
|
|
153
|
+
</context>
|
|
154
|
+
<options>
|
|
155
|
+
<option id="supabase">
|
|
156
|
+
<name>Supabase Auth</name>
|
|
157
|
+
<pros>Built-in with Supabase DB we're using, generous free tier, row-level security integration</pros>
|
|
158
|
+
<cons>Less customizable UI, tied to Supabase ecosystem</cons>
|
|
159
|
+
</option>
|
|
160
|
+
<option id="clerk">
|
|
161
|
+
<name>Clerk</name>
|
|
162
|
+
<pros>Beautiful pre-built UI, best developer experience, excellent docs</pros>
|
|
163
|
+
<cons>Paid after 10k MAU, vendor lock-in</cons>
|
|
164
|
+
</option>
|
|
165
|
+
<option id="nextauth">
|
|
166
|
+
<name>NextAuth.js</name>
|
|
167
|
+
<pros>Free, self-hosted, maximum control, widely adopted</pros>
|
|
168
|
+
<cons>More setup work, you manage security updates, UI is DIY</cons>
|
|
169
|
+
</option>
|
|
170
|
+
</options>
|
|
171
|
+
<resume-signal>Select: supabase, clerk, or nextauth</resume-signal>
|
|
172
|
+
</task>
|
|
173
|
+
```
|
|
174
|
+
</type>
|
|
175
|
+
|
|
176
|
+
<type name="human-action">
|
|
177
|
+
## checkpoint:human-action (Rare)
|
|
178
|
+
|
|
179
|
+
**When:** Action has NO CLI/API and requires human-only interaction, OR Claude hit an authentication gate during automation.
|
|
180
|
+
|
|
181
|
+
**Use ONLY for:**
|
|
182
|
+
- **Authentication gates** - Claude tried to use CLI/API but needs credentials to continue (this is NOT a failure)
|
|
183
|
+
- Email verification links (account creation requires clicking email)
|
|
184
|
+
- SMS 2FA codes (phone verification)
|
|
185
|
+
- Manual account approvals (platform requires human review before API access)
|
|
186
|
+
- Credit card 3D Secure flows (web-based payment authorization)
|
|
187
|
+
- OAuth app approvals (some platforms require web-based approval)
|
|
188
|
+
|
|
189
|
+
**Do NOT use for pre-planned manual work:**
|
|
190
|
+
- Manually deploying to Vercel (use `vercel` CLI - auth gate if needed)
|
|
191
|
+
- Manually creating Stripe webhooks (use Stripe API - auth gate if needed)
|
|
192
|
+
- Manually creating databases (use provider CLI - auth gate if needed)
|
|
193
|
+
- Running builds/tests manually (use Bash tool)
|
|
194
|
+
- Creating files manually (use Write tool)
|
|
195
|
+
|
|
196
|
+
**Structure:**
|
|
197
|
+
```xml
|
|
198
|
+
<task type="checkpoint:human-action" gate="blocking">
|
|
199
|
+
<action>[What human must do - Claude already did everything automatable]</action>
|
|
200
|
+
<instructions>
|
|
201
|
+
[What Claude already automated]
|
|
202
|
+
[The ONE thing requiring human action]
|
|
203
|
+
</instructions>
|
|
204
|
+
<verification>[What Claude can check afterward]</verification>
|
|
205
|
+
<resume-signal>[How to continue]</resume-signal>
|
|
206
|
+
</task>
|
|
207
|
+
```
|
|
208
|
+
|
|
209
|
+
**Key principle:** Claude automates EVERYTHING possible first, only asks human for the truly unavoidable manual step.
|
|
210
|
+
|
|
211
|
+
**Example: Email Verification**
|
|
212
|
+
```xml
|
|
213
|
+
<task type="auto">
|
|
214
|
+
<name>Create SendGrid account via API</name>
|
|
215
|
+
<action>Use SendGrid API to create subuser account with provided email. Request verification email.</action>
|
|
216
|
+
<verify>API returns 201, account created</verify>
|
|
217
|
+
<done>Account created, verification email sent</done>
|
|
218
|
+
</task>
|
|
219
|
+
|
|
220
|
+
<task type="checkpoint:human-action" gate="blocking">
|
|
221
|
+
<action>Complete email verification for SendGrid account</action>
|
|
222
|
+
<instructions>
|
|
223
|
+
I created the account and requested verification email.
|
|
224
|
+
Check your inbox for SendGrid verification link and click it.
|
|
225
|
+
</instructions>
|
|
226
|
+
<verification>SendGrid API key works: curl test succeeds</verification>
|
|
227
|
+
<resume-signal>Type "done" when email verified</resume-signal>
|
|
228
|
+
</task>
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
**Example: Credit Card 3D Secure**
|
|
232
|
+
```xml
|
|
233
|
+
<task type="auto">
|
|
234
|
+
<name>Create Stripe payment intent</name>
|
|
235
|
+
<action>Use Stripe API to create payment intent for $99. Generate checkout URL.</action>
|
|
236
|
+
<verify>Stripe API returns payment intent ID and URL</verify>
|
|
237
|
+
<done>Payment intent created</done>
|
|
238
|
+
</task>
|
|
239
|
+
|
|
240
|
+
<task type="checkpoint:human-action" gate="blocking">
|
|
241
|
+
<action>Complete 3D Secure authentication</action>
|
|
242
|
+
<instructions>
|
|
243
|
+
I created the payment intent: https://checkout.stripe.com/pay/cs_test_abc123
|
|
244
|
+
Visit that URL and complete the 3D Secure verification flow with your test card.
|
|
245
|
+
</instructions>
|
|
246
|
+
<verification>Stripe webhook receives payment_intent.succeeded event</verification>
|
|
247
|
+
<resume-signal>Type "done" when payment completes</resume-signal>
|
|
248
|
+
</task>
|
|
249
|
+
```
|
|
250
|
+
|
|
251
|
+
**Example: Authentication Gate (Dynamic Checkpoint)**
|
|
252
|
+
```xml
|
|
253
|
+
<task type="auto">
|
|
254
|
+
<name>Deploy to Vercel</name>
|
|
255
|
+
<files>.vercel/, vercel.json</files>
|
|
256
|
+
<action>Run `vercel --yes` to deploy</action>
|
|
257
|
+
<verify>vercel ls shows deployment, curl returns 200</verify>
|
|
258
|
+
</task>
|
|
259
|
+
|
|
260
|
+
<!-- If vercel returns "Error: Not authenticated", Claude creates checkpoint on the fly -->
|
|
261
|
+
|
|
262
|
+
<task type="checkpoint:human-action" gate="blocking">
|
|
263
|
+
<action>Authenticate Vercel CLI so I can continue deployment</action>
|
|
264
|
+
<instructions>
|
|
265
|
+
I tried to deploy but got authentication error.
|
|
266
|
+
Run: vercel login
|
|
267
|
+
This will open your browser - complete the authentication flow.
|
|
268
|
+
</instructions>
|
|
269
|
+
<verification>vercel whoami returns your account email</verification>
|
|
270
|
+
<resume-signal>Type "done" when authenticated</resume-signal>
|
|
271
|
+
</task>
|
|
272
|
+
|
|
273
|
+
<!-- After authentication, Claude retries the deployment -->
|
|
274
|
+
|
|
275
|
+
<task type="auto">
|
|
276
|
+
<name>Retry Vercel deployment</name>
|
|
277
|
+
<action>Run `vercel --yes` (now authenticated)</action>
|
|
278
|
+
<verify>vercel ls shows deployment, curl returns 200</verify>
|
|
279
|
+
</task>
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
**Key distinction:** Authentication gates are created dynamically when Claude encounters auth errors during automation. They're NOT pre-planned - Claude tries to automate first, only asks for credentials when blocked.
|
|
283
|
+
</type>
|
|
284
|
+
</checkpoint_types>
|
|
285
|
+
|
|
286
|
+
<execution_protocol>
|
|
287
|
+
|
|
288
|
+
When Claude encounters `type="checkpoint:*"`:
|
|
289
|
+
|
|
290
|
+
1. **Stop immediately** - do not proceed to next task
|
|
291
|
+
2. **Display checkpoint clearly:**
|
|
292
|
+
|
|
293
|
+
```
|
|
294
|
+
════════════════════════════════════════
|
|
295
|
+
CHECKPOINT: [Type]
|
|
296
|
+
════════════════════════════════════════
|
|
297
|
+
|
|
298
|
+
Task [X] of [Y]: [Name]
|
|
299
|
+
|
|
300
|
+
[Display checkpoint-specific content]
|
|
301
|
+
|
|
302
|
+
[Resume signal instruction]
|
|
303
|
+
════════════════════════════════════════
|
|
304
|
+
```
|
|
305
|
+
|
|
306
|
+
3. **Wait for user response** - do not hallucinate completion
|
|
307
|
+
4. **Verify if possible** - check files, run tests, whatever is specified
|
|
308
|
+
5. **Resume execution** - continue to next task only after confirmation
|
|
309
|
+
|
|
310
|
+
**For checkpoint:human-verify:**
|
|
311
|
+
```
|
|
312
|
+
════════════════════════════════════════
|
|
313
|
+
CHECKPOINT: Verification Required
|
|
314
|
+
════════════════════════════════════════
|
|
315
|
+
|
|
316
|
+
Task 5 of 8: Responsive dashboard layout
|
|
317
|
+
|
|
318
|
+
I built: Responsive dashboard at /dashboard
|
|
319
|
+
|
|
320
|
+
How to verify:
|
|
321
|
+
1. Run: npm run dev
|
|
322
|
+
2. Visit: http://localhost:3000/dashboard
|
|
323
|
+
3. Test: Resize browser window to mobile/tablet/desktop
|
|
324
|
+
4. Confirm: No layout shift, proper responsive behavior
|
|
325
|
+
|
|
326
|
+
Type "approved" to continue, or describe issues.
|
|
327
|
+
════════════════════════════════════════
|
|
328
|
+
```
|
|
329
|
+
|
|
330
|
+
**For checkpoint:decision:**
|
|
331
|
+
```
|
|
332
|
+
════════════════════════════════════════
|
|
333
|
+
CHECKPOINT: Decision Required
|
|
334
|
+
════════════════════════════════════════
|
|
335
|
+
|
|
336
|
+
Task 2 of 6: Select authentication provider
|
|
337
|
+
|
|
338
|
+
Decision: Which auth provider should we use?
|
|
339
|
+
|
|
340
|
+
Context: Need user authentication. Three options with different tradeoffs.
|
|
341
|
+
|
|
342
|
+
Options:
|
|
343
|
+
1. supabase - Built-in with our DB, free tier
|
|
344
|
+
2. clerk - Best DX, paid after 10k users
|
|
345
|
+
3. nextauth - Self-hosted, maximum control
|
|
346
|
+
|
|
347
|
+
Select: supabase, clerk, or nextauth
|
|
348
|
+
════════════════════════════════════════
|
|
349
|
+
```
|
|
350
|
+
</execution_protocol>
|
|
351
|
+
|
|
352
|
+
<writing_guidelines>
|
|
353
|
+
|
|
354
|
+
**DO:**
|
|
355
|
+
- Automate everything with CLI/API before checkpoint
|
|
356
|
+
- Be specific: "Visit https://myapp.vercel.app" not "check deployment"
|
|
357
|
+
- Number verification steps: easier to follow
|
|
358
|
+
- State expected outcomes: "You should see X"
|
|
359
|
+
- Provide context: why this checkpoint exists
|
|
360
|
+
- Make verification executable: clear, testable steps
|
|
361
|
+
|
|
362
|
+
**DON'T:**
|
|
363
|
+
- Ask human to do work Claude can automate (deploy, create resources, run builds)
|
|
364
|
+
- Assume knowledge: "Configure the usual settings" ❌
|
|
365
|
+
- Skip steps: "Set up database" ❌ (too vague)
|
|
366
|
+
- Mix multiple verifications in one checkpoint (split them)
|
|
367
|
+
- Make verification impossible (Claude can't check visual appearance without user confirmation)
|
|
368
|
+
</writing_guidelines>
|
|
369
|
+
|
|
370
|
+
<usage_guidelines>
|
|
371
|
+
|
|
372
|
+
**Use checkpoint:human-verify for:**
|
|
373
|
+
- Visual verification (UI, layouts, animations)
|
|
374
|
+
- Interactive testing (click flows, user journeys)
|
|
375
|
+
- Quality checks (audio/video playback, animation smoothness)
|
|
376
|
+
- Confirming deployed apps are accessible
|
|
377
|
+
|
|
378
|
+
**Use checkpoint:decision for:**
|
|
379
|
+
- Technology selection (auth providers, databases, frameworks)
|
|
380
|
+
- Architecture choices (monorepo, deployment strategy)
|
|
381
|
+
- Design decisions (color schemes, layout approaches)
|
|
382
|
+
- Feature prioritization
|
|
383
|
+
|
|
384
|
+
**Use checkpoint:human-action for:**
|
|
385
|
+
- Email verification links (no API)
|
|
386
|
+
- SMS 2FA codes (no API)
|
|
387
|
+
- Manual approvals with no automation
|
|
388
|
+
- 3D Secure payment flows
|
|
389
|
+
|
|
390
|
+
**Don't use checkpoints for:**
|
|
391
|
+
- Things Claude can verify programmatically (tests pass, build succeeds)
|
|
392
|
+
- File operations (Claude can read files to verify)
|
|
393
|
+
- Code correctness (use tests and static analysis)
|
|
394
|
+
- Anything automatable via CLI/API
|
|
395
|
+
</usage_guidelines>
|
|
396
|
+
|
|
397
|
+
<placement_guidelines>
|
|
398
|
+
|
|
399
|
+
Place checkpoints:
|
|
400
|
+
- **After automation completes** - not before Claude does the work
|
|
401
|
+
- **After UI buildout** - before declaring phase complete
|
|
402
|
+
- **Before dependent work** - decisions before implementation
|
|
403
|
+
- **At integration points** - after configuring external services
|
|
404
|
+
|
|
405
|
+
Bad placement:
|
|
406
|
+
- Before Claude automates (asking human to do automatable work) ❌
|
|
407
|
+
- Too frequent (every other task is a checkpoint) ❌
|
|
408
|
+
- Too late (checkpoint is last task, but earlier tasks needed its result) ❌
|
|
409
|
+
</placement_guidelines>
|
|
410
|
+
|
|
411
|
+
<examples>
|
|
412
|
+
|
|
413
|
+
### Example 1: Deployment Flow (Correct)
|
|
414
|
+
|
|
415
|
+
```xml
|
|
416
|
+
<!-- Claude automates everything -->
|
|
417
|
+
<task type="auto">
|
|
418
|
+
<name>Deploy to Vercel</name>
|
|
419
|
+
<files>.vercel/, vercel.json, package.json</files>
|
|
420
|
+
<action>
|
|
421
|
+
1. Run `vercel --yes` to create project and deploy
|
|
422
|
+
2. Capture deployment URL from output
|
|
423
|
+
3. Set environment variables with `vercel env add`
|
|
424
|
+
4. Trigger production deployment with `vercel --prod`
|
|
425
|
+
</action>
|
|
426
|
+
<verify>
|
|
427
|
+
- vercel ls shows deployment
|
|
428
|
+
- curl {url} returns 200
|
|
429
|
+
- Environment variables set correctly
|
|
430
|
+
</verify>
|
|
431
|
+
<done>App deployed to production, URL captured</done>
|
|
432
|
+
</task>
|
|
433
|
+
|
|
434
|
+
<!-- Human verifies visual/functional correctness -->
|
|
435
|
+
<task type="checkpoint:human-verify" gate="blocking">
|
|
436
|
+
<what-built>Deployed to https://myapp.vercel.app</what-built>
|
|
437
|
+
<how-to-verify>
|
|
438
|
+
Visit https://myapp.vercel.app and confirm:
|
|
439
|
+
- Homepage loads correctly
|
|
440
|
+
- All images/assets load
|
|
441
|
+
- Navigation works
|
|
442
|
+
- No console errors
|
|
443
|
+
</how-to-verify>
|
|
444
|
+
<resume-signal>Type "approved" or describe issues</resume-signal>
|
|
445
|
+
</task>
|
|
446
|
+
```
|
|
447
|
+
|
|
448
|
+
### Example 2: Database Setup (Correct)
|
|
449
|
+
|
|
450
|
+
```xml
|
|
451
|
+
<!-- Claude automates everything -->
|
|
452
|
+
<task type="auto">
|
|
453
|
+
<name>Create Upstash Redis database</name>
|
|
454
|
+
<files>.env</files>
|
|
455
|
+
<action>
|
|
456
|
+
1. Run `upstash redis create myapp-cache --region us-east-1`
|
|
457
|
+
2. Capture connection URL from output
|
|
458
|
+
3. Write to .env: UPSTASH_REDIS_URL={url}
|
|
459
|
+
4. Verify connection with test command
|
|
460
|
+
</action>
|
|
461
|
+
<verify>
|
|
462
|
+
- upstash redis list shows database
|
|
463
|
+
- .env contains UPSTASH_REDIS_URL
|
|
464
|
+
- Test connection succeeds
|
|
465
|
+
</verify>
|
|
466
|
+
<done>Redis database created and configured</done>
|
|
467
|
+
</task>
|
|
468
|
+
|
|
469
|
+
<!-- NO CHECKPOINT NEEDED - Claude automated everything and verified programmatically -->
|
|
470
|
+
```
|
|
471
|
+
|
|
472
|
+
### Example 3: Stripe Webhooks (Correct)
|
|
473
|
+
|
|
474
|
+
```xml
|
|
475
|
+
<!-- Claude automates everything -->
|
|
476
|
+
<task type="auto">
|
|
477
|
+
<name>Configure Stripe webhooks</name>
|
|
478
|
+
<files>.env, src/app/api/webhooks/route.ts</files>
|
|
479
|
+
<action>
|
|
480
|
+
1. Use Stripe API to create webhook endpoint pointing to /api/webhooks
|
|
481
|
+
2. Subscribe to events: payment_intent.succeeded, customer.subscription.updated
|
|
482
|
+
3. Save webhook signing secret to .env
|
|
483
|
+
4. Implement webhook handler in route.ts
|
|
484
|
+
</action>
|
|
485
|
+
<verify>
|
|
486
|
+
- Stripe API returns webhook endpoint ID
|
|
487
|
+
- .env contains STRIPE_WEBHOOK_SECRET
|
|
488
|
+
- curl webhook endpoint returns 200
|
|
489
|
+
</verify>
|
|
490
|
+
<done>Stripe webhooks configured and handler implemented</done>
|
|
491
|
+
</task>
|
|
492
|
+
|
|
493
|
+
<!-- Human verifies in Stripe dashboard -->
|
|
494
|
+
<task type="checkpoint:human-verify" gate="blocking">
|
|
495
|
+
<what-built>Stripe webhook configured via API</what-built>
|
|
496
|
+
<how-to-verify>
|
|
497
|
+
Visit Stripe Dashboard > Developers > Webhooks
|
|
498
|
+
Confirm: Endpoint shows https://myapp.com/api/webhooks with correct events
|
|
499
|
+
</how-to-verify>
|
|
500
|
+
<resume-signal>Type "yes" if correct</resume-signal>
|
|
501
|
+
</task>
|
|
502
|
+
```
|
|
503
|
+
</examples>
|
|
504
|
+
|
|
505
|
+
<anti_patterns>
|
|
506
|
+
|
|
507
|
+
### ❌ BAD: Asking human to automate
|
|
508
|
+
|
|
509
|
+
```xml
|
|
510
|
+
<task type="checkpoint:human-action" gate="blocking">
|
|
511
|
+
<action>Deploy to Vercel</action>
|
|
512
|
+
<instructions>
|
|
513
|
+
1. Visit vercel.com/new
|
|
514
|
+
2. Import Git repository
|
|
515
|
+
3. Click Deploy
|
|
516
|
+
4. Copy deployment URL
|
|
517
|
+
</instructions>
|
|
518
|
+
<verification>Deployment exists</verification>
|
|
519
|
+
<resume-signal>Paste URL</resume-signal>
|
|
520
|
+
</task>
|
|
521
|
+
```
|
|
522
|
+
|
|
523
|
+
**Why bad:** Vercel has a CLI. Claude should run `vercel --yes`.
|
|
524
|
+
|
|
525
|
+
### ✅ GOOD: Claude automates, human verifies
|
|
526
|
+
|
|
527
|
+
```xml
|
|
528
|
+
<task type="auto">
|
|
529
|
+
<name>Deploy to Vercel</name>
|
|
530
|
+
<action>Run `vercel --yes`. Capture URL.</action>
|
|
531
|
+
<verify>vercel ls shows deployment, curl returns 200</verify>
|
|
532
|
+
</task>
|
|
533
|
+
|
|
534
|
+
<task type="checkpoint:human-verify">
|
|
535
|
+
<what-built>Deployed to {url}</what-built>
|
|
536
|
+
<how-to-verify>Visit {url}, check homepage loads</how-to-verify>
|
|
537
|
+
<resume-signal>Type "approved"</resume-signal>
|
|
538
|
+
</task>
|
|
539
|
+
```
|
|
540
|
+
|
|
541
|
+
### ❌ BAD: Too many checkpoints
|
|
542
|
+
|
|
543
|
+
```xml
|
|
544
|
+
<task type="auto">Create schema</task>
|
|
545
|
+
<task type="checkpoint:human-verify">Check schema</task>
|
|
546
|
+
<task type="auto">Create API route</task>
|
|
547
|
+
<task type="checkpoint:human-verify">Check API</task>
|
|
548
|
+
<task type="auto">Create UI form</task>
|
|
549
|
+
<task type="checkpoint:human-verify">Check form</task>
|
|
550
|
+
```
|
|
551
|
+
|
|
552
|
+
**Why bad:** Verification fatigue. Combine into one checkpoint at end.
|
|
553
|
+
|
|
554
|
+
### ✅ GOOD: Single verification checkpoint
|
|
555
|
+
|
|
556
|
+
```xml
|
|
557
|
+
<task type="auto">Create schema</task>
|
|
558
|
+
<task type="auto">Create API route</task>
|
|
559
|
+
<task type="auto">Create UI form</task>
|
|
560
|
+
|
|
561
|
+
<task type="checkpoint:human-verify">
|
|
562
|
+
<what-built>Complete auth flow (schema + API + UI)</what-built>
|
|
563
|
+
<how-to-verify>Test full flow: register, login, access protected page</how-to-verify>
|
|
564
|
+
<resume-signal>Type "approved"</resume-signal>
|
|
565
|
+
</task>
|
|
566
|
+
```
|
|
567
|
+
|
|
568
|
+
### ❌ BAD: Asking for automatable file operations
|
|
569
|
+
|
|
570
|
+
```xml
|
|
571
|
+
<task type="checkpoint:human-action">
|
|
572
|
+
<action>Create .env file</action>
|
|
573
|
+
<instructions>
|
|
574
|
+
1. Create .env in project root
|
|
575
|
+
2. Add: DATABASE_URL=...
|
|
576
|
+
3. Add: STRIPE_KEY=...
|
|
577
|
+
</instructions>
|
|
578
|
+
</task>
|
|
579
|
+
```
|
|
580
|
+
|
|
581
|
+
**Why bad:** Claude has Write tool. This should be `type="auto"`.
|
|
582
|
+
</anti_patterns>
|
|
583
|
+
|
|
584
|
+
<summary>
|
|
585
|
+
|
|
586
|
+
Checkpoints formalize human-in-the-loop points. Use them when Claude cannot complete a task autonomously OR when human verification is required for correctness.
|
|
587
|
+
|
|
588
|
+
**The golden rule:** If Claude CAN automate it, Claude MUST automate it.
|
|
589
|
+
|
|
590
|
+
**Checkpoint priority:**
|
|
591
|
+
1. **checkpoint:human-verify** (90% of checkpoints) - Claude automated everything, human confirms visual/functional correctness
|
|
592
|
+
2. **checkpoint:decision** (9% of checkpoints) - Human makes architectural/technology choices
|
|
593
|
+
3. **checkpoint:human-action** (1% of checkpoints) - Truly unavoidable manual steps with no API/CLI
|
|
594
|
+
</summary>
|