jettypod 4.4.116 → 4.4.120

package/skills-templates/external-transition/SKILL.md

@@ -31,7 +31,7 @@ Say to the user:
 ```
 You're ready to transition to external state. Here's what that means:
 
-🏗️  **Infrastructure Work Items Will Be Created:**
+ **Infrastructure Work Items Will Be Created:**
 
 I'll create an "Infrastructure Readiness" epic with 15 work items across 4 categories:
 
@@ -58,7 +58,7 @@ I'll create an "Infrastructure Readiness" epic with 15 work items across 4 categ
   - Data retention policy
   - Security headers implemented
 
-📦 **Production Chores Will Be Generated:**
+**Production Chores Will Be Generated:**
 
 For each feature currently in stable mode, I'll:
   • Generate production scenarios from your chosen standards
@@ -68,7 +68,7 @@ For each feature currently in stable mode, I'll:
 
 This uses your feature's BDD scenarios as context for what needs hardening.
 
-⚠️  **Mode Requirement Changes:**
+ **Mode Requirement Changes:**
 
 After this transition, ALL customer-facing features MUST be built through Production mode (not Stable).
 
@@ -83,7 +83,7 @@ Ready to proceed? (yes/no)
 
 Wait for the user to respond with "yes" or similar affirmative response.
 
-**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+**WORKFLOW INTEGRATION: Start workflow tracking**
 
 After receiving initial confirmation, register this skill execution:
 
@@ -103,67 +103,67 @@ After user confirms, explain production standards and show preset options:
 Before we transition, let's establish your production standards. These define what "production-ready" means for your project and will guide all future production work.
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📋 Choose Your Production Standards Preset
+Choose Your Production Standards Preset
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-🚀 **Startup MVP**
+**Startup MVP**
 Early-stage products, internal tools going external, prototypes with first users
 
 Examples: Beta SaaS with first 20 customers, internal tool opened to partners, developer tool in early access, side project gaining traction
 
 What you get:
-  ✅ HTTPS/TLS, basic auth, structured logging
-  ✅ Health checks, daily backups (24h RPO)
-  ✅ Single region, 2 instances, 99.0% SLO
-  ❌ No 24/7 on-call, no multi-region
+  HTTPS/TLS, basic auth, structured logging
+  Health checks, daily backups (24h RPO)
+  Single region, 2 instances, 99.0% SLO
+  No 24/7 on-call, no multi-region
 
 Cost: $200–$500/mo | Time: 1–2 weeks
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-🏢 **Production SaaS**
+**Production SaaS**
 Established SaaS with paying customers, revenue dependency, uptime expectations
 
 Examples: B2B SaaS with annual contracts, consumer app with 5k DAU, API service with enterprise customers, e-commerce platform
 
 What you get:
-  ✅ WAF + rate limiting, OAuth/OIDC
-  ✅ APM with SLO dashboards, PII sanitization
-  ✅ Zero-downtime deployments, 15min backups
-  ✅ Multi-AZ, on-call rotation, 99.9% SLO
-  ⚠️ Single region (multi-region optional)
+  WAF + rate limiting, OAuth/OIDC
+  APM with SLO dashboards, PII sanitization
+  Zero-downtime deployments, 15min backups
+  Multi-AZ, on-call rotation, 99.9% SLO
+  Single region (multi-region optional)
 
 Cost: $1.5k–$4k/mo infra + $2k–$3k/mo ops | Time: 4–6 weeks
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-🏛️ **Enterprise**
+**Enterprise**
 Mission-critical systems, large customer base with strict SLAs, Fortune 500 customers
 
 Examples: Enterprise SaaS for F500, financial services platform, infrastructure/DevOps tooling, global marketplace
 
 What you get:
-  ✅ Everything in Production SaaS, plus:
-  ✅ Multi-region active-passive or active-active
-  ✅ Advanced DDoS, mTLS, per-tenant encryption
-  ✅ SOC2 Type II ready, chaos engineering
-  ✅ PITR backups (1min RPO), 99.95% SLO
+  Everything in Production SaaS, plus:
+  Multi-region active-passive or active-active
+  Advanced DDoS, mTLS, per-tenant encryption
+  SOC2 Type II ready, chaos engineering
+  PITR backups (1min RPO), 99.95% SLO
 
 Cost: $5k–$15k/mo infra + $4k–$8k/mo ops | Time: 8–12 weeks
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-🏥 **Regulated (Healthcare, Finance, Gov)**
+**Regulated (Healthcare, Finance, Gov)**
 Products handling PHI, PCI, FedRAMP - strict compliance mandates, legal liability
 
 Examples: Healthcare app (HIPAA), fintech/payments (PCI), government contractor (FedRAMP), legal tech, HR platform
 
 What you get:
-  ✅ Everything in Enterprise, plus:
-  ✅ HIPAA/PCI/FedRAMP compliance controls
-  ✅ Encryption at rest/in transit, MFA, PAM
-  ✅ Quarterly pentesting, annual audits
-  ✅ Real-time replication, 99.99% SLO
+  Everything in Enterprise, plus:
+  HIPAA/PCI/FedRAMP compliance controls
+  Encryption at rest/in transit, MFA, PAM
+  Quarterly pentesting, annual audits
+  Real-time replication, 99.99% SLO
 
 Cost: $10k–$30k/mo infra + $6k–$12k/mo ops + $20k–$50k/yr audits | Time: 12–24 weeks
 
@@ -236,7 +236,7 @@ Then show recommendations to the user:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📋 Recommended Production Standards
+Recommended Production Standards
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 Based on:
@@ -250,33 +250,33 @@ Based on:
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-✅ SECURITY ([X] standards)
+SECURITY ([X] standards)
 
-  [✓] TLS/HTTPS enforcement
+  [] TLS/HTTPS enforcement
       Why: [reasoning]
       Test: [acceptance criteria]
 
-  [✓] [Other security standards...]
+  [] [Other security standards...]
 
-✅ PERFORMANCE & SCALE ([X] standards)
+PERFORMANCE & SCALE ([X] standards)
 
-  [✓] Performance budgets
+  [] Performance budgets
       Why: [reasoning]
       Test: [acceptance criteria]
 
-  [✓] [Other scale standards...]
+  [] [Other scale standards...]
 
-✅ COMPLIANCE ([X] standards)
+COMPLIANCE ([X] standards)
 
-  [✓] [Compliance standards if applicable]
+  [] [Compliance standards if applicable]
 
-✅ INFRASTRUCTURE ([X] standards)
+INFRASTRUCTURE ([X] standards)
 
-  [✓] [Infrastructure standards]
+  [] [Infrastructure standards]
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-💰 Estimated Cost: $[X]–$[Y]/mo
+Estimated Cost: $[X]–$[Y]/mo
 
   Infrastructure: $[range]
   Operations: $[range]
@@ -284,7 +284,7 @@ Based on:
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-⚠️  Warnings (if any)
+ Warnings (if any)
 
   • [Warning messages for edge cases]
 
@@ -325,12 +325,12 @@ saveStandards(generatedStandards);
 Then confirm to user:
 
 ```
-✅ Production standards saved to .jettypod/production-standards.json
+Production standards saved to .jettypod/production-standards.json
 
 These standards will guide all production mode work going forward.
 ```
 
-**🔄 WORKFLOW CHECKPOINT: Standards saved**
+**WORKFLOW CHECKPOINT: Standards saved**
 
 ```bash
 jettypod workflow checkpoint --step=7
@@ -359,15 +359,15 @@ jettypod project external
 After the command completes successfully, relay the results to the user:
 
 ```
-✅ **Transition Complete!**
+**Transition Complete!**
 
 Your project is now in external state.
 
-📦 Created Infrastructure Readiness epic with:
+Created Infrastructure Readiness epic with:
   • 4 features (Security, Monitoring, Infrastructure, Compliance)
   • 15 chores across those features
 
-🔍 Production mode work items are now visible in your backlog.
+Production mode work items are now visible in your backlog.
 
 **Next Steps:**
 
@@ -378,7 +378,7 @@ Your project is now in external state.
 **Want to start on infrastructure work now?**
 ```
 
-**🔄 WORKFLOW INTEGRATION: Complete workflow**
+**WORKFLOW INTEGRATION: Complete workflow**
 
 ```bash
 jettypod workflow complete external-transition

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

@@ -11,7 +11,7 @@ Guides Claude through feature planning including UX approach exploration, option
 
 When this skill is activated, you are helping discover the best approach for a feature. Follow this structured approach:
 
-## 🔑 Critical Command Distinction
+## Critical Command Distinction
 
 **Six commands in workflow order:**
 
@@ -32,9 +32,9 @@ When this skill is activated, you are helping discover the best approach for a f
 - `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 13. 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 13.
+**HANDOFF REQUIREMENT:** After `work start`, you MUST invoke speed-mode using the Skill tool. See Step 13.
 
 ---
 
@@ -58,7 +58,7 @@ This returns: title, description, parent epic (if any), mode, phase, and any exi
 
 **If the feature is not found**, ask the user to verify the ID or run `jettypod backlog` to find it.
 
-**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+**WORKFLOW INTEGRATION: Start workflow tracking**
 
 After getting the feature context, register this skill execution:
 
@@ -87,10 +87,10 @@ This outputs any architectural decisions recorded for the parent epic. If no dec
 Display the context with decisions:
 
 ```
-✨ Planning Feature: [Feature Name]
+Planning Feature: [Feature Name]
 Epic: [Epic Name]
 
-🎯 **Epic Architectural Decisions:**
+**Epic Architectural Decisions:**
 [If decisions exist:]
 - **[Aspect]:** [Decision]
   *Rationale:* [Why this was chosen]
@@ -114,25 +114,25 @@ Propose exactly 3 approaches with varying complexity/trade-offs:
 Here are 3 different approaches for [feature name]:
 
 **Option 1: [Simple/Minimal approach name]**
-- **Pros**: ✅ [2-3 advantages]
-- **Cons**: ❌ [2-3 trade-offs]
+- **Pros**: [2-3 advantages]
+- **Cons**: [2-3 trade-offs]
 - **Experience**: [What it feels like to use]
 
 **Option 2: [Balanced approach name]**
-- **Pros**: ✅ [2-3 advantages]
-- **Cons**: ❌ [2-3 trade-offs]
+- **Pros**: [2-3 advantages]
+- **Cons**: [2-3 trade-offs]
 - **Experience**: [What it feels like to use]
 
 **Option 3: [Advanced/Comprehensive approach name]**
-- **Pros**: ✅ [2-3 advantages]
-- **Cons**: ❌ [2-3 trade-offs]
+- **Pros**: [2-3 advantages]
+- **Cons**: [2-3 trade-offs]
 - **Experience**: [What it feels like to use]
 
 **Additional approaches considered but not recommended:**
 - *[Alternative 1]*: [Brief] - Not selected because [reason]
 - *[Alternative 2]*: [Brief] - Not selected because [reason]
 
-**💡 Recommendation:** [State which option you recommend and why - 2-3 sentences explaining the reasoning]
+**Recommendation:** [State which option you recommend and why - 2-3 sentences explaining the reasoning]
 
 Would you like me to create working prototypes of these approaches?
 ```
@@ -140,7 +140,7 @@ Would you like me to create working prototypes of these approaches?
 **After presenting approaches, emit a question gate so the narrated UI can render an interactive choice card:**
 
 ```bash
-jettypod ui gate question --data='{"question":"Which approach should we take for [feature name]?","options":[{"id":"option-1","emoji":"🎯","label":"[Simple approach name]","description":"[1-line summary of what it does]"},{"id":"option-2","emoji":"⚖️","label":"[Balanced approach name]","description":"[1-line summary of what it does]"},{"id":"option-3","emoji":"🛡️","label":"[Advanced approach name]","description":"[1-line summary of what it does]"}]}'
+jettypod ui gate question --data='{"question":"Which approach should we take for [feature name]?","options":[{"id":"option-1","emoji":"","label":"[Simple approach name]","description":"[1-line summary of what it does]"},{"id":"option-2","emoji":"","label":"[Balanced approach name]","description":"[1-line summary of what it does]"},{"id":"option-3","emoji":"","label":"[Advanced approach name]","description":"[1-line summary of what it does]"}]}'
 ```
 
 **WAIT for user response.**
@@ -165,7 +165,7 @@ 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.
+**STOP AND CHECK:** Verify worktree was created successfully before proceeding.
 
 **Sub-step 2: Build prototypes in the worktree**
 
@@ -176,7 +176,7 @@ This creates a worktree at `.jettypod-work/prototype-<id>-<slug>-<approach>/` wh
 4. **Add visible banner header at TOP of page** (for HTML/web prototypes):
    ```html
    <div style="background: #f0f0f0; border: 2px solid #333; padding: 16px; margin-bottom: 24px; font-family: monospace;">
-     <strong>🧪 PROTOTYPE</strong><br>
+     <strong>PROTOTYPE</strong><br>
      Feature: [feature name]<br>
      Option: [option number/name]<br>
      Created: [YYYY-MM-DD]<br>
@@ -208,7 +208,7 @@ 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>
+<summary><strong>Prototyping Guidelines (click to expand)</strong></summary>
 
 **Use fastest tech to demonstrate UX:**
 - Quick HTML+JS for web UX
@@ -241,7 +241,7 @@ Which approach works best?
 
 User picks winner. Note their choice - you'll record it formally in Step 11 when transitioning to implementation.
 
-**🔄 WORKFLOW CHECKPOINT: Winner chosen**
+**WORKFLOW CHECKPOINT: Winner chosen**
 
 ```bash
 jettypod workflow checkpoint <feature-id> --step=5
@@ -274,7 +274,7 @@ jettypod workflow checkpoint <feature-id> --step=5
 **Display to user:**
 
 ```
-📍 Integration Contract
+Integration Contract
 
 **Entry Point:** [How users reach this feature]
 **Caller Code:** [What existing code invokes this]
@@ -297,11 +297,11 @@ Example:
 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**
+**FORBIDDEN: Manual Git Worktree Commands**
 ```
-❌ git worktree add ...
-❌ git checkout -b tests/...
-❌ git branch tests/...
+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.
 
@@ -315,14 +315,14 @@ 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.
+**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
+Created test worktree: /path/to/.jettypod-work/tests-42-email-login
 Branch: tests/feature-42-email-login
 
 Write your BDD files to:
@@ -333,13 +333,13 @@ Write your BDD files to:
 **Display:**
 
 ```
-📁 Test worktree created: ${WORKTREE_PATH}
+Test worktree created: ${WORKTREE_PATH}
 Branch: tests/feature-${FEATURE_ID}-${FEATURE_SLUG}
 
-🔒 WORKTREE LOCK ACTIVE: All BDD file writes will use this path.
+WORKTREE LOCK ACTIVE: All BDD file writes will use this path.
 ```
 
-**🔒 WORKTREE PATH LOCK**
+**WORKTREE PATH LOCK**
 
 From this point forward, ALL file operations for BDD tests MUST use paths starting with:
 ```
@@ -350,13 +350,17 @@ ${WORKTREE_PATH}/features/
 
 **Proceed to Step 8.**
 
+### BDD Scenario Formulation Rules (ENFORCED)
+
+Before proposing scenarios, read `templates/bdd-guidance.md`. Scenarios MUST be: declarative (describe intent, not UI clicks), one behavior per scenario, deterministic (factory data, not ambient), no implementation leakage ("Given a user with an unpaid invoice" not "Given the database has a row in invoices"). No UI specifics unless the feature IS a UI interaction.
+
 ### Step 8: Propose BDD Scenarios
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**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)
+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.
 
@@ -369,7 +373,7 @@ ${WORKTREE_PATH}/features/
 Based on chosen approach, **display** the proposed scenarios to the user:
 
 ```
-📋 Proposed BDD Scenarios
+Proposed BDD Scenarios
 
 **Feature file:** ${WORKTREE_PATH}/features/[feature-slug].feature
 **Step definitions:** ${WORKTREE_PATH}/features/step_definitions/[feature-slug].steps.js
@@ -438,7 +442,7 @@ Does this capture the feature correctly? Any scenarios to add/change?
 - If user requests changes → Revise scenarios and display again
 - **Store the confirmed scenarios in memory** - you'll write them in Step 9
 
-**🔄 WORKFLOW CHECKPOINT: BDD scenarios confirmed**
+**WORKFLOW CHECKPOINT: BDD scenarios confirmed**
 
 ```bash
 jettypod workflow checkpoint <feature-id> --step=8
@@ -520,7 +524,7 @@ Scenario: User logs in with "Remember me" option (optional feature)
 ```
 
 <details>
-<summary><strong>📋 BDD Scenario Guidelines (click to expand)</strong></summary>
+<summary><strong>BDD Scenario Guidelines (click to expand)</strong></summary>
 
 **Scenario naming:**
 - Use present tense
@@ -573,7 +577,7 @@ Scenario: Prevent unauthorized access
 
 **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.
+**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**:
 
@@ -605,14 +609,14 @@ cd ${WORKTREE_PATH} && npx cucumber-js --dry-run features/${FEATURE_SLUG}.featur
 
 **What the output means:**
 
-✅ **Success** - No errors, all steps have definitions:
+**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 steps** - Missing step definitions:
 ```
 Undefined. Implement with the following snippet:
   Given('I am on the login page', function () {
@@ -621,13 +625,13 @@ Undefined. Implement with the following snippet:
 ```
 → Add the missing step definition to your `.steps.js` file
 
-❌ **Syntax error** - Invalid Gherkin:
+**Syntax error** - Invalid Gherkin:
 ```
 Parse error in features/foo.feature
 ```
 → Fix the feature file syntax
 
-❌ **Duplicate steps** - Multiple definitions match:
+**Duplicate steps** - Multiple definitions match:
 ```
 Multiple step definitions match
 ```
@@ -640,7 +644,7 @@ Multiple step definitions match
 4. **Loop until validation passes** - do NOT proceed until green
 
 **If validation succeeds:**
-Display: "✅ BDD infrastructure validated - all steps have definitions"
+Display: "BDD infrastructure validated - all steps have definitions"
 
 **Update database with scenario file path:**
 
@@ -677,7 +681,7 @@ Now let me analyze the codebase and propose implementation chores for speed mode
 
 Based on the scenario and my understanding of the codebase, here are the chores I recommend for speed mode:
 
-**Chore 1: [Integration chore - wire feature into app]** ⚡ INTEGRATION
+**Chore 1: [Integration chore - wire feature into app]** INTEGRATION
 - Why: Makes the feature reachable from [entry point]
 - Integration Contract:
   • Entry point: [from Step 6]
@@ -739,17 +743,23 @@ Does this rationale capture why you chose this approach? (You can edit it if nee
 
 **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 10, use the Bash tool to create it:
-
-```bash
-jettypod work create chore "[Chore title]" "[Chore description]" --parent=${FEATURE_ID}
+For each chore that the user confirmed in Step 10, use the **Write** tool to create `/tmp/jettypod-create.json`:
+```json
+{
+  "type": "chore",
+  "title": "[Chore title]",
+  "description": "[Chore description]",
+  "parent": ${FEATURE_ID}
+}
 ```
 
-Replace `${FEATURE_ID}` with actual ID. Example:
+Then run via **Bash**:
 ```bash
-jettypod work create chore "Set up auth routes" "Create login/logout endpoints..." --parent=42
+jettypod work create --from=/tmp/jettypod-create.json
 ```
 
+Replace `${FEATURE_ID}` with actual ID. Example: Write `{"type":"chore","title":"Set up auth routes","description":"Create login/logout endpoints...","parent":42}` to `/tmp/jettypod-create.json`, then run `jettypod work create --from=/tmp/jettypod-create.json`.
+
 **CRITICAL: Copy the EXACT proposal from Step 10 into each chore description.** Do not paraphrase or summarize - the implementation guidance must be preserved verbatim:
 
 ```
@@ -792,13 +802,13 @@ jettypod work implement 42 --winner="Simple inline form" --rationale="Fastest UX
 After successful transition, display:
 
 ```
-✅ Feature transitioned to implementation phase
-✅ Created X chores for speed mode
+Feature transitioned to implementation phase
+Created X chores for speed mode
 
 Now I'll merge the BDD tests to main...
 ```
 
-**🔄 WORKFLOW CHECKPOINT: Implementation transition complete**
+**WORKFLOW CHECKPOINT: Implementation transition complete**
 
 ```bash
 jettypod workflow checkpoint <feature-id> --step=11
@@ -834,33 +844,33 @@ This will:
 - Push to remote
 - Mark worktree as merged (cleanup is separate)
 
-**🛑 STOP AND CHECK:** Verify merge succeeded:
-- ✅ "Tests merged to main" → Proceed to Step 13
-- ❌ Error → Investigate, worktree still exists for debugging
+**STOP AND CHECK:** Verify merge succeeded:
+- "Tests merged to main" → Proceed to Step 13
+- Error → Investigate, worktree still exists for debugging
 
 **After successful merge, display:**
 
 ```
-✅ Feature transitioned to implementation phase
-✅ Created X chores for speed mode
-✅ BDD tests merged to main
+Feature transitioned to implementation phase
+Created X chores for speed mode
+BDD tests merged to main
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎯 Feature Planning Complete!
+Feature Planning Complete!
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-📋 BDD scenarios: features/[feature-slug].feature
-🧪 Step definitions: features/step_definitions/[feature-slug].steps.js
-✅ Feature phase: Implementation
-🚀 Feature mode: Speed
+BDD scenarios: features/[feature-slug].feature
+Step definitions: features/step_definitions/[feature-slug].steps.js
+Feature phase: Implementation
+Feature mode: Speed
 
-💡 Recommendation: Start with Chore #[first-chore-id] ([chore-title])
+Recommendation: Start with Chore #[first-chore-id] ([chore-title])
    [Brief reasoning - e.g., "It sets up the foundation the other chores depend on."]
 
 Start this one? [yes / pick different / done for now]
 ```
 
-**🔄 WORKFLOW INTEGRATION: Complete workflow**
+**WORKFLOW INTEGRATION: Complete workflow**
 
 ```bash
 jettypod workflow complete feature-planning <feature-id>
@@ -897,11 +907,11 @@ End feature-planning skill without starting a chore. Do NOT invoke speed-mode.
 
 **After user picks a chore, execute these steps IN ORDER:**
 
-**🚫 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.
 
@@ -910,17 +920,17 @@ End feature-planning skill without starting a chore. Do NOT invoke speed-mode.
 jettypod work start [chore-id]
 ```
 
-**🛑 STOP AND CHECK:** Look at the output of `work start`. You should see:
+**STOP AND CHECK:** Look at the output of `work start`. You should see:
 ```
-✅ Created worktree: /path/to/.jettypod-work/[id]-[title-slug]
+Created worktree: /path/to/.jettypod-work/[id]-[title-slug]
 Branch: feature/work-[id]-[title-slug]
 ```
 
-**If you see `⚠️ Working in main repository (worktree creation failed)`:**
+**If you see `Working in main repository (worktree creation failed)`:**
 - **DO NOT proceed to speed-mode**
 - Investigate why worktree failed (uncommitted changes? branch conflict?)
 - Fix the issue and re-run `work start`
-- Only continue after seeing `✅ Created worktree`
+- Only continue after seeing `Created worktree`
 
 **Step 2: Verify worktree exists before invoking speed-mode:**
 ```bash
@@ -937,7 +947,7 @@ If this returns empty/no rows, **STOP** - the worktree wasn't created properly.
 Use the Skill tool with skill: "speed-mode"
 ```
 
-**🛑 CRITICAL:** You MUST:
+**CRITICAL:** You MUST:
 1. Run `work start` first
 2. Verify the worktree was created (not fallback to main)
 3. THEN invoke speed-mode using the Skill tool