jettypod 4.4.116 → 4.4.120

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

@@ -18,7 +18,7 @@ You'll receive context about:
 - Project context
 - No parent feature (standalone chores don't have features)
 
-**⚡ FIRST: Detect Technical Epic Ancestry**
+**FIRST: Detect Technical Epic Ancestry**
 
 Check if this chore belongs to a **technical epic** (an epic that creates chores directly without features):
 
@@ -27,7 +27,7 @@ Check if this chore belongs to a **technical epic** (an epic that creates chores
 
 **If chore belongs to a technical epic:**
 - Set `IS_TECHNICAL_EPIC = true`
-- Display: `⚡ Technical Epic Chore - no mode progression`
+- Display: `Technical Epic Chore - no mode progression`
 - This context will be passed to chore-mode
 
 **If chore is standalone or under a regular epic:**
@@ -38,7 +38,7 @@ Display:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🔧 Planning Standalone Chore
+Planning Standalone Chore
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 **Chore:** [Title]
@@ -47,7 +47,7 @@ Display:
 Analyzing chore type...
 ```
 
-**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+**WORKFLOW INTEGRATION: Start workflow tracking**
 
 After understanding the chore context, register this skill execution:
 
@@ -71,9 +71,13 @@ Classify the chore by matching keywords in the title and description against the
 **Classification rules:**
 - Count keyword matches (exact word boundary matches = 2 points, partial = 1 point)
 - Highest score wins
-- Default to **refactor** if no matches
+- Default to **enhancement** if no matches (behavior-adding is the catch-all)
 - Confidence: high (4+ points), medium (2-3 points), low (0-1 points)
 
+**Category distinction:**
+- **Behavior-preserving** (refactor, dependency, cleanup, tooling): Has specific keywords. Runs existing affected tests only. Never writes new tests.
+- **Behavior-adding** (enhancement): The default when no behavior-preserving keywords match. Uses TDD red-green-refactor to write tests first, then implement.
+
 Display:
 
 ```
@@ -82,7 +86,7 @@ Display:
 
 **If confidence is low:**
 ```
-⚠️ Low confidence classification. The chore might be:
+Low confidence classification. The chore might be:
 - [type] - because [reason based on keywords found]
 - [alternative type] - if [alternative interpretation]
 
@@ -104,12 +108,12 @@ Based on the classified type, apply this guidance:
 - Consider breaking into smaller refactors if scope is large
 
 *Verification Criteria:*
-- All existing tests pass without modification
+- Affected tests pass without modification
 - No new functionality added (that requires new tests)
 - Code review confirms behavior preservation
 - Performance is not degraded
 
-*Test Handling:* Tests required. Run all tests for affected modules before and after. Update test file paths/imports if moved. Do NOT change test assertions - if tests fail, the refactor broke behavior.
+*Test Handling:* Tests required. Run tests for affected and potentially impacted modules. Update test file paths/imports if moved. Do NOT change test assertions - if tests fail, the refactor broke behavior.
 
 ---
 
@@ -122,12 +126,12 @@ Based on the classified type, apply this guidance:
 - Consider update strategy: one at a time vs batch
 
 *Verification Criteria:*
-- All tests pass after update
+- Affected and potentially impacted tests pass after update
 - Application builds successfully
 - No new deprecation warnings (or documented)
 - Security vulnerabilities addressed (if security update)
 
-*Test Handling:* Tests not required. Run full test suite to catch regressions. No new tests needed unless migrating to new API patterns. Document any test changes needed due to library API changes.
+*Test Handling:* Tests not required. Run tests for affected and potentially impacted modules to catch regressions. No new tests needed unless migrating to new API patterns. Document any test changes needed due to library API changes.
 
 ---
 
@@ -140,12 +144,12 @@ Based on the classified type, apply this guidance:
 - Consider impact on git history/blame
 
 *Verification Criteria:*
-- All tests still pass
+- Affected tests still pass
 - No broken imports or references
 - Application runs correctly
 - Removed code was actually unused
 
-*Test Handling:* Tests not required. Run existing tests to ensure nothing breaks. Remove tests only if they test deleted code. No new tests needed for cleanup work.
+*Test Handling:* Tests not required. Run tests for affected modules to ensure nothing breaks. Remove tests only if they test deleted code. No new tests needed for cleanup work.
 
 ---
 
@@ -167,11 +171,29 @@ Based on the classified type, apply this guidance:
 
 ---
 
+**ENHANCEMENT Guidance:**
+
+*Scope Considerations:*
+- Define what new behavior is being added
+- Identify where the behavior integrates with existing code
+- Plan test cases BEFORE writing implementation (TDD)
+- Keep scope focused - one behavior per chore
+
+*Verification Criteria:*
+- New tests written BEFORE implementation (TDD red phase)
+- All new tests pass (TDD green phase)
+- Code is clean and well-structured (TDD refactor phase)
+- Existing affected tests still pass
+
+*Test Handling:* Tests required - TDD mandatory. Write failing tests first that define the new behavior (RED), then implement minimum code to pass (GREEN), then refactor for cleanliness (REFACTOR). Run affected tests to ensure no regressions.
+
+---
+
 Display the relevant guidance:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📋 [Type] Chore Guidance
+[Type] Chore Guidance
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 **Scope Considerations:**
@@ -243,11 +265,17 @@ Based on the chore type and guidance, analyze what needs to be done:
 - Identify affected workflows
 - Review CI/CD impacts
 
+**For ENHANCEMENT chores:**
+- Identify what new behavior is being added
+- Find integration points with existing code
+- Plan test cases that define the new behavior
+- List affected existing test files
+
 Display analysis:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🔍 Impact Analysis
+Impact Analysis
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 **Files to modify:**
@@ -266,7 +294,7 @@ Based on the analysis, create a focused plan:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📝 Implementation Plan
+Implementation Plan
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 **Step 1:** [First action]
@@ -308,7 +336,7 @@ The chore-mode skill will:
 3. Run verification steps
 4. Merge when complete
 
-**🔄 WORKFLOW INTEGRATION: Complete workflow**
+**WORKFLOW INTEGRATION: Complete workflow**
 
 Before invoking chore-mode:
 
@@ -340,10 +368,11 @@ This marks the `chore_planning_complete` gate as passed, enabling chore-mode to
 
 | Type | Keywords | Test Handling |
 |------|----------|---------------|
-| refactor | refactor, restructure, extract, rename | Run all tests, don't modify assertions |
-| dependency | update, upgrade, bump, migrate | Run full suite, check for deprecations |
+| refactor | refactor, restructure, extract, rename | Run affected tests, don't modify assertions |
+| dependency | update, upgrade, bump, migrate | Run affected + impacted tests, check for deprecations |
 | cleanup | remove, delete, unused, legacy | Verify no references, run affected tests |
 | tooling | ci, build, lint, config | Run affected pipelines |
+| enhancement | *(default - no keyword match)* | TDD: write tests first, then implement |
 
 ## Validation
 

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

@@ -17,7 +17,7 @@ When this skill is activated, you are helping plan an epic. Follow this structur
 
 ---
 
-**⚡ FIRST: Detect Technical Epic**
+**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:
 
@@ -50,7 +50,7 @@ jettypod work status ${EPIC_ID}
 
 Capture the title, description, and any existing context.
 
-**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+**WORKFLOW INTEGRATION: Start workflow tracking**
 
 After getting the epic context, register this skill execution:
 
@@ -109,14 +109,23 @@ I'd like to understand this epic better before suggesting features.
 
 **WAIT for user answers.**
 
-Then synthesize into an epic title + description and create:
+Then synthesize into an epic title + description. Use the **Write** tool to create `/tmp/jettypod-create.json`:
+```json
+{
+  "type": "epic",
+  "title": "${EPIC_TITLE}",
+  "description": "${EPIC_DESCRIPTION}"
+}
+```
+
+Then run via **Bash**:
 ```bash
-jettypod work create epic "${EPIC_TITLE}" "${EPIC_DESCRIPTION}"
+jettypod work create --from=/tmp/jettypod-create.json
 ```
 
 Capture the new epic ID from output.
 
-**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+**WORKFLOW INTEGRATION: Start workflow tracking**
 
 After creating the epic, register this skill execution:
 
@@ -162,7 +171,7 @@ Fresh start.
 Previous planning was started but not completed. Present existing decisions:
 
 ```
-🎯 **Existing Architectural Decisions for This Epic:**
+**Existing Architectural Decisions for This Epic:**
 
 [For each decision:]
 - **[Aspect]:** [Decision]
@@ -181,7 +190,7 @@ Do these still apply, or should we revisit any?
 Planning was previously completed or partially completed. Present what exists:
 
 ```
-🎯 **This epic already has children:**
+**This epic already has children:**
 
 [List features/chores from children command]
 
@@ -252,7 +261,7 @@ When user confirms chores (says "looks good", "yes", lists modifications, etc.),
 
 ### 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.
+**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.
 
@@ -284,18 +293,18 @@ Present exactly 3 approaches. Fill in the bracketed parts with actual content ba
 > Here are 3 different architectural approaches for **[fill in epic title]**:
 >
 > **Option 1: [Simple approach - you fill this in]**
-> - **Pros**: ✅ [2-3 actual advantages]
-> - **Cons**: ❌ [2-3 actual trade-offs]
+> - **Pros**: [2-3 actual advantages]
+> - **Cons**: [2-3 actual trade-offs]
 > - **Technical Impact**: [How this affects the features]
 >
 > **Option 2: [Balanced approach - you fill this in]**
-> - **Pros**: ✅ [2-3 actual advantages]
-> - **Cons**: ❌ [2-3 actual trade-offs]
+> - **Pros**: [2-3 actual advantages]
+> - **Cons**: [2-3 actual trade-offs]
 > - **Technical Impact**: [How this affects the features]
 >
 > **Option 3: [Advanced approach - you fill this in]**
-> - **Pros**: ✅ [2-3 actual advantages]
-> - **Cons**: ❌ [2-3 actual trade-offs]
+> - **Pros**: [2-3 actual advantages]
+> - **Cons**: [2-3 actual trade-offs]
 > - **Technical Impact**: [How this affects the features]
 >
 > Would you like me to create working prototypes to compare these?
@@ -322,7 +331,7 @@ jettypod work prototype start 5 websockets
 
 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.
+**STOP AND CHECK:** Verify worktree was created successfully before proceeding.
 
 **Sub-step 2: Build prototypes in the worktree**
 
@@ -380,24 +389,30 @@ jettypod backlog
 
 **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}
+For each chore the user agreed on, use the **Write** tool to create `/tmp/jettypod-create.json`:
+```json
+{
+  "type": "chore",
+  "title": "${CHORE_TITLE}",
+  "description": "${CHORE_DESCRIPTION}",
+  "parent": ${EPIC_ID}
+}
 ```
 
-**Example** (if epic ID is 5):
+Then run via **Bash**:
 ```bash
-jettypod work create chore "Migrate auth module to ESM" "Convert require() to import in auth/" --parent=5
+jettypod work create --from=/tmp/jettypod-create.json
 ```
 
+**Example** (if epic ID is 5): Write `{"type":"chore","title":"Migrate auth module to ESM","description":"Convert require() to import in auth/","parent":5}` to `/tmp/jettypod-create.json`, then run `jettypod work create --from=/tmp/jettypod-create.json`.
+
 After each successful creation, emit gate signal and tell the user:
 
 ```bash
 jettypod ui gate work-created --data='{"id":[id],"title":"[chore title]"}'
 ```
 
-> ✅ Created Chore #[id from output]: [title]
+> Created Chore #[id from output]: [title]
 
 **Then skip to Step 7** (no architectural decision for technical epics).
 
@@ -405,24 +420,30 @@ jettypod ui gate work-created --data='{"id":[id],"title":"[chore title]"}'
 
 **If `IS_TECHNICAL_EPIC = false`:** Create features
 
-For each feature the user agreed on, execute this command using the epic ID from Step 1:
-
-```bash
-jettypod work create feature "${FEATURE_TITLE}" "${FEATURE_DESCRIPTION}" --parent=${EPIC_ID}
+For each feature the user agreed on, use the **Write** tool to create `/tmp/jettypod-create.json`:
+```json
+{
+  "type": "feature",
+  "title": "${FEATURE_TITLE}",
+  "description": "${FEATURE_DESCRIPTION}",
+  "parent": ${EPIC_ID}
+}
 ```
 
-**Example** (if epic ID is 5):
+Then run via **Bash**:
 ```bash
-jettypod work create feature "Live cursor tracking" "Track cursor positions in real-time" --parent=5
+jettypod work create --from=/tmp/jettypod-create.json
 ```
 
+**Example** (if epic ID is 5): Write `{"type":"feature","title":"Live cursor tracking","description":"Track cursor positions in real-time","parent":5}` to `/tmp/jettypod-create.json`, then run `jettypod work create --from=/tmp/jettypod-create.json`.
+
 After each successful creation, emit gate signal and tell the user:
 
 ```bash
 jettypod ui gate work-created --data='{"id":[id],"title":"[feature title]"}'
 ```
 
-> ✅ Created Feature #[id from output]: [title]
+> Created Feature #[id from output]: [title]
 
 #### Step 6B: Record Architectural Decision (Conditional)
 
@@ -455,7 +476,7 @@ jettypod work epic-implement 5 --aspect="Architecture" --decision="WebSockets wi
 ```
 
 After success, tell the user:
-> ✅ Architectural decision recorded
+> Architectural decision recorded
 
 ---
 
@@ -474,13 +495,13 @@ Based on the output, recommend which item to plan first.
 
 **Say to user:**
 > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-> 🎯 Epic Planning Complete!
+> Epic Planning Complete!
 > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 >
 > Created under this epic:
 > [List the actual items from the children command output]
 >
-> 💡 Recommendation: Start with Feature #[actual id] ([actual title])
+> Recommendation: Start with Feature #[actual id] ([actual title])
 >    [Your reasoning - e.g., "It's foundational - other features depend on it."]
 >
 > Plan this one now? [yes / pick different / done for now]
@@ -526,9 +547,9 @@ Display a numbered list of all created items:
 ```
 Which item would you like to plan?
 
-1. ✨ Feature #[id]: [title]
-2. ✨ Feature #[id]: [title]
-3. 🔧 Chore #[id]: [title]
+1. Feature #[id]: [title]
+2. Feature #[id]: [title]
+3. Chore #[id]: [title]
 
 Enter the number of your choice:
 ```
@@ -558,7 +579,7 @@ Chores:
 Or run: jettypod backlog to see all items.
 ```
 
-**🔄 WORKFLOW INTEGRATION: Complete workflow**
+**WORKFLOW INTEGRATION: Complete workflow**
 
 ```bash
 jettypod workflow complete epic-planning <epic-id>
@@ -593,18 +614,18 @@ Epic: "Real-time Collaboration"
 **Architectural approaches suggested:**
 
 **Option 1: Long Polling (REST)**
-- **Pros**: ✅ Simple, works with all proxies, uses existing HTTP infrastructure
-- **Cons**: ❌ Higher latency (1-2s), more server load, inefficient for high-frequency updates
+- **Pros**: Simple, works with all proxies, uses existing HTTP infrastructure
+- **Cons**: Higher latency (1-2s), more server load, inefficient for high-frequency updates
 - **Technical Impact**: Each feature polls independently, easy to implement per feature
 
 **Option 2: Server-Sent Events (SSE)**
-- **Pros**: ✅ Lightweight, auto-reconnection, efficient one-way streaming
-- **Cons**: ❌ One-direction only (server→client), limited browser connections (6 per domain)
+- **Pros**: Lightweight, auto-reconnection, efficient one-way streaming
+- **Cons**: One-direction only (server→client), limited browser connections (6 per domain)
 - **Technical Impact**: Good for cursor/presence, requires separate POST for edits
 
 **Option 3: WebSockets (Socket.io)**
-- **Pros**: ✅ Bidirectional, low latency (<100ms), perfect for real-time, fallback support
-- **Cons**: ❌ More complex infrastructure, requires sticky sessions, WebSocket proxies needed
+- **Pros**: Bidirectional, low latency (<100ms), perfect for real-time, fallback support
+- **Cons**: More complex infrastructure, requires sticky sessions, WebSocket proxies needed
 - **Technical Impact**: All features use unified connection, best UX but infrastructure complexity
 
 **Additional approaches considered:**
@@ -657,13 +678,12 @@ Epic: "Migrate Codebase from CommonJS to ESM"
 
 **Architectural decision:** Skipped (not needed for technical work)
 
-**Commands run:**
+**Commands run (Write tool + Bash for each):**
 ```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
+# For each chore: Write JSON to /tmp/jettypod-create.json, then:
+jettypod work create --from=/tmp/jettypod-create.json
+# Repeated for: Migrate utility modules, Migrate lib modules,
+# Migrate core business logic, Update build configuration, Update test configuration
 ```
 
 **Routing:** All chores route to `chore-planning` → `chore-mode` (no mode progression)