jettypod 4.4.74 → 4.4.76

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

@@ -0,0 +1,327 @@
+---
+name: simple-improvement
+description: Guide implementation of simple improvements to existing functionality. Use when feature-planning routes here for basic enhancements like copy changes, styling tweaks, or minor behavior adjustments. (project)
+---
+
+# Simple Improvement Skill
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│  Simple Improvement Flow                                             │
+│                                                                      │
+│  Feature Planning → [SIMPLE IMPROVEMENT] → Done                      │
+│                      ▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲                           │
+│                      YOU ARE HERE                                    │
+│                                                                      │
+│  This is a LIGHTWEIGHT workflow - no speed/stable modes.             │
+│  Single chore, direct implementation, done.                          │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+Lightweight workflow for basic enhancements to existing functionality. Bypasses the full speed/stable mode progression for simple changes.
+
+## When to Use
+
+This skill is invoked by feature-planning when the user confirms their work is a **simple improvement**:
+- Copy/text changes
+- Styling tweaks
+- Minor behavior adjustments
+- Small bug fixes to existing functionality
+
+## When NOT to Use
+
+Route back to feature-planning for:
+- New functionality (even if small)
+- Changes requiring new data models
+- Complex logic changes
+- Features needing error handling design
+
+---
+
+## Instructions
+
+### Step 1: Validate Simplicity
+
+**Confirm the work is truly a simple improvement.**
+
+**Ask the user:**
+
+```
+Let me confirm this is a simple improvement. Please describe the change:
+
+What exactly needs to change? (Be specific - e.g., "Change button text from 'Submit' to 'Save'")
+```
+
+**⚡ WAIT for user response.**
+
+**First, check for vague or incomplete descriptions:**
+
+**Vague Description Signals:**
+| Signal | Examples |
+|--------|----------|
+| Too short | Less than 20 characters |
+| No specifics | "fix the thing", "update it", "make it better" |
+| Missing context | No file, component, or location mentioned |
+| Ambiguous action | "change something", "tweak the code" |
+
+**If description is vague or unclear:**
+
+```
+I need more details to proceed. Your description is too vague for me to understand what needs to change.
+
+Please provide:
+• What specific element/text/behavior needs to change?
+• Where is it located? (file, page, component)
+• What should it look like after the change?
+
+Example: "Change the submit button text from 'Submit' to 'Save Changes' on the contact form"
+```
+
+**⚡ WAIT for user to provide a clearer description before proceeding.**
+
+Do NOT continue until you have a specific, actionable description.
+
+---
+
+**Once you have a clear description, analyze for complexity signals:**
+
+**Complexity Signal Detection:**
+Scan the user's description for these patterns:
+
+| Signal | Keywords/Patterns |
+|--------|-------------------|
+| New data models | "new table", "add column", "database", "schema" |
+| New API | "new endpoint", "API", "new route" |
+| Complex logic | "if/else", "conditional", "depends on", multiple "and" clauses |
+| Multiple components | mentions 3+ different files/areas, "also need to" |
+| Architectural changes | "refactor", "restructure", "new system" |
+
+❌ **Route back to feature-planning if ANY complexity signal detected:**
+- New database tables/columns needed
+- New API endpoints required
+- Complex conditional logic
+- Multiple interconnected changes
+- Need for error handling design
+
+✅ **Continue if the change is:**
+- Single file or 2-3 related files
+- Modifying existing code (not creating new features)
+- Clear, specific scope
+- No architectural decisions needed
+
+**If too complex:**
+
+```
+⚠️ This change appears to require new data models or architectural changes. This is more than a simple improvement.
+
+I'm routing you back to feature-planning for proper planning with BDD scenarios.
+```
+
+**Then IMMEDIATELY:**
+1. Invoke feature-planning skill using the Skill tool
+2. END this skill (do not continue)
+
+**If confirmed simple:**
+
+```
+✅ Confirmed: This is a simple improvement.
+
+Change: [summarize the specific change]
+Scope: [list files likely affected]
+
+Creating implementation chore...
+```
+
+**Proceed to Step 2.**
+
+---
+
+### Step 2: Create Implementation Chore
+
+**Create a single chore with NO mode assigned.**
+
+```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>
+```
+
+**IMPORTANT:** Do NOT use `--mode` flag. Simple improvements don't use speed/stable modes.
+
+**Display to user:**
+
+```
+✅ Created Chore #[id]: [title]
+
+Ready to implement. Starting chore...
+```
+
+**If chore creation fails:**
+
+When the `jettypod work create` command fails, display error details and suggest recovery:
+
+```
+❌ Failed to create chore: [error message] ([error code if available])
+
+This could be caused by:
+• Database is locked by another process
+• File system permissions issue
+• Corrupted work.db file
+
+Suggested actions:
+1. Retry the operation
+2. Check if another process is using the database
+3. Verify system status with: ls -la .jettypod/
+4. If persistent, try: jettypod work cleanup --all
+```
+
+**⚡ WAIT for user to acknowledge before retrying or investigating further.**
+
+Do NOT proceed to Step 3 until chore is successfully created.
+
+**Proceed to Step 3.**
+
+---
+
+### Step 3: Start Chore and Implement
+
+**Start the chore to create a worktree:**
+
+```bash
+jettypod work start <chore-id>
+```
+
+**Then implement the change directly:**
+
+1. Read the file(s) that need modification
+2. Make the specific change requested
+3. Verify the change looks correct
+
+**Display progress:**
+
+```
+📝 Implementing change...
+
+Modified: [file path]
+Change: [what was changed]
+
+Verifying...
+```
+
+**Proceed to Step 4.**
+
+---
+
+### Step 4: Verify and Complete
+
+**Quick verification:**
+- Does the change match what was requested?
+- Is the code syntactically correct?
+- Are there any obvious issues?
+
+**If issues found:** Fix them before proceeding.
+
+**If verification passes:**
+
+```bash
+# Commit the change
+cd <worktree-path>
+git add .
+git commit -m "fix: [brief description]
+
+🤖 Generated with [Claude Code](https://claude.com/claude-code)
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
+```
+
+**Then merge (from main repo):**
+
+```bash
+cd <main-repo-path>
+jettypod work merge <chore-id>
+jettypod work cleanup <chore-id>
+```
+
+**If merge fails:**
+
+When `jettypod work merge` encounters an error (e.g., merge conflicts), the worktree is preserved for debugging.
+
+```
+❌ Merge failed: [error message from git]
+
+Conflicting files:
+• [list conflicting files if available]
+
+⚠️ IMPORTANT: The worktree has been PRESERVED for debugging at:
+   [worktree-path]
+
+Resolution steps:
+1. Navigate to the worktree: cd [worktree-path]
+2. Resolve the conflicts in the listed files
+3. Stage resolved files: git add [resolved-files]
+4. Commit the resolution: git commit -m "resolve: merge conflicts"
+5. Return to main repo: cd [main-repo-path]
+6. Retry the merge: jettypod work merge <chore-id>
+
+Need help? Run: git status (in worktree) to see conflict status
+```
+
+**⚡ WAIT for user to resolve conflicts before retrying.**
+
+Do NOT attempt to auto-resolve conflicts - let the user handle them manually.
+
+**Mark feature as done:**
+
+```bash
+jettypod work status <feature-id> done
+```
+
+**Display completion:**
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ Simple Improvement Complete!
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Change: [what was changed]
+Files: [files modified]
+Feature: #[id] marked as done
+
+No further action needed.
+```
+
+**END skill.**
+
+---
+
+## Key Differences from Speed/Stable Mode
+
+| Aspect | Simple Improvement | Speed/Stable Mode |
+|--------|-------------------|-------------------|
+| Chores | 1 chore, no mode | Multiple chores with modes |
+| BDD | Not required | Required |
+| Handoff | None - direct to done | Speed → Stable → (Production) |
+| Scope | Single focused change | Full feature implementation |
+| Time | Minutes | Hours to days |
+
+---
+
+## Command Reference
+
+```bash
+# Create chore (no mode)
+jettypod work create chore "<title>" "<description>" --parent=<feature-id>
+
+# Start chore
+jettypod work start <chore-id>
+
+# Merge (from main repo)
+cd <main-repo> && jettypod work merge <chore-id>
+
+# Cleanup
+jettypod work cleanup <chore-id>
+
+# Mark feature done
+jettypod work status <feature-id> done
+```