jettypod 4.4.98 → 4.4.100

package/lib/git-hooks/pre-commit

@@ -59,6 +59,12 @@ if (!checkBranchRestriction()) {
 
 // Export database snapshots (runs for all commits where .jettypod exists)
 async function exportSnapshots() {
+  // Skip in worktrees - snapshots only matter for commits on main
+  // Worktrees can't git add files from main repo ("outside repository" error)
+  if (process.cwd().includes('.jettypod-work')) {
+    return;
+  }
+
   const jettypodDir = path.join(process.cwd(), '.jettypod');
   if (!fs.existsSync(jettypodDir)) {
     return; // No JettyPod directory, skip export

package/lib/work-commands/index.js

@@ -1508,9 +1508,20 @@ async function mergeWork(options = {}) {
       return Promise.reject(new Error(`Failed to check git status: ${err.message}`));
     }
   
+    // Validate work item type BEFORE git operations
+    // Only chores, bugs, and test worktrees can be merged directly
+    const isTestWorktree = currentBranch.startsWith('tests/');
+    if (!isTestWorktree && !['chore', 'bug'].includes(currentWork.type)) {
+      return Promise.reject(new Error(
+        `Cannot merge ${currentWork.type} #${currentWork.id} directly.\n\n` +
+        `Only chores and bugs can be merged. Features complete when all their chores are done.\n` +
+        `Test worktrees (tests/* branches) merge BDD scenarios without completing the feature.`
+      ));
+    }
+
     console.log(`Merging work item #${currentWork.id}: ${currentWork.title}`);
     console.log(`Branch: ${currentBranch}`);
-  
+
     // Step 1: Push feature branch to remote
     // NOTE: Use ['pipe', 'inherit', 'inherit'] instead of 'inherit' to avoid stealing stdin
     // from Claude Code's shell. Using 'inherit' for stdin breaks the shell when run interactively.
@@ -1724,10 +1735,8 @@ async function mergeWork(options = {}) {
   
     console.log(`✓ Successfully merged work item #${currentWork.id}`);
 
-    // Check if this is a test worktree (tests/ prefix) - only set scenario_file, don't mark done
-    const isTestWorktree = currentBranch.startsWith('tests/');
-
     // Get worktree info from database (needed for cleanup message)
+    // Note: isTestWorktree was already set before git operations for early validation
     const worktree = await new Promise((resolve, reject) => {
       db.get(
         `SELECT id, worktree_path, branch_name FROM worktrees WHERE work_item_id = ? AND status = 'active'`,
@@ -1775,16 +1784,17 @@ async function mergeWork(options = {}) {
 
       console.log(`✅ BDD tests merged for feature #${currentWork.id}`);
       console.log('   Feature remains in discovery phase - create chores to continue');
-    } else if (currentWork.type !== 'chore') {
-      // Non-test branch for a non-chore - this shouldn't happen
+    } else if (!['chore', 'bug'].includes(currentWork.type)) {
+      // Non-test branch for a non-mergeable type - should have been caught by early validation
+      // but kept as defensive check
       return Promise.reject(new Error(
         `Cannot merge ${currentWork.type} #${currentWork.id} directly.\n\n` +
-        `Only chores can be merged. Features complete when all their chores are done.\n` +
+        `Only chores and bugs can be merged. Features complete when all their chores are done.\n` +
         `Test worktrees (tests/* branches) merge BDD scenarios without completing the feature.`
       ));
     } else {
-      // Chore worktree: mark as done (existing behavior)
-      console.log('Marking chore as done...');
+      // Chore or bug worktree: mark as done
+      console.log(`Marking ${currentWork.type} as done...`);
       const completedAt = new Date().toISOString();
       await new Promise((resolve, reject) => {
         db.run(
@@ -1796,7 +1806,7 @@ async function mergeWork(options = {}) {
           }
         );
       });
-      console.log(`✅ Chore #${currentWork.id} marked as done`);
+      console.log(`✅ ${currentWork.type.charAt(0).toUpperCase() + currentWork.type.slice(1)} #${currentWork.id} marked as done`);
     }
 
     // Mark worktree as merged but DON'T delete it yet

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jettypod",
-  "version": "4.4.98",
+  "version": "4.4.100",
   "description": "AI-powered development workflow manager with TDD, BDD, and automatic test generation",
   "main": "jettypod.js",
   "bin": {

package/skills-templates/chore-mode/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: chore-mode
-description: Guide implementation of standalone chores with type-appropriate guidance, verification steps, and test handling. Receives enriched context from chore-planning and executes with iteration until verification passes.
+description: Guide implementation of standalone chores with type-appropriate guidance, verification steps, and test handling. Receives enriched context from chore-planning and executes with iteration until verification passes. For chores under technical epics, receives context indicating no mode progression needed (already the default for all chores).
 ---
 
 # Chore Mode Skill
@@ -33,6 +33,7 @@ When this skill is activated, you are executing a standalone chore. The chore-pl
 - **Guided verification** - Use taxonomy verification checklist, not arbitrary checks
 - **Iteration with limits** - Max 5 iterations to achieve verification
 - **No mode progression** - Chores don't have speed/stable/production phases
+- **Technical epic awareness** - Acknowledge when a chore belongs to a technical epic (display indicator, confirm no mode progression)
 
 **Chore Types Quick Reference:**
 
@@ -80,6 +81,9 @@ You will receive:
 - `choreContext.classification` - Type and confidence
 - `choreContext.guidance` - Scope, verification, testHandling from taxonomy
 - `choreContext.implementationPlan` - Files to modify, affected tests
+- `choreContext.technicalEpic` - (optional) Technical epic context:
+  - `isTechnicalEpic: true/false` - Whether this chore belongs to a technical epic
+  - `skipModeProgression: true/false` - Whether to skip mode progression (always true for chores)
 
 **Display:**
 
@@ -96,6 +100,15 @@ Implementation Plan:
 • Affected tests: [list from context]
 ```
 
+**If `technicalEpic.isTechnicalEpic = true`:**
+
+Add this line after Chore ID:
+```
+⚡ Technical Epic Chore - no mode progression
+```
+
+This confirms the chore belongs to a technical epic and will execute directly without any speed→stable→production phases (which is the default for all chores anyway).
+
 **🔄 WORKFLOW INTEGRATION: Start workflow tracking**
 
 After receiving context, register this skill execution:

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

@@ -1,11 +1,11 @@
 ---
 name: chore-planning
-description: Guide standalone chore planning with automatic type classification and routing to chore-mode. Invoked by request-routing for substantial technical work - refactoring, infrastructure, migrations, or enhancements where the implementation approach is obvious. (project)
+description: Guide standalone chore planning with automatic type classification and routing to chore-mode. Invoked by request-routing for substantial technical work - refactoring, infrastructure, migrations, or enhancements where the implementation approach is obvious. For chores under technical epics, detects ancestry and passes context to chore-mode indicating no mode progression needed. (project)
 ---
 
 # Chore Planning Skill
 
-Guides Claude through standalone chore planning including automatic type classification, loading type-specific guidance from the taxonomy, building enriched context, and routing to chore-mode for execution.
+Guides Claude through standalone chore planning including automatic type classification, loading type-specific guidance from the taxonomy, building enriched context, and routing to chore-mode for execution. For chores under **technical epics**, detects this ancestry and passes context to skip mode progression.
 
 ## Instructions
 
@@ -18,6 +18,22 @@ You'll receive context about:
 - Project context
 - No parent feature (standalone chores don't have features)
 
+**⚡ FIRST: Detect Technical Epic Ancestry**
+
+Check if this chore belongs to a **technical epic** (an epic that creates chores directly without features):
+
+1. Check if the chore has a parent epic (not a feature)
+2. If it has a parent epic, check if that epic was created as a technical epic (detected by epic-planning based on refactor/migrate/infrastructure signals)
+
+**If chore belongs to a technical epic:**
+- Set `IS_TECHNICAL_EPIC = true`
+- Display: `⚡ Technical Epic Chore - no mode progression`
+- This context will be passed to chore-mode
+
+**If chore is standalone or under a regular epic:**
+- Set `IS_TECHNICAL_EPIC = false`
+- Proceed with normal flow
+
 Display:
 
 ```
@@ -180,12 +196,16 @@ const choreContext = {
     title: '[title]',
     description: '[description]',
     type: 'chore',
-    parent_id: null  // standalone
+    parent_id: null  // standalone, or epic_id if under technical epic
   },
   classification: {
     type: '[classified-type]',
     confidence: '[high/medium/low]'
   },
+  technicalEpic: {
+    isTechnicalEpic: true/false,  // from Step 1 detection
+    skipModeProgression: true/false  // same as isTechnicalEpic
+  },
   guidance: {
     scope: [...],
     verification: [...],
@@ -197,6 +217,8 @@ const choreContext = {
 };
 ```
 
+**Note:** If `technicalEpic.isTechnicalEpic = true`, chore-mode will skip mode progression (no speed→stable→production phases).
+
 ### Step 5: Analyze Codebase Impact
 
 Based on the chore type and guidance, analyze what needs to be done:
@@ -271,6 +293,15 @@ When user confirms (responds with "yes", "proceed", "let's go", etc.):
 Use the Skill tool with skill: "chore-mode"
 ```
 
+**Pass the technical epic context** in the skill arguments so chore-mode knows whether to skip mode progression:
+
+```
+Arguments should include:
+- choreContext (from Step 4)
+- technicalEpic.isTechnicalEpic = true/false
+- technicalEpic.skipModeProgression = true/false
+```
+
 The chore-mode skill will:
 1. Create a worktree for the chore
 2. Execute the implementation plan
@@ -297,6 +328,7 @@ This marks the `chore_planning_complete` gate as passed, enabling chore-mode to
 4. **Impact analysis** - Understand what the chore affects
 5. **Verification-focused** - Use type-specific verification criteria
 6. **Seamless handoff** - Route to chore-mode with full context
+7. **Technical epic awareness** - Detect when a chore belongs to a technical epic and pass this context to chore-mode so it skips mode progression (no speed→stable→production phases)
 
 ## Chore Type Quick Reference
 

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

@@ -1,11 +1,11 @@
 ---
 name: epic-planning
-description: Guide epic planning with feature brainstorming and optional architectural decision prototyping. Invoked by request-routing for large multi-feature initiatives that need to be broken down into features. (project)
+description: Guide epic planning with feature brainstorming and optional architectural decision prototyping. Invoked by request-routing for large multi-feature initiatives that need to be broken down into features. For technical epics (refactors, migrations, infrastructure), creates chores directly without features or mode progression. (project)
 ---
 
 # Epic Planning Skill
 
-Guides Claude through comprehensive epic planning including feature identification and architectural decisions.
+Guides Claude through comprehensive epic planning including feature identification and architectural decisions. For **technical epics**, skips feature brainstorming and creates chores directly.
 
 ## Instructions
 
@@ -17,6 +17,30 @@ When this skill is activated, you are helping plan an epic. Follow this structur
 
 ---
 
+**⚡ FIRST: Detect Technical Epic**
+
+Before proceeding, check if this is a **technical epic** by looking for these signals in the request or context passed from request-routing:
+
+| Technical Epic Signals |
+|------------------------|
+| refactor, migrate, infrastructure, technical debt |
+| + epic-scale words: "across all", "major", "entire", "large" |
+| No user-facing features mentioned |
+| Pure technical/engineering work |
+
+**If technical epic detected:**
+- Set `IS_TECHNICAL_EPIC = true`
+- Skip UX-focused questions in Scenario B
+- Will use Step 3B (Brainstorm Chores) instead of Step 3 (Brainstorm Features)
+- Will skip Steps 4-5 (Architectural Decision) - not needed for technical work
+- Will create chores in Step 6 instead of features
+
+**If NOT a technical epic:**
+- Set `IS_TECHNICAL_EPIC = false`
+- Follow normal feature-based flow
+
+---
+
 **Scenario A: Epic ID provided** (e.g., "plan epic #5", "help me with epic 42")
 
 Run this command to get epic context:
@@ -42,7 +66,28 @@ Proceed to Step 2.
 
 **Scenario B: Just an idea** (e.g., "I want to add real-time collab", "plan an epic for auth")
 
-User has only provided a sentence or vague concept. **DO NOT suggest features yet.**
+User has only provided a sentence or vague concept. **DO NOT suggest features/chores yet.**
+
+**If `IS_TECHNICAL_EPIC = true`:**
+
+Gather technical context. Ask 2-3 of the most relevant questions from:
+
+```
+I'd like to understand this technical epic better before suggesting chores.
+
+**Scope:**
+- What's the scope? (which modules/areas are affected?)
+- What's the end state? (what does "done" look like?)
+
+**Constraints:**
+- Any ordering dependencies? (must do X before Y?)
+- Any patterns to follow? (existing conventions, migration guides)
+
+**Verification:**
+- How will we know it's complete? (tests pass, no warnings, etc.)
+```
+
+**If `IS_TECHNICAL_EPIC = false`:**
 
 Gather context first. Ask 2-4 of the most relevant questions from:
 
@@ -81,7 +126,9 @@ jettypod workflow start epic-planning <epic-id>
 
 This creates an execution record for session resume.
 
-Proceed to Step 3 (skip Step 2 since nothing exists yet).
+Proceed to Step 2 if epic already exists, or:
+- **If `IS_TECHNICAL_EPIC = true`:** Proceed to Step 3B (Brainstorm Chores)
+- **If `IS_TECHNICAL_EPIC = false`:** Proceed to Step 3 (Brainstorm Features)
 
 ### Step 2: Check Existing State
 
@@ -102,9 +149,11 @@ Based on results, follow the appropriate path:
 
 ---
 
-**Path A: Nothing exists (no decisions AND no features)**
+**Path A: Nothing exists (no decisions AND no features/chores)**
 
-Fresh start. Proceed to Step 3 (Brainstorm Features).
+Fresh start.
+- **If `IS_TECHNICAL_EPIC = true`:** Proceed to Step 3B (Brainstorm Chores)
+- **If `IS_TECHNICAL_EPIC = false`:** Proceed to Step 3 (Brainstorm Features)
 
 ---
 
@@ -174,8 +223,37 @@ What features should we include? What am I missing?
 
 When user confirms features (says "looks good", "yes", lists modifications, etc.), finalize the feature list and proceed to Step 4.
 
+### Step 3B: Brainstorm Chores (Technical Epic)
+
+**Only used when `IS_TECHNICAL_EPIC = true`**
+
+Based on the technical epic's purpose, suggest chores that accomplish the work:
+
+```
+I'll help you plan the chores for this technical epic.
+
+Based on [epic name], here are the chores I recommend:
+
+**Chore 1: [Name]** - [Brief description of technical work]
+**Chore 2: [Name]** - [Brief description]
+**Chore 3: [Name]** - [Brief description]
+...
+
+**Ordering notes:**
+- [Any dependencies between chores]
+- [Suggested sequence if applicable]
+
+What chores should we include? What am I missing?
+```
+
+**WAIT for user response.**
+
+When user confirms chores (says "looks good", "yes", lists modifications, etc.), finalize the chore list and **skip directly to Step 6** (no architectural decision needed for technical epics).
+
 ### Step 4: Architectural Decision (Optional)
 
+**⚠️ SKIP THIS STEP if `IS_TECHNICAL_EPIC = true`** - Technical epics don't need architectural decisions. Go directly to Step 6.
+
 After features are defined, ask if this epic needs a shared technical approach.
 
 **Say to user:**
@@ -287,7 +365,7 @@ Set `ARCH_DECISION_MADE = false` and proceed directly to Step 6.
 
 ---
 
-### Step 6: Create Features
+### Step 6: Create Features or Chores
 
 **CRITICAL: Execute these commands with the Bash tool. Do NOT just display them.**
 
@@ -296,7 +374,31 @@ Set `ARCH_DECISION_MADE = false` and proceed directly to Step 6.
 jettypod backlog
 ```
 
-#### Step 6A: Create Each Feature
+---
+
+#### Step 6A: Create Items (Features OR Chores)
+
+**If `IS_TECHNICAL_EPIC = true`:** Create chores
+
+For each chore the user agreed on, execute this command:
+
+```bash
+jettypod work create chore "${CHORE_TITLE}" "${CHORE_DESCRIPTION}" --parent=${EPIC_ID}
+```
+
+**Example** (if epic ID is 5):
+```bash
+jettypod work create chore "Migrate auth module to ESM" "Convert require() to import in auth/" --parent=5
+```
+
+After each successful creation, tell the user:
+> ✅ Created Chore #[id from output]: [title]
+
+**Then skip to Step 7** (no architectural decision for technical epics).
+
+---
+
+**If `IS_TECHNICAL_EPIC = false`:** Create features
 
 For each feature the user agreed on, execute this command using the epic ID from Step 1:
 
@@ -387,6 +489,11 @@ Based on user response:
 **If user confirms (says "yes", "let's go", "proceed", etc.):**
 
 Determine the skill to invoke based on item type:
+
+**If `IS_TECHNICAL_EPIC = true`:**
+- **All items are chores** → always invoke `chore-planning`
+
+**If `IS_TECHNICAL_EPIC = false`:**
 - **Feature** → invoke `feature-planning`
 - **Chore** → invoke `chore-planning`
 
@@ -453,7 +560,7 @@ This marks the `epic_planning_complete` gate as passed. Features created under t
 
 ## Key Principles
 
-1. **Feature brainstorming is always required** - Don't skip this even if architectural decision is clear
+1. **Feature brainstorming is always required** - Don't skip this even if architectural decision is clear (for regular epics)
 2. **Architectural decision is optional** - Not all epics need one (e.g., "Q1 Goals" is just grouping)
 3. **Always suggest exactly 3 options** when architectural decision needed - Simple/Conservative, Balanced, Advanced
 4. **Be specific about features** - Each feature should be user-facing capability
@@ -461,6 +568,7 @@ This marks the `epic_planning_complete` gate as passed. Features created under t
 6. **Route to next skill** - After creating items, recommend one and invoke the appropriate planning skill
 7. **Use jettypod commands** - Create features using jettypod CLI, record decisions with epic-implement
 8. **Skill handoff** - Invoke `feature-planning` for features, `chore-planning` for chores
+9. **Technical epics are different** - They create chores directly (no features), skip architectural decisions, and always route to `chore-planning`. Chores under technical epics don't use mode progression (no speed→stable→production).
 
 ## Example: Epic with Architectural Decision
 
@@ -519,6 +627,37 @@ Epic: "User Management"
 
 **Architectural decision:** None needed - these are independent features using existing auth system
 
+## Example: Technical Epic (Chores Only)
+
+Epic: "Migrate Codebase from CommonJS to ESM"
+
+**Detection:** `IS_TECHNICAL_EPIC = true` (signals: "migrate", "codebase", no user-facing features)
+
+**Context questions asked:**
+- What's the scope? → "All JavaScript files in src/ and lib/"
+- What's the end state? → "All files use import/export, package.json has type:module"
+- Any ordering dependencies? → "Start with leaf modules, work up to entry points"
+
+**Chores brainstormed:**
+- Migrate utility modules (src/utils/)
+- Migrate lib/ modules
+- Migrate core business logic
+- Update build configuration
+- Update test configuration
+
+**Architectural decision:** Skipped (not needed for technical work)
+
+**Commands run:**
+```bash
+jettypod work create chore "Migrate utility modules" "Convert src/utils/ from require() to import" --parent=42
+jettypod work create chore "Migrate lib modules" "Convert lib/ from require() to import" --parent=42
+jettypod work create chore "Migrate core business logic" "Convert src/core/ from require() to import" --parent=42
+jettypod work create chore "Update build configuration" "Update webpack/rollup for ESM output" --parent=42
+jettypod work create chore "Update test configuration" "Update Jest config for ESM" --parent=42
+```
+
+**Routing:** All chores route to `chore-planning` → `chore-mode` (no mode progression)
+
 ## Validation
 
 Before completing epic planning, ensure:

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

@@ -13,16 +13,20 @@ When this skill is activated, you are helping discover the best approach for a f
 
 ## 🔑 Critical Command Distinction
 
-**Four different commands, four different purposes:**
+**Six commands in workflow order:**
 
 | Command | Used For | When | Phase |
 |---------|----------|------|-------|
+| `work prototype start <feature-id> [approach]` | Create worktree for UX prototyping | After UX approaches proposed (Step 4) | Feature Planning |
+| `work prototype merge <feature-id>` | Merge prototype to main | After user tests prototype (Step 4) | Feature Planning |
 | `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 tests merge` → `cd` → `work cleanup` | Merge tests to main, then cleanup worktree | After transition (Step 12) | 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 prototype start` = Creates isolated worktree for UX prototyping (Step 4, optional)
+- `work prototype merge` = Land prototype files on main (Step 4)
 - `work tests start` = Creates isolated worktree for BDD test authoring (Step 7)
 - `work implement` = Ends feature planning, transitions to implementation phase
 - `work tests merge` = Land BDD tests on main

package/skills-templates/request-routing/SKILL.md

@@ -31,6 +31,7 @@ From the user's request, identify work type and complexity signals:
 | Signal Words | Likely Route |
 |--------------|--------------|
 | fix, bug, broken, crash, error, not working, regression | bug-planning |
+| (refactor, migrate, infrastructure, technical debt) + (epic, large, across, all, major) | epic-planning (technical) |
 | refactor, rename, move, clean up, upgrade, migrate, infrastructure | chore-planning |
 | add, build, create, implement, new feature, capability, workflow | feature-planning |
 | epic, initiative, project, roadmap, multi-feature | epic-planning |
@@ -79,6 +80,12 @@ Contains bug/fix/broken/error signals?
      ├─► Yes → bug-planning
      │
      ▼
+Is this a large TECHNICAL initiative?
+(Refactor/migrate/infrastructure + epic-scale: "across all", "major", "entire")
+     ├─► Yes → epic-planning (technical)
+     │         (Creates chores directly, no features, no mode progression)
+     │
+     ▼
 Describes large multi-feature initiative?
      ├─► Yes → epic-planning
      │
@@ -109,6 +116,7 @@ Is this truly atomic?
 | Route | When to Use | Progression |
 |-------|-------------|-------------|
 | **bug-planning** | Something is broken/not working as expected | Investigation → fix |
+| **epic-planning (technical)** | Large technical initiative (refactor, migration, infrastructure) with no user-facing features | Break down → chores directly (no features, no modes) |
 | **epic-planning** | Large initiative spanning multiple features | Break down → plan features |
 | **feature-planning** | New behavior needing UX exploration OR has edge cases worth sequencing | UX exploration → BDD → speed → stable → production |
 | **chore-planning** | Substantial technical work, clear implementation | speed → stable → production |
@@ -121,11 +129,21 @@ Is this truly atomic?
 - "Getting a crash when I save"
 - "Users are seeing a 500 error"
 
+**→ epic-planning (technical)**
+- "Migrate the entire codebase from CommonJS to ESM"
+- "Refactor authentication across all modules"
+- "Major infrastructure overhaul for the API layer"
+- "Technical debt cleanup across the whole project"
+
+*(Technical work at epic scale - no user-facing features, just chores)*
+
 **→ epic-planning**
 - "We need a full authentication system"
 - "Build out the reporting dashboard"
 - "Plan the v2 API migration"
 
+*(User-facing initiatives with multiple features)*
+
 **→ feature-planning**
 - "Add drag-and-drop reordering for cards"
 - "Implement user notifications"
@@ -166,6 +184,12 @@ Sounds like a bug - [X] isn't working as expected. Let me help you investigate.
 ```
 Then invoke bug-planning skill.
 
+**Technical Epic:**
+```
+This is a large technical initiative - no user-facing features, just coordinated technical work. Let's break it down into chores.
+```
+Then invoke epic-planning skill with context indicating technical epic.
+
 **Epic:**
 ```
 This is a larger initiative with multiple features. Let's break it down.

package/skills-templates/simple-improvement/SKILL.md

@@ -192,10 +192,34 @@ Do NOT proceed to Step 3 until chore is successfully created.
 jettypod work start <chore-id>
 ```
 
+**🛑 STOP AND CHECK:** Verify worktree was created successfully before proceeding.
+
+```bash
+sqlite3 .jettypod/work.db "SELECT worktree_path FROM worktrees WHERE work_item_id = <chore-id> AND status = 'active'"
+```
+
+**If empty or error:** Stop and investigate. Do NOT proceed without a valid worktree.
+
+**Capture the worktree path:**
+- `WORKTREE_PATH` - the absolute path from the query result (e.g., `/path/to/.jettypod-work/42-fix-button-text`)
+
+**Display confirmation:**
+
+```
+📁 Worktree created: ${WORKTREE_PATH}
+
+From this point forward, ALL file operations MUST use paths starting with:
+${WORKTREE_PATH}/
+```
+
+**🔒 WORKTREE PATH LOCK:** Store `WORKTREE_PATH` - all file operations in this skill MUST use this path prefix.
+
+---
+
 **Then implement the change directly:**
 
-1. Read the file(s) that need modification
-2. Make the specific change requested
+1. Read the file(s) that need modification (using `${WORKTREE_PATH}/...`)
+2. Make the specific change requested (using `${WORKTREE_PATH}/...`)
 3. Verify the change looks correct
 
 **Display progress:**
@@ -203,7 +227,7 @@ jettypod work start <chore-id>
 ```
 📝 Implementing change...
 
-Modified: [file path]
+Modified: ${WORKTREE_PATH}/[relative path]
 Change: [what was changed]
 
 Verifying...
@@ -224,9 +248,11 @@ Verifying...
 
 **If verification passes:**
 
+**🔒 WORKTREE PATH REQUIRED:** Use the `WORKTREE_PATH` captured in Step 3.
+
 ```bash
 # Commit the change
-cd <worktree-path>
+cd ${WORKTREE_PATH}
 git add .
 git commit -m "fix: [brief description]