jettypod 4.4.94 → 4.4.96

package/skills-templates/feature-planning/SKILL.md

@@ -17,19 +17,20 @@ When this skill is activated, you are helping discover the best approach for a f
 
 | Command | Used For | When | Phase |
 |---------|----------|------|-------|
-| `work implement <feature-id>` | Transition feature to implementation phase | After chores created (Step 8C) | Feature Planning |
-| `work tests start <feature-id>` | Create worktree for test authoring | After transition (Step 8D) | Feature Planning |
-| `work tests merge` → `cd` → `work cleanup` | Merge tests to main, then cleanup worktree | After tests validated (Step 8D) | Feature Planning |
-| `work start <chore-id>` | Start implementing a specific chore | After tests merged (Step 8E) | Speed Mode |
+| `work tests start <feature-id>` | Create worktree for test authoring | After Integration Contract (Step 7) | Feature Planning |
+| `work tests merge` → `cd` → `work cleanup` | Merge tests to main, then cleanup worktree | After chores created (Step 12) | Feature Planning |
+| `work implement <feature-id>` | Transition feature to implementation phase | After chores created (Step 11) | Feature Planning |
+| `work start <chore-id>` | Start implementing a specific chore | After tests merged (Step 13) | Speed Mode |
 
 **CRITICAL:** All commands are run by **Claude**, not the user. The distinction is:
+- `work tests start` = Creates isolated worktree for BDD test authoring (Step 7)
 - `work implement` = Ends feature planning, transitions to implementation phase
-- `work tests start/merge` = Write and land BDD tests in isolated worktree
+- `work tests merge` = Land BDD tests on main
 - `work start` = Creates worktree/branch for chore implementation
 
-**🛑 STOP GATE:** DO NOT run `work start` until Step 8E. Tests must be merged to main first.
+**🛑 STOP GATE:** DO NOT run `work start` until Step 13. Tests must be merged to main first.
 
-**🛑 HANDOFF REQUIREMENT:** After `work start`, you MUST invoke speed-mode using the Skill tool. See Step 8E.
+**🛑 HANDOFF REQUIREMENT:** After `work start`, you MUST invoke speed-mode using the Skill tool. See Step 13.
 
 ---
 
@@ -141,7 +142,25 @@ Would you like me to create working prototypes of these approaches?
 
 If user wants prototypes:
 
-1. **Build prototypes** in `/prototypes/feature-[id]-[approach-name]/`
+**Sub-step 1: Create prototype worktree**
+
+```bash
+jettypod work prototype start ${FEATURE_ID} [approach-name]
+```
+
+Example:
+```bash
+jettypod work prototype start 42 simple-form
+```
+
+This creates a worktree at `.jettypod-work/prototype-<id>-<slug>-<approach>/` where prototypes can be safely built and committed.
+
+**🛑 STOP AND CHECK:** Verify worktree was created successfully before proceeding.
+
+**Sub-step 2: Build prototypes in the worktree**
+
+1. **Build prototypes** using **absolute paths** to the worktree:
+   - `<worktree_path>/prototypes/feature-[id]-[approach-name]/`
 2. **Name format**: `YYYY-MM-DD-[feature-slug]-[option].ext`
 3. **Focus on UX**: Show the feel, not production code
 4. **Add visible banner header at TOP of page** (for HTML/web prototypes):
@@ -156,10 +175,28 @@ If user wants prototypes:
    </div>
    ```
    For CLI/terminal prototypes, add similar info as first output.
-5. **Offer to open them**: "Want me to open these in your browser?"
+5. **Commit the prototype** in the worktree:
+   ```bash
+   cd <worktree_path>
+   git add .
+   git commit -m "Add prototype: [approach-name] for feature #${FEATURE_ID}"
+   ```
+6. **Offer to open them**: "Want me to open these in your browser?"
 
 **WAIT for user to test prototypes.**
 
+**Sub-step 3: Merge prototype after testing**
+
+After user has tested (regardless of whether they pick this approach):
+
+```bash
+jettypod work prototype merge ${FEATURE_ID}
+cd <main-repo-path>
+jettypod work cleanup ${FEATURE_ID}
+```
+
+This merges prototype files to main (in `/prototypes/` directory) and cleans up the worktree.
+
 <details>
 <summary><strong>📋 Prototyping Guidelines (click to expand)</strong></summary>
 
@@ -192,7 +229,7 @@ Which approach works best?
 
 **WAIT for user response.**
 
-User picks winner. Note their choice - you'll record it formally in Step 8 when transitioning to implementation.
+User picks winner. Note their choice - you'll record it formally in Step 11 when transitioning to implementation.
 
 **🔄 WORKFLOW CHECKPOINT: Winner chosen**
 
@@ -202,12 +239,10 @@ jettypod workflow checkpoint <feature-id> --step=5
 
 **Proceed to Step 6.**
 
-### Step 6: Define Integration Contract AND Generate BDD Scenarios
+### Step 6: Define Integration Contract
 
 **CRITICAL:** Before writing scenarios, you MUST define how users reach this feature. Features that pass tests but aren't integrated into the product are useless.
 
-#### Step 6A: Define Integration Contract
-
 **Ask yourself and document:**
 
 1. **Entry Point** - How does a user reach this feature?
@@ -243,17 +278,77 @@ Example:
 
 **WAIT for user to confirm or adjust the integration contract.**
 
-#### Step 6B: Propose BDD Scenarios (DO NOT WRITE YET)
+**Proceed to Step 7.**
+
+### Step 7: Create Test Worktree
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**CRITICAL:** Create the isolated worktree BEFORE proposing scenarios. This ensures:
+1. A safe workspace exists before any file discussion
+2. Claude has `WORKTREE_PATH` before being tempted to write files
+3. Writing to main is impossible because we're in worktree context
+
+**🚫 FORBIDDEN: Manual Git Worktree Commands**
+```
+❌ git worktree add ...
+❌ git checkout -b tests/...
+❌ git branch tests/...
+```
+**ALWAYS use jettypod commands** - they handle branch naming, path conventions, database tracking, and cleanup. Manual git commands will create orphaned worktrees that break the merge workflow.
+
+**Run:**
+
+```bash
+jettypod work tests start ${FEATURE_ID}
+```
+
+This creates:
+- Worktree at `.jettypod-work/tests-<id>-<slug>/`
+- Branch `tests/feature-<id>-<slug>`
+
+**🛑 STOP AND CHECK:** Verify worktree was created successfully. If you see an error, investigate before continuing.
+
+**Capture from output:**
+- `WORKTREE_PATH` - the absolute path to the worktree (e.g., `/path/to/.jettypod-work/tests-42-email-login`)
+
+Example output:
+```
+✅ Created test worktree: /path/to/.jettypod-work/tests-42-email-login
+Branch: tests/feature-42-email-login
+
+Write your BDD files to:
+  <worktree>/features/email-login.feature
+  <worktree>/features/step_definitions/email-login.steps.js
+```
+
+**Display:**
+
+```
+📁 Test worktree created: ${WORKTREE_PATH}
+Branch: tests/feature-${FEATURE_ID}-${FEATURE_SLUG}
+
+🔒 WORKTREE LOCK ACTIVE: All BDD file writes will use this path.
+```
+
+**🔒 WORKTREE PATH LOCK**
+
+From this point forward, ALL file operations for BDD tests MUST use paths starting with:
 ```
-❌ Write tool to features/*.feature
-❌ Write tool to features/step_definitions/*.js
-❌ Any file creation on main branch
+${WORKTREE_PATH}/features/
 ```
-**Files are written in Step 8D** inside an isolated worktree. At this step, you are ONLY displaying proposed scenarios to the user for confirmation. The worktree doesn't exist yet.
 
-**CRITICAL:** Do NOT write files yet. Display the proposed scenarios for user confirmation. Files will be written in Step 8D inside an isolated worktree.
+**Store `WORKTREE_PATH`** - you'll need it for Step 9.
+
+**Proceed to Step 8.**
+
+### Step 8: Propose BDD Scenarios
+
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to ${WORKTREE_PATH}/features/*.feature
+❌ Write tool to ${WORKTREE_PATH}/features/step_definitions/*.js
+❌ Any file creation (even in worktree)
+```
+**Files are written in Step 9** after user confirms the scenarios. At this step, you are ONLY displaying proposed scenarios to the user for confirmation.
 
 **Feature slug:** Derive `FEATURE_SLUG` from the feature title:
 - Lowercase
@@ -266,8 +361,8 @@ Based on chosen approach, **display** the proposed scenarios to the user:
 ```
 📋 Proposed BDD Scenarios
 
-**Feature file:** features/[feature-slug].feature
-**Step definitions:** features/step_definitions/[feature-slug].steps.js
+**Feature file:** ${WORKTREE_PATH}/features/[feature-slug].feature
+**Step definitions:** ${WORKTREE_PATH}/features/step_definitions/[feature-slug].steps.js
 ```
 
 Then show the full Gherkin content:
@@ -280,8 +375,8 @@ Feature: [Feature Name]
   Approach: [Chosen approach name]
 
   # Integration Contract:
-  # Entry Point: [from Step 6A]
-  # Caller Code: [from Step 6A]
+  # Entry Point: [from Step 6]
+  # Caller Code: [from Step 6]
 
 # INTEGRATION SCENARIO (REQUIRED - proves feature is reachable)
 Scenario: User can reach [feature] from [entry point]
@@ -318,7 +413,7 @@ Does this capture the feature correctly? Any scenarios to add/change?
 ```
 
 **Scenario content requirements:**
-- **FIRST scenario MUST be the Integration Scenario** from Step 6A (proves reachability)
+- **FIRST scenario MUST be the Integration Scenario** from Step 6 (proves reachability)
 - **Include all "make it work" scenarios**:
   - All success paths - required functionality AND optional features
   - Multiple valid workflows if the feature supports them
@@ -329,17 +424,17 @@ Does this capture the feature correctly? Any scenarios to add/change?
 
 **WAIT for user confirmation.**
 
-- If user confirms → Proceed to Step 7
+- If user confirms → Proceed to Step 9
 - If user requests changes → Revise scenarios and display again
-- **Store the confirmed scenarios in memory** - you'll write them in Step 8D
+- **Store the confirmed scenarios in memory** - you'll write them in Step 9
 
 **🔄 WORKFLOW CHECKPOINT: BDD scenarios confirmed**
 
 ```bash
-jettypod workflow checkpoint <feature-id> --step=6
+jettypod workflow checkpoint <feature-id> --step=8
 ```
 
-**Proceed to Step 7.**
+**Proceed to Step 9.**
 
 **Template for speed mode (make it work):**
 
@@ -351,8 +446,8 @@ Feature: [Feature Name]
   Approach: [Chosen approach name]
 
   # Integration Contract:
-  # Entry Point: [from Step 6A]
-  # Caller Code: [from Step 6A]
+  # Entry Point: [from Step 6]
+  # Caller Code: [from Step 6]
 
 # INTEGRATION SCENARIO (REQUIRED - proves feature is reachable)
 Scenario: User can reach [feature] from [entry point]
@@ -464,13 +559,94 @@ Scenario: Prevent unauthorized access
 
 </details>
 
-### Step 7: Propose Speed Mode Chores
+### Step 9: Write and Validate BDD Files
+
+**NOW you may write files** - the worktree exists (from Step 7) and scenarios are confirmed (from Step 8).
+
+**🔒 WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured in Step 7.
+
+Using the scenarios confirmed in Step 8, write the files using **absolute paths to the worktree**:
+
+**A. Write scenario file** using Write tool:
+```
+${WORKTREE_PATH}/features/${FEATURE_SLUG}.feature
+```
+
+**B. Write step definitions file** using Write tool:
+```
+${WORKTREE_PATH}/features/step_definitions/${FEATURE_SLUG}.steps.js
+```
+
+**Step definition requirements:**
+1. Implement all Given/When/Then steps from the scenarios
+2. Follow existing patterns - check other `.steps.js` files for conventions
+3. Include test environment setup/cleanup
+4. All Given steps (setup state)
+5. All When steps (execute actions)
+6. All Then steps (verify outcomes)
+
+**Validate BDD infrastructure:**
+
+Run cucumber dry-run **from within the worktree**:
+
+```bash
+cd ${WORKTREE_PATH} && npx cucumber-js --dry-run features/${FEATURE_SLUG}.feature
+```
+
+**What the output means:**
+
+✅ **Success** - No errors, all steps have definitions:
+```
+0 scenarios
+0 steps
+```
+(Dry-run doesn't execute, so 0 is correct)
+
+❌ **Undefined steps** - Missing step definitions:
+```
+Undefined. Implement with the following snippet:
+  Given('I am on the login page', function () {
+    ...
+  });
+```
+→ Add the missing step definition to your `.steps.js` file
 
-**CRITICAL:** After user confirms the BDD scenarios, analyze the codebase and propose technical implementation chores. **DO NOT CREATE CHORES YET** - the feature must transition to implementation mode first (Step 8).
+❌ **Syntax error** - Invalid Gherkin:
+```
+Parse error in features/foo.feature
+```
+→ Fix the feature file syntax
+
+❌ **Duplicate steps** - Multiple definitions match:
+```
+Multiple step definitions match
+```
+→ Remove or rename one of the duplicate step definitions
+
+**If validation fails:**
+1. Read the error message carefully
+2. Fix the step definitions or scenario file **in the worktree**
+3. Re-run the dry-run command
+4. **Loop until validation passes** - do NOT proceed until green
+
+**If validation succeeds:**
+Display: "✅ BDD infrastructure validated - all steps have definitions"
+
+**Update database with scenario file path:**
+
+```bash
+sqlite3 .jettypod/work.db "UPDATE work_items SET scenario_file = 'features/${FEATURE_SLUG}.feature' WHERE id = ${FEATURE_ID}"
+```
+
+**Proceed to Step 10.**
+
+### Step 10: Propose Speed Mode Chores
+
+**CRITICAL:** After BDD files are written and validated, analyze the codebase and propose technical implementation chores. **DO NOT CREATE CHORES YET** - the feature must transition to implementation mode first (Step 11).
 
 **Your analysis should consider:**
 - The BDD scenarios (integration + all success paths)
-- The Integration Contract from Step 6A
+- The Integration Contract from Step 6
 - Existing codebase structure and patterns
 - Epic's architectural decisions (if any)
 - Tech stack and framework conventions
@@ -480,7 +656,7 @@ Scenario: Prevent unauthorized access
 **REQUIRED: At least one chore MUST be an Integration Chore** that:
 - Wires the feature into the existing app
 - Makes the Integration Scenario pass
-- Modifies the caller code identified in Step 6A
+- Modifies the caller code identified in Step 6
 
 **Say to the user:**
 
@@ -494,7 +670,7 @@ Based on the scenario and my understanding of the codebase, here are the chores
 **Chore 1: [Integration chore - wire feature into app]** ⚡ INTEGRATION
 - Why: Makes the feature reachable from [entry point]
 - Integration Contract:
-  • Entry point: [from Step 6A]
+  • Entry point: [from Step 6]
   • Caller code to modify: [specific file/function]
 - Scenario steps addressed:
   • [Integration scenario Given/When/Then steps]
@@ -524,17 +700,17 @@ Sound good? Any adjustments?
 
 **WAIT for user response.**
 
-- If user confirms → Proceed to Step 8
+- If user confirms → Proceed to Step 11
 - If user requests changes → Revise chore proposals, then WAIT again
 - If user adds/removes chores → Update your list accordingly
 
-### Step 8: Transition to Implementation
+### Step 11: Rationale, Create Chores, and Transition
 
-Complete the discovery phase by transitioning the feature from discovery to implementation.
+Complete the discovery phase by recording the decision, creating chores, and transitioning the feature from discovery to implementation.
 
-**CRITICAL: You must EXECUTE the transition command using the Bash tool. Do NOT just display it as text.**
+**CRITICAL: You must EXECUTE commands using the Bash tool. Do NOT just display them as text.**
 
-#### Step 8A: Propose Rationale
+#### Sub-step A: Confirm Rationale
 
 Display to user:
 
@@ -549,11 +725,11 @@ Does this rationale capture why you chose this approach? (You can edit it if nee
 
 **WAIT for user to confirm or provide edited rationale.**
 
-#### Step 8B: Create the Chores
+#### Sub-step B: Create the Chores
 
 **CRITICAL: Create chores BEFORE running `work implement`.** The system validates that chores exist before allowing the transition.
 
-For each chore that the user confirmed in Step 7, use the Bash tool to create it:
+For each chore that the user confirmed in Step 10, use the Bash tool to create it:
 
 ```bash
 jettypod work create chore "[Chore title]" "[Chore description]" --parent=${FEATURE_ID}
@@ -564,24 +740,24 @@ Replace `${FEATURE_ID}` with actual ID. Example:
 jettypod work create chore "Set up auth routes" "Create login/logout endpoints..." --parent=42
 ```
 
-**CRITICAL: Copy the EXACT proposal from Step 7 into each chore description.** Do not paraphrase or summarize - the implementation guidance must be preserved verbatim:
+**CRITICAL: Copy the EXACT proposal from Step 10 into each chore description.** Do not paraphrase or summarize - the implementation guidance must be preserved verbatim:
 
 ```
-[Technical description from Step 7]
+[Technical description from Step 10]
 
 Scenario steps addressed:
-• [EXACT steps from Step 7]
+• [EXACT steps from Step 10]
 
 Implementation guidance:
-• Files to create/modify: [EXACT paths from Step 7]
-• Patterns to follow: [EXACT references from Step 7]
-• Key functions/components needed: [EXACT list from Step 7]
+• Files to create/modify: [EXACT paths from Step 10]
+• Patterns to follow: [EXACT references from Step 10]
+• Key functions/components needed: [EXACT list from Step 10]
 
 Verification:
-• [EXACT step definitions from Step 7]
+• [EXACT step definitions from Step 10]
 ```
 
-#### Step 8C: Execute Transition
+#### Sub-step C: Execute Transition
 
 **After ALL chores are created, use Bash tool to EXECUTE the work implement command:**
 
@@ -600,8 +776,8 @@ jettypod work implement 42 --winner="Simple inline form" --rationale="Fastest UX
 
 **If the command fails**, check the error message:
 - "Feature not found" → Verify the feature ID
-- "No chores exist" → You skipped Step 8B - go back and create chores first
-- "Already in implementation" → Feature was already transitioned, proceed to Step 8D
+- "No chores exist" → You skipped Sub-step B - go back and create chores first
+- "Already in implementation" → Feature was already transitioned, proceed to Step 12
 
 After successful transition, display:
 
@@ -609,134 +785,20 @@ After successful transition, display:
 ✅ Feature transitioned to implementation phase
 ✅ Created X chores for speed mode
 
-Now I'll write the BDD tests in an isolated worktree...
+Now I'll merge the BDD tests to main...
 ```
 
 **🔄 WORKFLOW CHECKPOINT: Implementation transition complete**
 
 ```bash
-jettypod workflow checkpoint <feature-id> --step=8
-```
-
-**Proceed to Step 8D.**
-
-#### Step 8D: Write Tests in Isolated Worktree
-
-**CRITICAL:** Tests are written in an isolated worktree, not directly on main. This ensures agent failures don't leave uncommitted garbage on main.
-
-**🚫 FORBIDDEN: Manual Git Worktree Commands**
-```
-❌ git worktree add ...
-❌ git checkout -b tests/...
-❌ git branch tests/...
-```
-**ALWAYS use jettypod commands** - they handle branch naming, path conventions, database tracking, and cleanup. Manual git commands will create orphaned worktrees that break the merge workflow.
-
-**Sub-step 1: Create test worktree**
-
-```bash
-jettypod work tests start ${FEATURE_ID}
-```
-
-This creates:
-- Worktree at `.jettypod-work/tests-<id>-<slug>/`
-- Branch `tests/feature-<id>-<slug>`
-
-**Capture the worktree path from output** - you'll need it for file operations.
-
-Example output:
-```
-✅ Created test worktree: /path/to/.jettypod-work/tests-42-email-login
-Branch: tests/feature-42-email-login
-
-Write your BDD files to:
-  <worktree>/features/email-login.feature
-  <worktree>/features/step_definitions/email-login.steps.js
-
-When done, merge then cleanup:
-  jettypod work tests merge 42
-  cd /path/to/main/repo
-  jettypod work cleanup 42
-```
-
-**🛑 STOP AND CHECK:** Verify worktree was created successfully. If you see an error, investigate before continuing.
-
-**Sub-step 2: Write BDD files in the worktree**
-
-Using the scenarios you confirmed in Step 6B, write the files using **absolute paths to the worktree**:
-
-**A. Write scenario file** using Write tool:
-```
-<worktree_path>/features/${FEATURE_SLUG}.feature
-```
-
-**B. Write step definitions file** using Write tool:
-```
-<worktree_path>/features/step_definitions/${FEATURE_SLUG}.steps.js
-```
-
-**Step definition requirements:**
-1. Implement all Given/When/Then steps from the scenarios
-2. Follow existing patterns - check other `.steps.js` files for conventions
-3. Include test environment setup/cleanup
-4. All Given steps (setup state)
-5. All When steps (execute actions)
-6. All Then steps (verify outcomes)
-
-**Sub-step 3: Validate BDD infrastructure**
-
-Run cucumber dry-run **from within the worktree**:
-
-```bash
-cd <worktree_path> && npx cucumber-js --dry-run features/${FEATURE_SLUG}.feature
-```
-
-**What the output means:**
-
-✅ **Success** - No errors, all steps have definitions:
-```
-0 scenarios
-0 steps
-```
-(Dry-run doesn't execute, so 0 is correct)
-
-❌ **Undefined steps** - Missing step definitions:
+jettypod workflow checkpoint <feature-id> --step=11
 ```
-Undefined. Implement with the following snippet:
-  Given('I am on the login page', function () {
-    ...
-  });
-```
-→ Add the missing step definition to your `.steps.js` file
-
-❌ **Syntax error** - Invalid Gherkin:
-```
-Parse error in features/foo.feature
-```
-→ Fix the feature file syntax
-
-❌ **Duplicate steps** - Multiple definitions match:
-```
-Multiple step definitions match
-```
-→ Remove or rename one of the duplicate step definitions
 
-**If validation fails:**
-1. Read the error message carefully
-2. Fix the step definitions or scenario file **in the worktree**
-3. Re-run the dry-run command
-4. **Loop until validation passes** - do NOT proceed until green
+**Proceed to Step 12.**
 
-**If validation succeeds:**
-Display: "✅ BDD infrastructure validated - all steps have definitions"
-
-**Sub-step 4: Update database with scenario file path**
-
-```bash
-sqlite3 .jettypod/work.db "UPDATE work_items SET scenario_file = 'features/${FEATURE_SLUG}.feature' WHERE id = ${FEATURE_ID}"
-```
+### Step 12: Merge Tests to Main
 
-**Sub-step 5: Merge tests to main**
+The BDD files were written in Step 9. Now merge them to main.
 
 **Merge and cleanup (3 steps):**
 
@@ -763,7 +825,7 @@ This will:
 - Mark worktree as merged (cleanup is separate)
 
 **🛑 STOP AND CHECK:** Verify merge succeeded:
-- ✅ "Tests merged to main" → Proceed to Step 8E
+- ✅ "Tests merged to main" → Proceed to Step 13
 - ❌ Error → Investigate, worktree still exists for debugging
 
 **After successful merge, display:**
@@ -796,9 +858,9 @@ jettypod workflow complete feature-planning <feature-id>
 
 This marks the `feature_planning_complete` gate as passed, enabling speed-mode to start.
 
-**Proceed to Step 8E.**
+**Proceed to Step 13.**
 
-#### Step 8E: Start First Chore
+### Step 13: Start First Chore
 
 **Feature planning is now complete.** The feature has been transitioned to implementation phase, tests are on main, and chores are ready.
 
@@ -921,15 +983,15 @@ Before completing feature planning, ensure:
 - [ ] Exactly 3 approaches suggested
 - [ ] Winner chosen (with prototypes or without)
 - [ ] **Integration Contract defined** (entry point, caller code, integration scenario)
+- [ ] **Test worktree created** with `work tests start` (Step 7)
 - [ ] **Integration Scenario is FIRST scenario** in proposed scenarios
-- [ ] BDD scenarios **proposed and confirmed** by user (Step 6B)
+- [ ] BDD scenarios **proposed and confirmed** by user (Step 8)
+- [ ] **BDD files written** in worktree using `WORKTREE_PATH` (Step 9)
+- [ ] **BDD infrastructure validated** with dry-run (Step 9)
 - [ ] **At least one Integration Chore proposed** (wires feature into app)
-- [ ] Speed mode chores proposed and confirmed (Step 7)
-- [ ] Chores created in database (Step 8B)
-- [ ] Feature transitioned to implementation with `work implement` (Step 8C)
-- [ ] **Test worktree created** with `work tests start` (Step 8D)
-- [ ] **BDD files written** in worktree (Step 8D)
-- [ ] **BDD infrastructure validated** with dry-run (Step 8D)
-- [ ] **Tests merged to main** with `work tests merge` → `cd` → `work cleanup` (Step 8D)
-- [ ] First chore started with `work start [chore-id]` (Step 8E)
-- [ ] **Speed-mode skill invoked using Skill tool** (Step 8E)
+- [ ] Speed mode chores proposed and confirmed (Step 10)
+- [ ] Chores created in database (Step 11)
+- [ ] Feature transitioned to implementation with `work implement` (Step 11)
+- [ ] **Tests merged to main** with `work tests merge` → `cd` → `work cleanup` (Step 12)
+- [ ] First chore started with `work start [chore-id]` (Step 13)
+- [ ] **Speed-mode skill invoked using Skill tool** (Step 13)