jettypod 4.4.10 → 4.4.11

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.
Files changed (32) hide show
  1. package/apps/dashboard/README.md +36 -0
  2. package/apps/dashboard/app/favicon.ico +0 -0
  3. package/apps/dashboard/app/globals.css +122 -0
  4. package/apps/dashboard/app/layout.tsx +34 -0
  5. package/apps/dashboard/app/page.tsx +25 -0
  6. package/apps/dashboard/app/work/[id]/page.tsx +193 -0
  7. package/apps/dashboard/components/KanbanBoard.tsx +201 -0
  8. package/apps/dashboard/components/WorkItemTree.tsx +116 -0
  9. package/apps/dashboard/components.json +22 -0
  10. package/apps/dashboard/eslint.config.mjs +18 -0
  11. package/apps/dashboard/lib/db.ts +270 -0
  12. package/apps/dashboard/lib/utils.ts +6 -0
  13. package/apps/dashboard/next.config.ts +7 -0
  14. package/apps/dashboard/package.json +33 -0
  15. package/apps/dashboard/postcss.config.mjs +7 -0
  16. package/apps/dashboard/public/file.svg +1 -0
  17. package/apps/dashboard/public/globe.svg +1 -0
  18. package/apps/dashboard/public/next.svg +1 -0
  19. package/apps/dashboard/public/vercel.svg +1 -0
  20. package/apps/dashboard/public/window.svg +1 -0
  21. package/apps/dashboard/tsconfig.json +34 -0
  22. package/jettypod.js +41 -0
  23. package/lib/current-work.js +10 -18
  24. package/lib/migrations/016-workflow-checkpoints-table.js +70 -0
  25. package/lib/migrations/017-backfill-epic-id.js +54 -0
  26. package/lib/workflow-checkpoint.js +204 -0
  27. package/package.json +7 -2
  28. package/skills-templates/chore-mode/SKILL.md +3 -0
  29. package/skills-templates/epic-planning/SKILL.md +225 -154
  30. package/skills-templates/feature-planning/SKILL.md +172 -87
  31. package/skills-templates/speed-mode/SKILL.md +161 -338
  32. package/skills-templates/stable-mode/SKILL.md +8 -2
@@ -13,11 +13,23 @@ description: Guide implementation of speed mode chores with autonomous code anal
13
13
  │ ▲▲▲▲▲▲▲▲▲▲▲ │
14
14
  │ YOU ARE HERE │
15
15
  │ │
16
- │ Next: After implementation, this skill generates stable mode
17
- │ chores and elevates the feature to stable mode.
16
+ │ Next: After ALL speed chores complete, this skill generates
17
+ stable mode chores and IMMEDIATELY invokes stable-mode skill.
18
18
  └─────────────────────────────────────────────────────────────────────┘
19
19
  ```
20
20
 
21
+ ## 🛑 CRITICAL HANDOFF REQUIREMENT
22
+
23
+ **After completing ALL speed mode chores, you MUST:**
24
+ 1. Generate stable mode BDD scenarios and step definitions
25
+ 2. Create stable mode chores
26
+ 3. Set feature mode to stable
27
+ 4. **IMMEDIATELY invoke stable-mode using the Skill tool**
28
+
29
+ **🛑 STOP GATE:** DO NOT end this skill without invoking stable-mode. Speed mode is ONLY a checkpoint - features are INCOMPLETE without stable mode.
30
+
31
+ ---
32
+
21
33
  Guides Claude Code through speed mode implementation with autonomous analysis and execution. Users confirm approach but Claude Code writes the code.
22
34
 
23
35
  ## Instructions
@@ -51,6 +63,28 @@ When this skill is activated, you are helping implement a speed mode chore to ma
51
63
 
52
64
  **User Profile:** May not know how to code - Claude Code does the implementation autonomously.
53
65
 
66
+ <details>
67
+ <summary><strong>📋 Speed Mode Constraints (click to expand)</strong></summary>
68
+
69
+ **What to implement:**
70
+ - ALL scoped functionality - required features AND optional features from all success scenarios
71
+ - Multiple valid workflows if the feature supports them
72
+ - Success variations (different outcomes that are all correct)
73
+
74
+ **What NOT to implement:**
75
+ - ❌ Error handling (try/catch, validation, edge cases)
76
+ - ❌ Input validation (null checks, type checks, range validation)
77
+ - ❌ Error messages for failures
78
+ - ❌ Edge case handling (empty arrays, boundary values, race conditions)
79
+
80
+ **Code organization:**
81
+ - Single file when possible - keep it simple
82
+ - Inline code over separate modules initially
83
+ - Use real infrastructure (actual database/storage from your tech stack, not mocks)
84
+ - Focus: Make. All. Features. Work. (all success paths)
85
+
86
+ </details>
87
+
54
88
  ---
55
89
 
56
90
  ## 🧪 Unit Testing in Speed Mode - True TDD
@@ -75,7 +109,9 @@ When this skill is activated, you are helping implement a speed mode chore to ma
75
109
  - Follow project conventions: `test/`, `__tests__/`, or `*.test.js` alongside code
76
110
  - Check existing test files for patterns
77
111
 
78
- **Example of TDD iteration:**
112
+ <details>
113
+ <summary><strong>📋 TDD Example (click to expand)</strong></summary>
114
+
79
115
  ```javascript
80
116
  // Iteration 1: BDD step "Given a user exists" is failing
81
117
 
@@ -112,30 +148,30 @@ test('createUser throws error for invalid email', () => {
112
148
  });
113
149
  ```
114
150
 
115
- <details>
116
- <summary><strong>📋 Speed Mode Constraints (click to expand)</strong></summary>
151
+ </details>
117
152
 
118
- **What to implement:**
119
- - ALL scoped functionality - required features AND optional features from all success scenarios
120
- - Multiple valid workflows if the feature supports them
121
- - Success variations (different outcomes that are all correct)
153
+ ---
122
154
 
123
- **What NOT to implement:**
124
- - ❌ Error handling (try/catch, validation, edge cases)
125
- - ❌ Input validation (null checks, type checks, range validation)
126
- - ❌ Error messages for failures
127
- - ❌ Edge case handling (empty arrays, boundary values, race conditions)
155
+ ## Quick Reference: Async Boundaries
128
156
 
129
- **Code organization:**
130
- - Single file when possible - keep it simple
131
- - Inline code over separate modules initially
132
- - Use real infrastructure (actual database/storage from your tech stack, not mocks)
133
- - Focus: Make. All. Features. Work. (all success paths)
157
+ **Where Claude Code MUST wait for user confirmation:**
134
158
 
135
- </details>
159
+ | Step | Location | Why |
160
+ |------|----------|-----|
161
+ | Step 3A | Before implementing (conditional) | User confirms implementation approach - only if ambiguous |
162
+ | Step 7B | Before creating stable chores | User confirms proposed stable mode chores - always |
163
+
164
+ **Where Claude Code executes autonomously:**
165
+ - Steps 0-2: Initialize, analyze scenarios, analyze codebase
166
+ - Step 3: Decision to skip/ask confirmation
167
+ - Steps 4-5: RED baseline, RED→GREEN→REFACTOR loop
168
+ - Step 6: Route to next chore OR transition to Step 7
169
+ - Step 7 (after confirmation): Create chores, commit, set mode, invoke stable-mode
136
170
 
137
171
  ---
138
172
 
173
+ ## Implementation Steps
174
+
139
175
  ### Step 0: Initialize Speed Mode Context
140
176
 
141
177
  **You are now in speed mode,** implementing a chore to make success scenarios pass.
@@ -165,57 +201,6 @@ Analyzing BDD scenarios to determine implementation approach...
165
201
 
166
202
  ---
167
203
 
168
- ## Quick Reference: Async Boundaries
169
-
170
- **Where Claude Code MUST wait for user confirmation:**
171
-
172
- | Phase | Location | Why | Condition |
173
- |-------|----------|-----|-----------|
174
- | Step 3A | Before implementing (conditional) | User confirms implementation approach | Only if approach is ambiguous or multiple valid paths |
175
- | Step 6 Phase 2 | Before creating stable chores | User confirms proposed stable mode chores | Always |
176
-
177
- **Where Claude Code executes autonomously:**
178
- - Step 0: Initialize context
179
- - Step 1: Scenario analysis and breadcrumb check
180
- - Step 2: Codebase analysis
181
- - Step 3: Decision to skip/ask for confirmation
182
- - Step 4: Establish RED baseline
183
- - Step 5: RED→GREEN→REFACTOR loop (true TDD)
184
- - Step 6 Phase 1: Generate stable mode scenarios/steps
185
- - Step 6 Phases 3-5: Create chores and invoke stable-mode skill
186
-
187
- ---
188
-
189
- ## ⚠️ CRITICAL: Speed Mode Workflow Requirements
190
-
191
- **DO NOT mark features as complete after speed mode implementation.**
192
-
193
- Speed mode is ONLY a checkpoint to prove functionality works. Features are INCOMPLETE without stable mode chores that add:
194
- - Error handling and validation
195
- - Edge case coverage
196
- - Comprehensive testing
197
- - User-friendly error messages
198
-
199
- **Required workflow after speed mode implementation:**
200
-
201
- 1. ✅ **Complete ALL speed mode chores** - Implement all success scenarios (required + optional features)
202
- 2. ✅ **Elevate to stable mode** - Use `jettypod work set-mode <feature-id> stable` to auto-generate stable mode chores
203
- 3. ✅ **Implement stable mode chores** - Add error handling and edge cases
204
- 4. ❌ **NEVER mark feature complete in speed mode** - This bypasses critical quality gates
205
-
206
- **If you attempt to mark a feature complete while in speed mode, the system will block you with an error.**
207
-
208
- The validation will require you to:
209
- - Elevate to stable mode: `jettypod work set-mode <feature-id> stable`
210
- - This will automatically analyze the implementation and generate appropriate stable mode chores
211
- - Or explicitly skip (not recommended): `jettypod work set-mode <feature-id> stable --force`
212
-
213
- **Remember:** Speed mode makes it work (all success scenarios). Stable mode makes it robust (handles failures).
214
-
215
- ---
216
-
217
- ## Implementation Steps
218
-
219
204
  ### Step 1: Check for Breadcrumbs and Analyze Scenario
220
205
 
221
206
  **CRITICAL:** Claude Code executes this autonomously - no user permission needed.
@@ -230,7 +215,6 @@ The validation will require you to:
230
215
  **To get current work and check for breadcrumbs:**
231
216
 
232
217
  ```bash
233
- # Get current work item with description and parent feature's scenario_file
234
218
  sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.description, wi.parent_id, parent.title as parent_title, parent.scenario_file FROM work_items wi LEFT JOIN work_items parent ON wi.parent_id = parent.id WHERE wi.status = 'in_progress' AND wi.type = 'chore'"
235
219
  ```
236
220
 
@@ -485,7 +469,7 @@ Now implementing...
485
469
 
486
470
  **Then REFACTOR (quick pass, 5 min max):**
487
471
  - Extract duplicated code
488
- - Rename unclear variables
472
+ - Rename unclear variables
489
473
  - Simplify complex expressions
490
474
  - Remove dead code
491
475
 
@@ -514,32 +498,23 @@ Now implementing...
514
498
 
515
499
  ---
516
500
 
517
- **CRITICAL: Check if ALL speed mode chores are complete. Stable mode transition happens ONLY after all speed chores are done.**
518
-
519
- <!-- ┌─────────────────────────────────────────────────────────────────────────┐
520
- │ 🔍 COMPLETION CHECK: Speed Chores │
521
- │ │
522
- │ Progress Tracking: │
523
- │ • Query: Count incomplete speed chores for feature │
524
- │ • Display: "X speed mode chores remaining" or "All complete" │
525
- │ • Action: Generate stable scenarios/steps/chores if all complete │
526
- │ │
527
- │ Return Point: │
528
- │ • CHECKPOINT_CHORE_COUNT: Known incomplete count from last check │
529
- │ • If session interrupted, re-query to get current count │
530
- └─────────────────────────────────────────────────────────────────────────┘ -->
501
+ ### Step 6: Route After Chore Completion
502
+
503
+ **CRITICAL: After GREEN, check if more speed chores remain.**
531
504
 
532
505
  **Check for incomplete speed chores:**
533
506
 
534
507
  ```bash
535
- # Get current work to find parent feature ID
536
- sqlite3 .jettypod/work.db "SELECT wi.parent_id FROM work_items wi WHERE wi.status = 'in_progress'"
508
+ # Get current work to find parent feature ID and current chore ID
509
+ sqlite3 .jettypod/work.db "SELECT wi.id, wi.parent_id FROM work_items wi WHERE wi.status = 'in_progress'"
537
510
 
538
- # Get list of remaining speed chores (excluding current chore)
511
+ # Count remaining speed chores (excluding current)
539
512
  sqlite3 .jettypod/work.db "SELECT id, title FROM work_items WHERE parent_id = <feature-id> AND type = 'chore' AND mode = 'speed' AND status != 'done' AND id != <current-chore-id> ORDER BY created_at LIMIT 1"
540
513
  ```
541
514
 
542
- **If speed chores remain, display and start next chore:**
515
+ ---
516
+
517
+ **Route A: More speed chores remain → Start next chore**
543
518
 
544
519
  ```
545
520
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
@@ -552,237 +527,89 @@ More speed mode chores remain. Starting next chore:
552
527
  #[next-chore-id]: [next-chore-title]
553
528
  ```
554
529
 
555
- **Then immediately merge current chore and start next:**
530
+ **Merge and start next:**
556
531
 
557
532
  ```bash
558
533
  # Commit changes in the worktree
559
534
  git add . && git commit -m "feat: [brief description of what was implemented]"
560
535
 
561
- # Merge current chore - this automatically marks it as done
536
+ # Merge current chore (handles push, merge, cleanup)
562
537
  jettypod work merge
563
538
 
564
539
  # Start next speed chore
565
540
  jettypod work start [next-chore-id]
566
541
  ```
567
542
 
568
- **CRITICAL: Use ONLY `jettypod work merge` to complete chores.**
569
- - ❌ DO NOT use `jettypod work status <id> done`
570
- - ❌ DO NOT use `jettypod work complete <id>`
571
- - ❌ DO NOT use `jettypod work set-mode <id> done`
572
- - ✅ ONLY use `jettypod work merge`
573
-
574
- The merge command handles everything: pushes branch, merges to main, marks chore done, cleans up worktree.
575
-
576
543
  The speed-mode skill will automatically re-invoke for the next chore.
577
544
 
578
- **If all speed chores are done (count = 0), continue to Step 6 below.**
579
-
580
545
  ---
581
546
 
582
- ### Step 6: Transition to Stable Mode (After All Speed Chores Complete)
547
+ **Route B: All speed chores complete Transition to Step 7**
548
+
549
+ If the query returns no remaining chores, proceed to Step 7.
583
550
 
584
- **⚡ ASYNC BOUNDARY - Must wait for user to confirm proposed scenarios/chores**
551
+ ---
585
552
 
586
- **CRITICAL:** This step ONLY runs after ALL speed chores are complete. This is the transition from speed mode to stable mode.
553
+ ### Step 7: Transition to Stable Mode
587
554
 
588
- **Workflow: Merge last chore → Generate scenarios → Generate step definitions Propose chores Commit BDD files → Create chores Set mode to stable → Invoke stable-mode skill**
555
+ **🛑 CRITICAL: This step ONLY runs after ALL speed chores are complete.**
589
556
 
590
- #### Phase 1: Merge Final Speed Chore
557
+ This is the transition from speed mode to stable mode. Follow these phases in order.
591
558
 
592
- **Complete the current (final) speed chore:**
559
+ #### Step 7A: Merge Final Speed Chore
593
560
 
594
561
  ```bash
595
562
  # Commit changes in the worktree
596
563
  git add . && git commit -m "feat: [brief description of what was implemented]"
597
564
 
598
- # Merge to main with lock held for transition phase
599
- # This prevents race conditions when multiple instances generate BDD files simultaneously
565
+ # Merge with transition lock (prevents race conditions during BDD generation)
600
566
  jettypod work merge --with-transition
601
567
  ```
602
568
 
603
- <details>
604
- <summary>💡 Why --with-transition? (click to expand)</summary>
605
-
606
- The `--with-transition` flag holds the merge lock through the entire BDD generation phase (Phases 2-6).
569
+ After merge, you are on main branch. Ready to generate stable mode scenarios.
607
570
 
608
- **Without this flag:**
609
- - Instance A merges → generates BDD → appends to step_definitions/auth.steps.js
610
- - Instance B merges → generates BDD → appends to step_definitions/auth.steps.js (CONFLICT!)
611
- - Second write can overwrite first write, losing step definitions
571
+ #### Step 7B: Generate and Propose Stable Mode Chores
612
572
 
613
- **With this flag:**
614
- - Instance A acquires lock → merges → generates BDD → commits → releases lock
615
- - Instance B waits → acquires lock → merges → generates BDD → commits → releases lock
616
- - No conflicts, all step definitions preserved
617
-
618
- You'll release the lock in Phase 6 after committing BDD files.
619
- </details>
573
+ **⚡ ASYNC BOUNDARY - Must wait for user confirmation**
620
574
 
621
- **CRITICAL: Use ONLY `jettypod work merge` to complete chores.**
622
- - ❌ DO NOT use `jettypod work status <id> done`
623
- - ❌ DO NOT use `jettypod work complete <id>`
624
- - ❌ DO NOT use `jettypod work set-mode <id> done`
625
- - ✅ ONLY use `jettypod work merge`
626
-
627
- After merge, you are now on main branch. Ready to generate stable mode scenarios.
628
-
629
- #### Phase 2: Generate Stable Mode BDD Scenarios
630
-
631
- **Your task:** Create BDD scenarios for error handling, edge cases, and validation.
632
-
633
- **Read the feature's existing scenario file:**
575
+ **1. Read the feature's scenario file and analyze for stable mode needs:**
634
576
 
635
577
  ```bash
636
- # Find the feature's scenario file
637
- sqlite3 .jettypod/work.db "SELECT id, title FROM work_items WHERE id = <feature-id>"
638
- # Look for: features/bdd/<epic-slug>/<feature-slug>.feature
578
+ sqlite3 .jettypod/work.db "SELECT id, title, scenario_file FROM work_items WHERE id = <feature-id>"
639
579
  ```
640
580
 
641
- **Analysis checklist for new scenarios:**
642
-
643
- 1. **Error scenarios** - What can go wrong?
644
- - Invalid user input (wrong types, out of range, malformed data)
645
- - Missing required parameters
646
- - System errors (file not found, network errors, database errors)
647
- - Permission/authorization failures
648
-
649
- 2. **Edge case scenarios** - Boundary conditions
650
- - Empty inputs (empty strings, empty arrays, null values)
651
- - Maximum values (large numbers, long strings, many items)
652
- - Minimum values (zero, negative numbers)
653
- - Special characters and Unicode
654
-
655
- 3. **State consistency scenarios** - Data integrity
656
- - Concurrent operations (race conditions)
657
- - Partial failures (transaction rollbacks)
658
- - State transitions (invalid state changes)
659
-
660
- **Generate stable scenarios and append to feature file:**
661
-
662
- ```gherkin
663
- Scenario: Handle missing required parameter
664
- Given the system is initialized
665
- When I call the function with missing "name" parameter
666
- Then it should throw a validation error
667
- And the error message should be "Parameter 'name' is required"
668
-
669
- Scenario: Handle empty input
670
- Given the system is initialized
671
- When I provide an empty string as input
672
- Then it should return an appropriate error
673
- And the error code should be "INVALID_INPUT"
674
-
675
- Scenario: Handle maximum boundary value
676
- Given the system is initialized
677
- When I provide the maximum allowed value
678
- Then it should process successfully
679
- And return the expected result
680
- ```
581
+ **2. Generate stable mode BDD scenarios** covering:
582
+ - **Error scenarios** - Invalid input, missing params, system errors, permission failures
583
+ - **Edge cases** - Empty inputs, boundary values, special characters
584
+ - **State consistency** - Concurrent ops, partial failures, invalid state transitions
681
585
 
682
- **Append scenarios to the feature file** (don't overwrite existing speed scenarios):
586
+ **3. Append scenarios to the feature file:**
683
587
 
684
588
  ```bash
685
- # Append to existing .feature file
686
- cat >> features/bdd/<epic-slug>/<feature-slug>.feature << 'EOF'
589
+ cat >> <scenario-file-path> << 'EOF'
687
590
 
688
591
  # Stable Mode Scenarios - Error Handling and Edge Cases
689
592
 
690
- Scenario: [Title]
593
+ Scenario: [Error scenario title]
691
594
  Given [context]
692
- When [action]
693
- Then [expected behavior]
595
+ When [error condition]
596
+ Then [expected error handling]
694
597
 
695
- Scenario: [Title]
598
+ Scenario: [Edge case title]
696
599
  Given [context]
697
- When [action]
600
+ When [edge case input]
698
601
  Then [expected behavior]
699
602
  EOF
700
603
  ```
701
604
 
702
- #### Phase 3: Generate Stable Mode Step Definitions
703
-
704
- **Your task:** Create step definition files for the new stable scenarios.
605
+ **4. Create step definitions** at `features/step_definitions/<feature-slug>-stable.steps.js`
705
606
 
706
- **Identify new step definitions needed:**
607
+ **5. Present proposal to user:**
707
608
 
708
- 1. Read the stable scenarios you just created
709
- 2. Extract unique Given/When/Then steps
710
- 3. Check if step definitions already exist in `features/bdd/<epic-slug>/steps/`
711
- 4. Create new step definition files for missing steps
712
-
713
- **Generate step definition files:**
714
-
715
- ```javascript
716
- // features/bdd/<epic-slug>/steps/<feature-slug>-stable.steps.js
717
-
718
- const { Given, When, Then } = require('@cucumber/cucumber');
719
- const { expect } = require('chai');
720
-
721
- // Error handling steps
722
- When('I call the function with missing {string} parameter', async function(paramName) {
723
- try {
724
- // Implementation that calls function without parameter
725
- this.error = null;
726
- } catch (err) {
727
- this.error = err;
728
- }
729
- });
730
-
731
- Then('it should throw a validation error', function() {
732
- expect(this.error).to.exist;
733
- expect(this.error.name).to.equal('ValidationError');
734
- });
735
-
736
- Then('the error message should be {string}', function(expectedMessage) {
737
- expect(this.error.message).to.equal(expectedMessage);
738
- });
739
-
740
- // Edge case steps
741
- When('I provide an empty string as input', async function() {
742
- this.result = await this.functionUnderTest('');
743
- });
744
-
745
- When('I provide the maximum allowed value', async function() {
746
- this.result = await this.functionUnderTest(Number.MAX_SAFE_INTEGER);
747
- });
748
609
  ```
749
-
750
- **Create step definition files:**
751
-
752
- ```bash
753
- # Create the step definition file
754
- touch features/bdd/<epic-slug>/steps/<feature-slug>-stable.steps.js
755
- # Write the step definitions to the file
756
- ```
757
-
758
- #### Phase 4: Analyze Implementation and Propose Stable Mode Chores
759
-
760
- **Your task:** Based on the stable scenarios and step definitions, identify what needs to be implemented.
761
-
762
- **Analysis checklist:**
763
-
764
- 1. **Error handling gaps**
765
- - What validation needs to be added?
766
- - What error types need to be thrown?
767
- - What error messages need to be user-friendly?
768
-
769
- 2. **Edge case handling**
770
- - What boundary checks are needed?
771
- - What null/undefined checks are missing?
772
- - What type validation is needed?
773
-
774
- 3. **Code that needs refactoring**
775
- - What needs better structure for error handling?
776
- - What needs logging/debugging support?
777
- - What needs better separation of concerns?
778
-
779
- **Present your analysis:**
780
-
781
- ```
782
- 📋 Stable Mode Chores Proposal
610
+ 📋 Stable Mode Transition
783
611
 
784
612
  I've generated [N] stable mode scenarios covering error handling and edge cases.
785
- I've created step definitions for these scenarios.
786
613
 
787
614
  Here are the chores needed to make these scenarios pass:
788
615
 
@@ -796,96 +623,61 @@ Here are the chores needed to make these scenarios pass:
796
623
  - Scope: [What specifically needs to be done]
797
624
  - Scenarios: [Which BDD scenarios this addresses]
798
625
 
799
- **Chore 3: [Title]**
800
- - Why: [What gap this fills]
801
- - Scope: [What specifically needs to be done]
802
- - Scenarios: [Which BDD scenarios this addresses]
803
-
804
- These chores will make all stable mode scenarios pass with proper error handling and edge case coverage.
805
-
806
626
  Sound good? I'll create these chores once you confirm.
807
627
  ```
808
628
 
809
- **WAIT for user confirmation or adjustments.**
810
-
811
- If user adjusts: revise chores and confirm again.
812
-
813
- #### Phase 5: Create Chores Autonomously
814
-
815
- **CRITICAL:** After user confirms, create chores programmatically - no additional permission needed.
816
-
817
- **Code to create chores:**
818
-
819
- ```javascript
820
- const { create } = require('./features/work-tracking');
821
- const { getCurrentWork } = require('./lib/current-work');
629
+ **⚡ WAIT for user confirmation or adjustments.**
822
630
 
823
- (async () => {
824
- const currentWork = await getCurrentWork();
825
- const featureId = currentWork.parent_id; // Parent feature
631
+ #### Step 7C: Create Chores and Complete Transition
826
632
 
827
- // For each confirmed chore:
828
- await create('chore', 'Chore Title', 'Description', featureId, 'stable', false);
829
- })();
830
- ```
633
+ **After user confirms, execute autonomously:**
831
634
 
832
- **Display results:**
833
-
834
- ```
835
- ✅ Created [N] stable mode chores
635
+ **1. Create stable mode chores:**
836
636
 
837
- Chores created:
838
- #[ID]: [Title]
839
- • #[ID]: [Title]
840
- • #[ID]: [Title]
637
+ ```bash
638
+ jettypod work create chore "[Chore title]" "[Description with scenarios addressed]" --parent=<feature-id> --mode=stable
841
639
  ```
842
640
 
843
- #### Phase 6: Commit Stable Mode Scenarios and Steps to Main
641
+ Repeat for each confirmed chore.
844
642
 
845
- **CRITICAL: Commit the BDD files to main BEFORE starting stable chores.**
643
+ **2. Commit BDD files to main:**
846
644
 
847
645
  ```bash
848
- # You're currently on main after merging the last speed chore
849
- # Commit the stable mode scenarios and step definitions
850
646
  git add features/
851
647
  git commit -m "test: Add stable mode BDD scenarios and step definitions
852
648
 
853
- Added error handling and edge case scenarios for stable mode implementation.
854
-
649
+ Added error handling and edge case scenarios for stable mode.
855
650
  - [N] new stable mode scenarios
856
- - Step definitions for validation, error handling, and edge cases"
651
+ - Step definitions for validation and error handling"
857
652
 
858
- # Push to remote
859
653
  git push
860
-
861
- # Release the merge lock (held since Phase 1)
862
- jettypod work merge --release-lock
863
654
  ```
864
655
 
865
- This ensures stable mode BDD files are in main and will be present in stable chore worktrees.
866
-
867
- The merge lock is now released - other instances can proceed with their transitions.
656
+ **3. Release merge lock:**
868
657
 
869
- #### Phase 7: Set Feature Mode to Stable
658
+ ```bash
659
+ jettypod work merge --release-lock
660
+ ```
870
661
 
871
- **Set the feature mode:**
662
+ **4. Set feature mode to stable:**
872
663
 
873
664
  ```bash
874
665
  jettypod work set-mode <feature-id> stable
875
666
  ```
876
667
 
877
- #### Phase 8: Invoke Stable Mode Skill
668
+ #### Step 7D: Invoke Stable Mode Skill
878
669
 
879
- **CRITICAL: Immediately transition to stable-mode skill to start implementing stable chores.**
670
+ **🛑 CRITICAL HANDOFF - You MUST invoke stable-mode using the Skill tool.**
671
+
672
+ **Display completion message:**
880
673
 
881
674
  ```
882
675
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
883
676
  🎯 Speed Mode Complete! Transitioning to Stable Mode
884
677
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
885
678
 
886
- ⚠️ CRITICAL: Speed mode is ONLY a checkpoint to prove functionality works.
887
- The feature is INCOMPLETE without stable mode - error handling, validation,
888
- edge cases, and comprehensive testing are ALL required.
679
+ ⚠️ CRITICAL: Speed mode is ONLY a checkpoint.
680
+ The feature is INCOMPLETE without stable mode.
889
681
 
890
682
  What we accomplished:
891
683
  ✅ All speed mode chores complete
@@ -894,23 +686,13 @@ What we accomplished:
894
686
  ✅ Created [N] stable mode chores
895
687
  ✅ Feature mode set to stable
896
688
 
897
- 🚀 NEVER leave a feature in speed mode.
898
- Stable mode adds:
899
- • Comprehensive error handling and user-friendly error messages
900
- • Input validation (null checks, type checks, range validation)
901
- • Edge case handling (empty arrays, boundary values, race conditions)
902
- • State consistency and data integrity
903
- • All BDD scenarios passing (success scenarios + error/edge cases)
904
-
905
- **Next step:** I'm now invoking the stable-mode skill to start implementing the first stable chore.
689
+ 🚀 Now invoking stable-mode skill...
906
690
  ```
907
691
 
908
- **Invoke the stable-mode skill:**
909
-
910
- Use the Skill tool to automatically transition to stable mode implementation:
692
+ **Invoke stable-mode:**
911
693
 
912
694
  ```
913
- Skill tool with skill="stable-mode"
695
+ Use the Skill tool with skill: "stable-mode"
914
696
  ```
915
697
 
916
698
  The stable-mode skill will:
@@ -920,3 +702,44 @@ The stable-mode skill will:
920
702
 
921
703
  **End speed-mode skill.**
922
704
 
705
+ ---
706
+
707
+ ## Validation Checklist
708
+
709
+ Before ending speed-mode skill, ensure:
710
+ - [ ] All speed mode chores complete (GREEN on all success scenarios)
711
+ - [ ] Stable mode BDD scenarios generated and committed
712
+ - [ ] Step definitions created for stable scenarios
713
+ - [ ] Stable mode chores created
714
+ - [ ] Feature mode set to stable
715
+ - [ ] **stable-mode skill invoked using Skill tool**
716
+
717
+ ---
718
+
719
+ ## Command Reference
720
+
721
+ **Complete chores:**
722
+ ```bash
723
+ jettypod work merge # Merge current chore to main
724
+ jettypod work merge --with-transition # Hold lock for transition phase
725
+ jettypod work merge --release-lock # Release held lock
726
+ ```
727
+
728
+ **Start chores:**
729
+ ```bash
730
+ jettypod work start <chore-id> # Create worktree and start chore
731
+ ```
732
+
733
+ **Create chores:**
734
+ ```bash
735
+ jettypod work create chore "<title>" "<description>" --parent=<feature-id> --mode=stable
736
+ ```
737
+
738
+ **Set feature mode:**
739
+ ```bash
740
+ jettypod work set-mode <feature-id> stable
741
+ ```
742
+
743
+ **❌ DO NOT use these to complete chores:**
744
+ - `jettypod work status <id> done`
745
+ - `jettypod work complete <id>`