jettypod 4.3.0 โ 4.4.1
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/SECURITY-AUDIT-CATASTROPHIC-DELETE.md +196 -0
- package/TEST_HOOK.md +1 -0
- package/docs/DECISIONS.md +4 -52
- package/jettypod.js +210 -24
- package/lib/chore-classifier.js +232 -0
- package/lib/chore-taxonomy.js +172 -0
- package/lib/jettypod-backup.js +124 -8
- package/lib/safe-delete.js +794 -0
- package/lib/worktree-manager.js +54 -41
- package/package.json +1 -1
- package/skills-templates/chore-mode/SKILL.md +396 -0
- package/skills-templates/chore-mode/verification.js +255 -0
- package/skills-templates/chore-planning/SKILL.md +229 -0
- package/skills-templates/epic-planning/SKILL.md +13 -5
- package/skills-templates/feature-planning/SKILL.md +113 -158
- package/skills-templates/production-mode/SKILL.md +7 -4
- package/skills-templates/speed-mode/SKILL.md +463 -471
- package/skills-templates/stable-mode/SKILL.md +371 -319
|
@@ -11,21 +11,6 @@ Guides Claude through feature planning including UX approach exploration, option
|
|
|
11
11
|
|
|
12
12
|
When this skill is activated, you are helping discover the best approach for a feature. Follow this structured approach:
|
|
13
13
|
|
|
14
|
-
## ๐ Critical Command Distinction
|
|
15
|
-
|
|
16
|
-
**Two different commands, two different purposes:**
|
|
17
|
-
|
|
18
|
-
| Command | Used For | When | Phase |
|
|
19
|
-
|---------|----------|------|-------|
|
|
20
|
-
| `work implement <feature-id>` | Transition feature to implementation phase | During feature planning (Step 8B) | Feature Planning |
|
|
21
|
-
| `work start <chore-id>` | Start implementing a specific chore | After feature planning complete (Step 8D) | Speed Mode |
|
|
22
|
-
|
|
23
|
-
**CRITICAL:** Both commands are run by **Claude**, not the user. The distinction is:
|
|
24
|
-
- `work implement` = Ends feature planning, creates chores
|
|
25
|
-
- `work start` = Begins implementing a chore (triggers speed-mode skill)
|
|
26
|
-
|
|
27
|
-
---
|
|
28
|
-
|
|
29
14
|
### Step 1: Understand the Feature Context
|
|
30
15
|
|
|
31
16
|
You'll receive context about:
|
|
@@ -111,42 +96,15 @@ If user wants prototypes:
|
|
|
111
96
|
1. **Build prototypes** in `/prototypes/feature-[id]-[approach-name]/`
|
|
112
97
|
2. **Name format**: `YYYY-MM-DD-[feature-slug]-[option].ext`
|
|
113
98
|
3. **Focus on UX**: Show the feel, not production code
|
|
114
|
-
4. **Add
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
Created: [YYYY-MM-DD]<br>
|
|
121
|
-
Purpose: [what this explores]<br>
|
|
122
|
-
Decision: [to be filled after testing]
|
|
123
|
-
</div>
|
|
99
|
+
4. **Add prototype header**:
|
|
100
|
+
```
|
|
101
|
+
// Prototype: [feature] - [option]
|
|
102
|
+
// Created: [date]
|
|
103
|
+
// Purpose: [what this explores]
|
|
104
|
+
// Decision: [to be filled after testing]
|
|
124
105
|
```
|
|
125
|
-
For CLI/terminal prototypes, add similar info as first output.
|
|
126
106
|
5. **Offer to open them**: "Want me to open these in your browser?"
|
|
127
107
|
|
|
128
|
-
<details>
|
|
129
|
-
<summary><strong>๐ Prototyping Guidelines (click to expand)</strong></summary>
|
|
130
|
-
|
|
131
|
-
**Use fastest tech to demonstrate UX:**
|
|
132
|
-
- Quick HTML+JS for web UX
|
|
133
|
-
- Simple CLI scripts for command-line UX
|
|
134
|
-
- Minimal frameworks, maximum clarity
|
|
135
|
-
|
|
136
|
-
**What to prototype:**
|
|
137
|
-
- User interaction flow
|
|
138
|
-
- Visual layout (if UI)
|
|
139
|
-
- Command structure (if CLI)
|
|
140
|
-
- API shape (if API)
|
|
141
|
-
|
|
142
|
-
**What NOT to prototype:**
|
|
143
|
-
- Production error handling
|
|
144
|
-
- Database layer
|
|
145
|
-
- Authentication (unless that's the feature)
|
|
146
|
-
- Test coverage
|
|
147
|
-
|
|
148
|
-
</details>
|
|
149
|
-
|
|
150
108
|
### Step 5: Choose Winner
|
|
151
109
|
|
|
152
110
|
After user tests (or skips prototyping):
|
|
@@ -166,12 +124,10 @@ Based on chosen approach, generate:
|
|
|
166
124
|
**A. Scenario file** at `features/[feature-slug].feature` using Write tool:
|
|
167
125
|
|
|
168
126
|
1. **Create file** at `features/[feature-slug].feature` using Write tool
|
|
169
|
-
2. **
|
|
170
|
-
-
|
|
171
|
-
- Multiple valid workflows if the feature supports them
|
|
172
|
-
- Success variations (different outcomes that are all correct)
|
|
127
|
+
2. **ONLY include happy path scenario**:
|
|
128
|
+
- Happy path ONLY - the core user journey that proves it works
|
|
173
129
|
- NO error handling scenarios (added in stable mode)
|
|
174
|
-
- NO
|
|
130
|
+
- NO edge cases (added in stable mode)
|
|
175
131
|
- NO security/compliance scenarios (added in production mode)
|
|
176
132
|
|
|
177
133
|
**B. Step definitions file** at `features/step_definitions/[feature-slug].steps.js` using Write tool:
|
|
@@ -191,7 +147,7 @@ Based on chosen approach, generate:
|
|
|
191
147
|
sqlite3 .jettypod/work.db "UPDATE work_items SET scenario_file = 'features/[feature-slug].feature' WHERE id = <feature-id>"
|
|
192
148
|
```
|
|
193
149
|
|
|
194
|
-
**Template for speed mode (
|
|
150
|
+
**Template for speed mode (happy path only):**
|
|
195
151
|
|
|
196
152
|
```gherkin
|
|
197
153
|
Feature: [Feature Name]
|
|
@@ -200,20 +156,15 @@ Feature: [Feature Name]
|
|
|
200
156
|
Epic: [Epic name if applicable]
|
|
201
157
|
Approach: [Chosen approach name]
|
|
202
158
|
|
|
203
|
-
Scenario: [
|
|
159
|
+
Scenario: [Happy path scenario - core user journey]
|
|
204
160
|
Given [initial state]
|
|
205
161
|
When [user takes main action]
|
|
206
162
|
Then [expected successful outcome]
|
|
207
163
|
And [observable UI/system state change]
|
|
208
164
|
|
|
209
|
-
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
Then [feature works correctly]
|
|
213
|
-
|
|
214
|
-
# SPEED MODE: All success scenarios above (required + optional functionality)
|
|
215
|
-
# STABLE MODE: Will add error handling, validation failures, edge cases
|
|
216
|
-
# These failure scenarios are added by stable-mode skill, NOT during feature discovery
|
|
165
|
+
# SPEED MODE: Only happy path above
|
|
166
|
+
# STABLE MODE: Will add error handling, edge cases, validation scenarios
|
|
167
|
+
# These additional scenarios are added by stable-mode skill, NOT during feature discovery
|
|
217
168
|
```
|
|
218
169
|
|
|
219
170
|
**Example for Login feature (speed mode):**
|
|
@@ -231,66 +182,8 @@ Scenario: User successfully logs in with valid credentials
|
|
|
231
182
|
Then I am redirected to the dashboard
|
|
232
183
|
And I see a welcome message with my name
|
|
233
184
|
And I have an active session token
|
|
234
|
-
|
|
235
|
-
Scenario: User logs in with "Remember me" option (optional feature)
|
|
236
|
-
Given I am on the login page
|
|
237
|
-
When I enter valid credentials
|
|
238
|
-
And I check the "Remember me" checkbox
|
|
239
|
-
And I click the login button
|
|
240
|
-
Then I am redirected to the dashboard
|
|
241
|
-
And my session persists for 30 days
|
|
242
|
-
```
|
|
243
|
-
|
|
244
|
-
<details>
|
|
245
|
-
<summary><strong>๐ BDD Scenario Guidelines (click to expand)</strong></summary>
|
|
246
|
-
|
|
247
|
-
**Scenario naming:**
|
|
248
|
-
- Use present tense
|
|
249
|
-
- Be specific about what's being tested
|
|
250
|
-
- Focus on user behavior
|
|
251
|
-
|
|
252
|
-
**Given/When/Then structure:**
|
|
253
|
-
- **Given**: Set up initial state
|
|
254
|
-
- **When**: User action
|
|
255
|
-
- **Then**: Observable outcome
|
|
256
|
-
|
|
257
|
-
**What feature planning creates:**
|
|
258
|
-
|
|
259
|
-
Feature planning creates speed mode scenarios (make it work - all success paths):
|
|
260
|
-
```gherkin
|
|
261
|
-
Scenario: User successfully [does the required thing]
|
|
262
|
-
Given [setup]
|
|
263
|
-
When [action]
|
|
264
|
-
Then [success]
|
|
265
|
-
|
|
266
|
-
Scenario: User successfully [uses optional feature]
|
|
267
|
-
Given [setup]
|
|
268
|
-
When [uses optional capability]
|
|
269
|
-
Then [feature works correctly]
|
|
270
|
-
```
|
|
271
|
-
|
|
272
|
-
**Additional scenarios are added LATER by stable-mode skill:**
|
|
273
|
-
|
|
274
|
-
Stable mode adds error handling and validation:
|
|
275
|
-
```gherkin
|
|
276
|
-
Scenario: Handle invalid input
|
|
277
|
-
Given [setup]
|
|
278
|
-
When [invalid action]
|
|
279
|
-
Then [appropriate error]
|
|
280
185
|
```
|
|
281
186
|
|
|
282
|
-
Production mode adds security/scale/compliance:
|
|
283
|
-
```gherkin
|
|
284
|
-
Scenario: Prevent unauthorized access
|
|
285
|
-
Given [unauthorized user]
|
|
286
|
-
When [attempts action]
|
|
287
|
-
Then [access denied with proper error]
|
|
288
|
-
```
|
|
289
|
-
|
|
290
|
-
**IMPORTANT:** Feature planning creates all success scenarios (required + optional). Stable/production chores add failure scenarios later.
|
|
291
|
-
|
|
292
|
-
</details>
|
|
293
|
-
|
|
294
187
|
### Step 6.5: Validate BDD Infrastructure
|
|
295
188
|
|
|
296
189
|
**CRITICAL:** After creating both scenario and step definition files, automatically validate them with cucumber dry-run to catch errors immediately.
|
|
@@ -343,7 +236,7 @@ console.log(''); // Extra line before continuing
|
|
|
343
236
|
|
|
344
237
|
The speed-mode skill guides Claude to:
|
|
345
238
|
1. Implement the feature code
|
|
346
|
-
2. Create corresponding unit tests for
|
|
239
|
+
2. Create corresponding unit tests for the happy path
|
|
347
240
|
3. Ensure tests pass before completing the chore
|
|
348
241
|
|
|
349
242
|
This keeps feature planning focused on BDD scenarios (what users experience) while speed mode handles unit tests (implementation details).
|
|
@@ -353,7 +246,7 @@ This keeps feature planning focused on BDD scenarios (what users experience) whi
|
|
|
353
246
|
**CRITICAL:** After BDD validation passes, analyze the codebase and propose technical implementation chores. **DO NOT CREATE CHORES YET** - the feature must transition to implementation mode first (Step 8).
|
|
354
247
|
|
|
355
248
|
**Your analysis should consider:**
|
|
356
|
-
- The BDD scenarios (
|
|
249
|
+
- The BDD scenarios (especially the happy path)
|
|
357
250
|
- Existing codebase structure and patterns
|
|
358
251
|
- Epic's architectural decisions (if any)
|
|
359
252
|
- Tech stack and framework conventions
|
|
@@ -393,7 +286,7 @@ Based on the scenario and my understanding of the codebase, here are the chores
|
|
|
393
286
|
|
|
394
287
|
[etc.]
|
|
395
288
|
|
|
396
|
-
These chores will make
|
|
289
|
+
These chores will make the happy path scenario pass.
|
|
397
290
|
|
|
398
291
|
Sound good? Any adjustments?
|
|
399
292
|
```
|
|
@@ -438,11 +331,16 @@ node jettypod.js work implement [feature-id] \
|
|
|
438
331
|
|
|
439
332
|
**CRITICAL: NOW create the chores.** The feature has transitioned to implementation mode, so chore creation will succeed.
|
|
440
333
|
|
|
441
|
-
|
|
334
|
+
**IMPORTANT:** You MUST pass `--parent=<FEATURE_ID>` with the actual numeric feature ID. Without this, chores won't be linked to the feature.
|
|
335
|
+
|
|
336
|
+
For each chore that the user confirmed in Step 7, use the Bash tool to create it. Replace `<FEATURE_ID>` with the actual feature ID number:
|
|
442
337
|
|
|
443
338
|
```bash
|
|
444
|
-
#
|
|
445
|
-
node jettypod.js work create chore "
|
|
339
|
+
# CORRECT - uses actual numeric feature ID:
|
|
340
|
+
node jettypod.js work create chore "Implement cursor position broadcast" "Broadcast cursor positions..." --parent=12
|
|
341
|
+
|
|
342
|
+
# WRONG - missing parent flag (chore won't be linked to feature):
|
|
343
|
+
node jettypod.js work create chore "Implement cursor position broadcast" "Broadcast cursor positions..."
|
|
446
344
|
```
|
|
447
345
|
|
|
448
346
|
**Build the description from your Step 7 proposal:**
|
|
@@ -469,7 +367,7 @@ After creating all chores, display:
|
|
|
469
367
|
โ
Created X chores for speed mode
|
|
470
368
|
|
|
471
369
|
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
472
|
-
๐ฏ Feature
|
|
370
|
+
๐ฏ Feature Discovery Complete!
|
|
473
371
|
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
474
372
|
|
|
475
373
|
๐ BDD scenarios: features/[feature-slug].feature
|
|
@@ -480,30 +378,97 @@ After creating all chores, display:
|
|
|
480
378
|
Ready to start implementation?
|
|
481
379
|
```
|
|
482
380
|
|
|
483
|
-
#### Step 8D:
|
|
381
|
+
#### Step 8D: Transition to Speed Mode
|
|
484
382
|
|
|
485
|
-
**
|
|
383
|
+
**WAIT for user confirmation.**
|
|
486
384
|
|
|
487
|
-
|
|
385
|
+
When user confirms they want to proceed with implementation (responds with "yes", "let's go", "proceed", "start", or similar):
|
|
386
|
+
|
|
387
|
+
**IMMEDIATELY invoke the speed-mode skill using the Skill tool:**
|
|
488
388
|
|
|
489
389
|
```
|
|
490
|
-
|
|
390
|
+
Use the Skill tool with skill: "speed-mode"
|
|
491
391
|
```
|
|
492
392
|
|
|
493
|
-
**
|
|
393
|
+
**The speed-mode skill will then:**
|
|
394
|
+
1. Guide the user to start the first chore with `jettypod work start [chore-id]`
|
|
395
|
+
2. Create a worktree for the chore
|
|
396
|
+
3. Follow TDD workflow to implement the chore
|
|
397
|
+
4. Merge when complete
|
|
494
398
|
|
|
495
|
-
|
|
496
|
-
|
|
399
|
+
**End feature-planning skill after invoking speed-mode.**
|
|
400
|
+
|
|
401
|
+
## Key Principles
|
|
402
|
+
|
|
403
|
+
1. **Always suggest exactly 3 options** - Simple, Balanced, Advanced
|
|
404
|
+
2. **Show epic's architectural decision** - Feature should align with epic's technical approach
|
|
405
|
+
3. **UX first, tech second** - Focus on what it feels like to use, not implementation details
|
|
406
|
+
4. **Prototypes are optional but valuable** - User can skip if approach is obvious
|
|
407
|
+
5. **BDD scenarios are required** - Discovery isn't complete without scenarios
|
|
408
|
+
6. **Guide to next step** - Always end with clear action
|
|
409
|
+
|
|
410
|
+
## Prototyping Guidelines
|
|
411
|
+
|
|
412
|
+
**Use fastest tech to demonstrate UX:**
|
|
413
|
+
- Quick HTML+JS for web UX
|
|
414
|
+
- Simple CLI scripts for command-line UX
|
|
415
|
+
- Minimal frameworks, maximum clarity
|
|
416
|
+
|
|
417
|
+
**What to prototype:**
|
|
418
|
+
- User interaction flow
|
|
419
|
+
- Visual layout (if UI)
|
|
420
|
+
- Command structure (if CLI)
|
|
421
|
+
- API shape (if API)
|
|
422
|
+
|
|
423
|
+
**What NOT to prototype:**
|
|
424
|
+
- Production error handling
|
|
425
|
+
- Database layer
|
|
426
|
+
- Authentication (unless that's the feature)
|
|
427
|
+
- Test coverage
|
|
428
|
+
|
|
429
|
+
## BDD Scenario Guidelines
|
|
430
|
+
|
|
431
|
+
**Scenario naming:**
|
|
432
|
+
- Use present tense
|
|
433
|
+
- Be specific about what's being tested
|
|
434
|
+
- Focus on user behavior
|
|
435
|
+
|
|
436
|
+
**Given/When/Then structure:**
|
|
437
|
+
- **Given**: Set up initial state
|
|
438
|
+
- **When**: User action
|
|
439
|
+
- **Then**: Observable outcome
|
|
440
|
+
|
|
441
|
+
**What feature-discover creates:**
|
|
442
|
+
|
|
443
|
+
**Feature discovery ONLY creates speed mode scenarios (happy path):**
|
|
444
|
+
```gherkin
|
|
445
|
+
Scenario: User successfully [does the thing]
|
|
446
|
+
Given [setup]
|
|
447
|
+
When [action]
|
|
448
|
+
Then [success]
|
|
449
|
+
```
|
|
450
|
+
|
|
451
|
+
**Additional scenarios are added LATER by stable-mode skill:**
|
|
452
|
+
|
|
453
|
+
Stable mode adds error handling:
|
|
454
|
+
```gherkin
|
|
455
|
+
Scenario: Handle invalid input
|
|
456
|
+
Given [setup]
|
|
457
|
+
When [invalid action]
|
|
458
|
+
Then [appropriate error]
|
|
497
459
|
```
|
|
498
460
|
|
|
499
|
-
|
|
500
|
-
|
|
501
|
-
|
|
502
|
-
|
|
461
|
+
Production mode adds security/scale/compliance:
|
|
462
|
+
```gherkin
|
|
463
|
+
Scenario: Prevent unauthorized access
|
|
464
|
+
Given [unauthorized user]
|
|
465
|
+
When [attempts action]
|
|
466
|
+
Then [access denied with proper error]
|
|
467
|
+
```
|
|
503
468
|
|
|
504
|
-
**
|
|
469
|
+
**IMPORTANT:** Feature discovery only creates happy path. Stable/production chores add more scenarios later.
|
|
505
470
|
|
|
506
|
-
## Example: Feature
|
|
471
|
+
## Example: Feature Discovery Flow
|
|
507
472
|
|
|
508
473
|
**Feature:** "Email/password login"
|
|
509
474
|
**Epic decision:** "Using Auth.js with JWT tokens"
|
|
@@ -515,25 +480,17 @@ jettypod work start [chore-id]
|
|
|
515
480
|
|
|
516
481
|
**User picks:** Option 1 (Simple inline form)
|
|
517
482
|
|
|
518
|
-
**Scenarios generated (
|
|
483
|
+
**Scenarios generated (happy path only for speed mode):**
|
|
519
484
|
```gherkin
|
|
520
485
|
Feature: Email/Password Login
|
|
521
486
|
|
|
522
|
-
Scenario: Successful login
|
|
487
|
+
Scenario: Successful login
|
|
523
488
|
Given I am on the login page
|
|
524
489
|
When I enter valid credentials and submit
|
|
525
490
|
Then I am redirected to the dashboard
|
|
526
491
|
And I have an active JWT token
|
|
527
492
|
|
|
528
|
-
|
|
529
|
-
Given I am on the login page
|
|
530
|
-
When I enter valid credentials
|
|
531
|
-
And I check "Remember me"
|
|
532
|
-
And I submit
|
|
533
|
-
Then I am redirected to the dashboard
|
|
534
|
-
And my session persists for 30 days
|
|
535
|
-
|
|
536
|
-
# SPEED MODE: All success scenarios above (required + optional features)
|
|
493
|
+
# SPEED MODE: Only happy path above
|
|
537
494
|
# STABLE MODE: Will add error handling scenarios like "Invalid credentials"
|
|
538
495
|
```
|
|
539
496
|
|
|
@@ -543,17 +500,15 @@ User confirms: "Yes, perfect"
|
|
|
543
500
|
|
|
544
501
|
**Transition:** `jettypod work implement 10 --winner="prototypes/2025-10-30-login-simple.html" --rationale="Simple inline form chosen - fastest for users, cleanest UX"`
|
|
545
502
|
|
|
546
|
-
## Validation
|
|
503
|
+
## Validation
|
|
547
504
|
|
|
548
|
-
Before completing feature
|
|
505
|
+
Before completing feature discovery, ensure:
|
|
549
506
|
- [ ] Epic's architectural decision is shown (if exists)
|
|
550
507
|
- [ ] Exactly 3 approaches suggested
|
|
551
508
|
- [ ] Winner chosen (with prototypes or without)
|
|
552
|
-
- [ ] BDD scenarios written
|
|
509
|
+
- [ ] BDD scenarios written
|
|
553
510
|
- [ ] Step definitions written for ALL scenario steps
|
|
554
511
|
- [ ] Scenarios file exists at `features/[feature-slug].feature`
|
|
555
512
|
- [ ] Step definitions file exists at `features/step_definitions/[feature-slug].steps.js`
|
|
556
513
|
- [ ] BDD infrastructure validated with dry-run (Step 6.5)
|
|
557
|
-
- [ ]
|
|
558
|
-
- [ ] Speed mode chores created
|
|
559
|
-
- [ ] First chore started with `work start [chore-id]` (Step 8D)
|
|
514
|
+
- [ ] User knows next step .jettypod work start [feature-id])
|
|
@@ -39,8 +39,8 @@ When this skill is activated, you are helping implement a production mode chore
|
|
|
39
39
|
**To detect context, check these conditions:**
|
|
40
40
|
|
|
41
41
|
```bash
|
|
42
|
-
# Get current work
|
|
43
|
-
|
|
42
|
+
# Get current work and parent feature
|
|
43
|
+
jettypod work current
|
|
44
44
|
|
|
45
45
|
# Check for production scenarios in the feature file
|
|
46
46
|
# (Look for scenarios tagged with @production or containing production-related keywords)
|
|
@@ -230,8 +230,11 @@ This will:
|
|
|
230
230
|
**Get current work and identify target scenario:**
|
|
231
231
|
|
|
232
232
|
```bash
|
|
233
|
-
# Get current chore details
|
|
234
|
-
|
|
233
|
+
# Get current chore details
|
|
234
|
+
jettypod work current
|
|
235
|
+
|
|
236
|
+
# Get parent feature's scenario file
|
|
237
|
+
sqlite3 .jettypod/work.db "SELECT scenario_file FROM work_items WHERE id = <parent-feature-id>"
|
|
235
238
|
```
|
|
236
239
|
|
|
237
240
|
Parse the chore description to find which scenario it addresses (look for "Scenario: ..." in the description).
|