jettypod 4.4.118 → 4.4.121

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

@@ -30,7 +30,7 @@ When this skill is activated, you are helping implement a production mode chore
 
 ---
 
-## 🛑 PRE-FLIGHT VALIDATION (REQUIRED)
+## PRE-FLIGHT VALIDATION (REQUIRED)
 
 **Before proceeding with ANY implementation, you MUST validate the worktree exists.**
 
@@ -44,23 +44,23 @@ sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.status, wt.worktree_path,
 
 | worktree_path | What it means | Action |
 |---------------|---------------|--------|
-| **Has a path** (e.g., `/path/to/.jettypod-work/...`) | ✅ Worktree exists, ready to proceed | Continue to Step 0 |
-| **NULL or empty** | ❌ `work start` was not called | **STOP - run `jettypod work start [chore-id]` first** |
-| **No rows returned** | ❌ No chore is in progress | **STOP - verify the chore exists and run `work start`** |
+| **Has a path** (e.g., `/path/to/.jettypod-work/...`) | Worktree exists, ready to proceed | Continue to Step 0 |
+| **NULL or empty** | `work start` was not called | **STOP - run `jettypod work start [chore-id]` first** |
+| **No rows returned** | No chore is in progress | **STOP - verify the chore exists and run `work start`** |
 
-**🛑 STOP GATE:** If `worktree_path` is NULL or no rows returned, you MUST run `jettypod work start [chore-id]` before continuing. DO NOT proceed without a valid worktree.
+**STOP GATE:** If `worktree_path` is NULL or no rows returned, you MUST run `jettypod work start [chore-id]` before continuing. DO NOT proceed without a valid worktree.
 
-**🚫 FORBIDDEN: Manual Git Worktree Commands**
+**FORBIDDEN: Manual Git Worktree Commands**
 ```
-❌ git worktree add ...
-❌ git checkout -b feature/...
-❌ git branch feature/...
+git worktree add ...
+git checkout -b feature/...
+git branch feature/...
 ```
 **ALWAYS use `jettypod work start`** - it handles branch naming, path conventions, database tracking, and cleanup. Manual git commands will create orphaned worktrees that break the merge workflow.
 
 ---
 
-## 🔒 WORKTREE PATH LOCK
+## WORKTREE PATH LOCK
 
 **After pre-flight validation passes, capture and lock the worktree path:**
 
@@ -70,7 +70,7 @@ From the pre-flight query output, extract and store:
 **Display:**
 
 ```
-🔒 WORKTREE LOCK ACTIVE
+WORKTREE LOCK ACTIVE
 Path: ${WORKTREE_PATH}
 
 All file writes will use this path.
@@ -94,11 +94,11 @@ jettypod ui gate worktree-started --data='{"path":"${WORKTREE_PATH}"}'
 
 **MUST RUN FIRST:** Detect which scenario applies to this feature.
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to any path
-❌ Edit tool to any path
-❌ Any file creation or modification
+Write tool to any path
+Edit tool to any path
+Any file creation or modification
 ```
 **This is a DETECTION step.** File writes happen in Step 3.
 
@@ -120,7 +120,7 @@ sqlite3 .jettypod/work.db "SELECT completed_at FROM work_items WHERE parent_id =
 
 Based on these checks, determine which scenario applies.
 
-**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+**WORKFLOW INTEGRATION: Start workflow tracking**
 
 After detecting context, register this skill execution:
 
@@ -155,11 +155,11 @@ This validates that `stable_mode_complete` gate is passed and creates an executi
 
 **For all scenarios:** Read production standards file.
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to any path
-❌ Edit tool to any path
-❌ Any file creation or modification
+Write tool to any path
+Edit tool to any path
+Any file creation or modification
 ```
 **This is a READ step.** File writes happen in Step 3.
 
@@ -173,7 +173,7 @@ cat .jettypod/production-standards.json
 
 If the file doesn't exist, run external-transition first to generate production standards.
 
-**🔄 WORKFLOW CHECKPOINT: Standards read**
+**WORKFLOW CHECKPOINT: Standards read**
 
 ```bash
 jettypod workflow checkpoint <feature-id> --step=1
@@ -185,11 +185,11 @@ jettypod workflow checkpoint <feature-id> --step=1
 
 **For Scenario A only:** Quick validation of existing scenarios.
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to any path
-❌ Edit tool to any path
-❌ Any file creation or modification
+Write tool to any path
+Edit tool to any path
+Any file creation or modification
 ```
 **This is a VALIDATION step.** File writes happen in Step 3.
 
@@ -208,19 +208,19 @@ try {
   });
 
   if (!feature.scenario_file) {
-    console.error('❌ Feature has no scenario file.');
+    console.error('Feature has no scenario file.');
     return;
   }
 
   // Validate scenarios against standards
   const validation = await validateScenarios(feature.scenario_file, standards);
 
-  console.log(`✅ Validation complete:`);
+  console.log(`Validation complete:`);
   console.log(`  - Covered: ${validation.covered}/${validation.total} standards`);
   console.log(`  - Gaps: ${validation.gaps.length}`);
 
   if (validation.hasGaps) {
-    console.log('\n⚠️  Missing scenarios for:');
+    console.log('\n Missing scenarios for:');
     validation.gaps.forEach(gap => {
       console.log(`  - ${gap.domain}: ${gap.standardId}`);
       console.log(`    ${gap.reasoning}`);
@@ -234,12 +234,12 @@ try {
     const newScenarios = await generateScenariosFromStandards(missingStandards);
 
     await appendScenarios(feature.scenario_file, newScenarios);
-    console.log(`✅ Added ${newScenarios.length} missing scenarios`);
+    console.log(`Added ${newScenarios.length} missing scenarios`);
   } else {
-    console.log('✅ All standards are covered by existing scenarios');
+    console.log('All standards are covered by existing scenarios');
   }
 } catch (err) {
-  console.error('❌ Validation failed:', err.message);
+  console.error('Validation failed:', err.message);
   return;
 }
 ```
@@ -250,11 +250,11 @@ try {
 
 **For Scenario B only:** Re-validate with current standards.
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to any path
-❌ Edit tool to any path
-❌ Any file creation or modification
+Write tool to any path
+Edit tool to any path
+Any file creation or modification
 ```
 **This is a VALIDATION step.** File writes happen in Step 3.
 
@@ -263,7 +263,7 @@ const { validateScenarios } = require('../../lib/production-scenario-validator')
 const config = require('../../lib/config');
 
 try {
-  console.log('🔄 Re-validating scenarios against current standards...');
+  console.log('Re-validating scenarios against current standards...');
 
   // Check if project state changed
   const projectConfig = config.read();
@@ -281,12 +281,12 @@ try {
   // Validate scenarios
   const validation = await validateScenarios(feature.scenario_file, standards);
 
-  console.log(`✅ Re-validation complete:`);
+  console.log(`Re-validation complete:`);
   console.log(`  - Covered: ${validation.covered}/${validation.total} standards`);
   console.log(`  - New gaps: ${validation.gaps.length}`);
 
   if (validation.hasGaps) {
-    console.log('\n⚠️  Standards added/changed since last run:');
+    console.log('\n Standards added/changed since last run:');
     validation.gaps.forEach(gap => {
       console.log(`  - ${gap.domain}: ${gap.standardId}`);
     });
@@ -299,10 +299,10 @@ try {
     const newScenarios = await generateScenariosFromStandards(missingStandards);
 
     await appendScenarios(feature.scenario_file, newScenarios);
-    console.log(`✅ Updated with ${newScenarios.length} new scenarios`);
+    console.log(`Updated with ${newScenarios.length} new scenarios`);
   }
 } catch (err) {
-  console.error('❌ Re-validation failed:', err.message);
+  console.error('Re-validation failed:', err.message);
   return;
 }
 ```
@@ -313,11 +313,11 @@ try {
 
 **For Scenario C only:** Generate production scenarios from standards.
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to any path
-❌ Edit tool to any path
-❌ Any file creation or modification
+Write tool to any path
+Edit tool to any path
+Any file creation or modification
 ```
 **This is a GENERATION step (via jettypod commands, not direct file writes).** File writes happen in Step 3.
 
@@ -335,7 +335,7 @@ This will:
 3. Append scenarios to the feature file
 4. Create production chores
 
-**🔄 WORKFLOW CHECKPOINT: Scenarios validated/generated** (after any Step 2 variant)
+**WORKFLOW CHECKPOINT: Scenarios validated/generated** (after any Step 2 variant)
 
 ```bash
 jettypod workflow checkpoint <feature-id> --step=2
@@ -345,9 +345,9 @@ jettypod workflow checkpoint <feature-id> --step=2
 
 ### Step 3: Implement Production Chore
 
-**🔒 WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured after pre-flight validation.
+**WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured after pre-flight validation.
 
-**✅ NOW you may write files** - worktree is locked, context is detected.
+**NOW you may write files** - worktree is locked, context is detected.
 
 **Emit gate signal:**
 
@@ -373,7 +373,7 @@ Parse the chore description to find which scenario it addresses (look for "Scena
    npx cucumber-js <scenario-file> --name "<scenario-name>"
    ```
 
-   **🔄 WORKFLOW CHECKPOINT: RED baseline established**
+   **WORKFLOW CHECKPOINT: RED baseline established**
 
    ```bash
    jettypod workflow checkpoint <feature-id> --step=3
@@ -444,7 +444,27 @@ Once all production chores complete:
 2. Can be deployed to external environment
 3. Meets all standards for scale, security, compliance
 
-**🔄 WORKFLOW INTEGRATION: Complete workflow**
+**Prove It Works (REQUIRED):**
+
+Before completing the feature, demonstrate it works in practice — not just that tests pass.
+
+1. **Run or build the actual code** — compile, start the server, execute the command, or trigger the relevant workflow
+2. **Show real output** — display console output, build result, or observable behavior
+3. **Confirm it matches expectations** — verify the output is what was requested
+
+**Display:**
+
+```
+Verifying in practice...
+
+[Actual output from running/building the code]
+
+Verified: [what was confirmed]
+```
+
+**If the change cannot be run directly** (requires hardware, external service, or manual UI interaction), state what the user should verify manually and why you can't verify it yourself.
+
+**WORKFLOW INTEGRATION: Complete workflow**
 
 When all production chores are complete:
 

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

@@ -1,11 +1,11 @@
 ---
 name: request-routing
-description: "⚡ ENTRY POINT FOR ALL WORK REQUESTS. Invoke this skill FIRST when user describes ANY work - 'build X', 'fix Y', 'add Z', 'create feature', 'implement'. Do NOT create work items or invoke other planning skills directly. This skill analyzes intent and routes to the correct workflow. (project)"
+description: "ENTRY POINT FOR ALL WORK REQUESTS. Invoke this skill FIRST when user describes ANY work - 'build X', 'fix Y', 'add Z', 'create feature', 'implement'. Do NOT create work items or invoke other planning skills directly. This skill analyzes intent and routes to the correct workflow. (project)"
 ---
 
 # Request Routing Skill
 
-**⚡ UNIVERSAL ENTRY POINT** - This skill MUST be invoked FIRST when a user describes work they want done.
+**UNIVERSAL ENTRY POINT** - This skill MUST be invoked FIRST when a user describes work they want done.
 
 **DO NOT:**
 - Create work items (`jettypod work create`) before invoking this skill
@@ -121,7 +121,7 @@ Default → chore-planning
 | **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 |
+| **chore-planning** | Substantial technical work OR behavior-adding without edge cases | Type-specific verification → done (enhancement type uses TDD) |
 | **simple-improvement** | PURELY COSMETIC: text, copy, color, spacing changes only. No behavior change. | Direct implementation |
 
 ## Routing Examples
@@ -178,7 +178,7 @@ Default → chore-planning
 
 *(PURELY COSMETIC: only text, copy, color, spacing, or static visual changes. Zero behavior change.)*
 
-**⚠️ NOT simple-improvement (common mistakes):**
+**NOT simple-improvement (common mistakes):**
 - "Add a loading spinner to the save button" → **chore-planning** (adds behavior: state tracking, show/hide logic)
 - "Add a tooltip to the settings icon" → **chore-planning** (adds behavior: hover state, positioning)
 - "Track work item counts" → **feature-planning** (adds behavior: counting, state, display logic)

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

@@ -73,7 +73,7 @@ Use the description from the user's initial request (passed through request-rout
 I need more details. What specifically needs to change?
 ```
 
-**⚡ WAIT for user to clarify, then proceed.**
+**WAIT for user to clarify, then proceed.**
 
 **Otherwise, proceed directly with the clear description you already have.**
 
@@ -94,7 +94,7 @@ Scan the user's description for these patterns:
 | Multiple components | mentions 3+ different files/areas, "also need to" |
 | Architectural changes | "refactor", "restructure", "new system" |
 
-❌ **Route back to request-routing if ANY complexity signal detected:**
+**Route back to request-routing if ANY complexity signal detected:**
 - Any new behavior (even "small" behavior like a spinner or tooltip)
 - Any state management (loading, toggle, hover, selection)
 - New database tables/columns needed
@@ -103,7 +103,7 @@ Scan the user's description for these patterns:
 - Multiple interconnected changes
 - Need for error handling design
 
-✅ **Continue ONLY if the change is:**
+**Continue ONLY if the change is:**
 - Purely cosmetic (text, color, spacing, static visual appearance)
 - Single file or 2-3 related files
 - Modifying existing static values (not adding logic)
@@ -113,7 +113,7 @@ Scan the user's description for these patterns:
 **If too complex:**
 
 ```
-⚠️ This change appears to require new data models or architectural changes. This is more than a simple improvement.
+This change appears to require new data models or architectural changes. This is more than a simple improvement.
 
 I'm routing you back to request-routing for proper planning.
 ```
@@ -125,7 +125,7 @@ I'm routing you back to request-routing for proper planning.
 **If confirmed simple:**
 
 ```
-✅ Confirmed: This is a simple improvement.
+Confirmed: This is a simple improvement.
 
 Change: [summarize the specific change]
 Scope: [list files likely affected]
@@ -147,14 +147,22 @@ jettypod ui gate route-decided --data='{"route":"simple-improvement","title":"[b
 
 **Create a single chore with NO mode assigned.**
 
+Use the **Write** tool to create `/tmp/jettypod-create.json`:
+```json
+{
+  "type": "chore",
+  "title": "[Brief description of the change]",
+  "description": "[Detailed description including:\n- What to change\n- Where to change it\n- Expected outcome]",
+  "parent": <feature-id>
+}
+```
+
+Then run via **Bash**:
 ```bash
-jettypod work create chore "[Brief description of the change]" "[Detailed description including:
-- What to change
-- Where to change it
-- Expected outcome]" --parent=<feature-id>
+jettypod work create --from=/tmp/jettypod-create.json
 ```
 
-**IMPORTANT:** Do NOT use `--mode` flag. Simple improvements don't use speed/stable modes.
+**IMPORTANT:** Do NOT add a `mode` field. Simple improvements don't use speed/stable modes.
 
 **Emit gate signal:**
 
@@ -165,7 +173,7 @@ jettypod ui gate work-created --data='{"id":[chore-id],"title":"[title]"}'
 **Display to user:**
 
 ```
-✅ Created Chore #[id]: [title]
+Created Chore #[id]: [title]
 
 Ready to implement. Starting chore...
 ```
@@ -175,7 +183,7 @@ Ready to implement. Starting chore...
 When the `jettypod work create` command fails, display error details and suggest recovery:
 
 ```
-❌ Failed to create chore: [error message] ([error code if available])
+Failed to create chore: [error message] ([error code if available])
 
 This could be caused by:
 • Database is locked by another process
@@ -189,7 +197,7 @@ Suggested actions:
 4. If persistent, try: jettypod work cleanup --all
 ```
 
-**⚡ WAIT for user to acknowledge before retrying or investigating further.**
+**WAIT for user to acknowledge before retrying or investigating further.**
 
 Do NOT proceed to Step 3 until chore is successfully created.
 
@@ -205,7 +213,7 @@ 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.
+**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'"
@@ -225,13 +233,13 @@ jettypod ui gate worktree-started --data='{"path":"${WORKTREE_PATH}"}'
 **Display confirmation:**
 
 ```
-📁 Worktree created: ${WORKTREE_PATH}
+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.
+**WORKTREE PATH LOCK:** Store `WORKTREE_PATH` - all file operations in this skill MUST use this path prefix.
 
 ---
 
@@ -250,7 +258,7 @@ jettypod ui gate implementing --data='{"description":"[what is being changed]","
 **Display progress:**
 
 ```
-📝 Implementing change...
+Implementing change...
 
 Modified: ${WORKTREE_PATH}/[relative path]
 Change: [what was changed]
@@ -273,7 +281,27 @@ Verifying...
 
 **If verification passes:**
 
-**🔒 WORKTREE PATH REQUIRED:** Use the `WORKTREE_PATH` captured in Step 3.
+**Prove It Works (REQUIRED):**
+
+Before committing, demonstrate the change works in practice.
+
+1. **Run or build the actual code** — compile, start the server, execute the command, or trigger the relevant workflow
+2. **Show real output** — display console output, build result, or observable behavior
+3. **Confirm it matches expectations** — verify the output is what was requested
+
+**Display:**
+
+```
+Verifying in practice...
+
+[Actual output from running/building the code]
+
+Verified: [what was confirmed]
+```
+
+**If the change cannot be run directly** (requires hardware, external service, or manual UI interaction), state what the user should verify manually and why you can't verify it yourself.
+
+**WORKTREE PATH REQUIRED:** Use the `WORKTREE_PATH` captured in Step 3.
 
 ```bash
 # Commit the change
@@ -281,14 +309,14 @@ cd ${WORKTREE_PATH}
 git add .
 git commit -m "fix: [brief description]
 
-🤖 Generated with [Claude Code](https://claude.com/claude-code)
+Generated with [Claude Code](https://claude.com/claude-code)
 
 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
 ```
 
 **Then merge (CRITICAL: run as separate Bash calls):**
 
-⚠️ Shell CWD persists. You MUST run `cd` as a SEPARATE Bash tool call before merge.
+Shell CWD persists. You MUST run `cd` as a SEPARATE Bash tool call before merge.
 
 ```bash
 # Bash call 1: Change to main repo
@@ -301,17 +329,19 @@ jettypod work merge <chore-id>
 jettypod work cleanup <chore-id>
 ```
 
-**If merge fails:**
+**If merge fails with `Uncommitted changes detected`:** `git stash` from main repo CWD → create a work item for the stashed changes → `jettypod work start <id>` → `git stash pop` in that worktree → commit → merge → cleanup → then retry your original merge.
+
+**If merge fails with merge conflicts:**
 
-When `jettypod work merge` encounters an error (e.g., merge conflicts), the worktree is preserved for debugging.
+When `jettypod work merge` encounters a merge conflict, the worktree is preserved for debugging.
 
 ```
-❌ Merge failed: [error message from git]
+Merge failed: [error message from git]
 
 Conflicting files:
 • [list conflicting files if available]
 
-⚠️ IMPORTANT: The worktree has been PRESERVED for debugging at:
+IMPORTANT: The worktree has been PRESERVED for debugging at:
    [worktree-path]
 
 Resolution steps:
@@ -325,13 +355,28 @@ Resolution steps:
 Need help? Run: git status (in worktree) to see conflict status
 ```
 
-**⚡ WAIT for user to resolve conflicts before retrying.**
+**WAIT for user to resolve conflicts before retrying.**
 
 Do NOT attempt to auto-resolve conflicts - let the user handle them manually.
 
 **The merge command automatically sets the feature as ready for review.**
 It will appear with accept/reject buttons on the kanban board. Do NOT call `jettypod work status <feature-id> done` — that bypasses the review gate.
 
+**Generate QA checklist:**
+
+Based on the change you just made, generate specific QA steps a tester can verify manually. Write a JSON array to `/tmp/qa-steps.json`:
+```json
+[
+  {"section": "Section Name", "text": "Action to perform and expected result", "detail": "Additional context"},
+  ...
+]
+```
+Be specific (e.g., "Click the Save button — confirmation toast appears") not generic. 3-8 steps for simple improvements.
+
+```bash
+jettypod work set-qa-steps <chore-id> --from=/tmp/qa-steps.json
+```
+
 **Emit gate signal:**
 
 ```bash
@@ -342,7 +387,7 @@ jettypod ui gate complete --data='{"summary":"[what was changed]","files":["[fil
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-✅ Simple Improvement Complete!
+Simple Improvement Complete!
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 Change: [what was changed]
@@ -371,8 +416,8 @@ No further action needed.
 ## Command Reference
 
 ```bash
-# Create chore (no mode)
-jettypod work create chore "<title>" "<description>" --parent=<feature-id>
+# Create chore (no mode) - use Write tool for JSON, then:
+jettypod work create --from=/tmp/jettypod-create.json
 
 # Start chore
 jettypod work start <chore-id>
@@ -384,5 +429,5 @@ jettypod work merge <chore-id>      # Bash call 2
 # Cleanup
 jettypod work cleanup <chore-id>
 
-# ⚠️ Do NOT mark feature done manually — merge sets the review gate automatically
+# Do NOT mark feature done manually — merge sets the review gate automatically
 ```