jettypod 4.4.118 → 4.4.121

package/skills-templates/chore-mode/verification.js

@@ -57,6 +57,10 @@ function runVerificationChecklist(type, context = {}) {
       checks.push(...runToolingChecks(guidance, context));
       break;
 
+    case CHORE_TYPES.ENHANCEMENT:
+      checks.push(...runEnhancementChecks(guidance, context));
+      break;
+
     default:
       checks.push(createCheck(
         'Valid chore type',
@@ -80,9 +84,9 @@ function runVerificationChecklist(type, context = {}) {
 function runRefactorChecks(guidance, context) {
   const checks = [];
 
-  // "All existing tests pass without modification"
+  // "Affected tests pass without modification"
   checks.push(createCheck(
-    'All existing tests pass without modification',
+    'Affected tests pass without modification',
     context.testResult?.passed === true,
     context.testResult?.passed ? null : 'Tests failed - refactor may have broken behavior'
   ));
@@ -117,9 +121,9 @@ function runRefactorChecks(guidance, context) {
 function runDependencyChecks(guidance, context) {
   const checks = [];
 
-  // "All tests pass after update"
+  // "Affected tests pass after update"
   checks.push(createCheck(
-    'All tests pass after update',
+    'Affected tests pass after update',
     context.testResult?.passed === true,
     context.testResult?.passed ? null : 'Tests failed after dependency update'
   ));
@@ -150,9 +154,9 @@ function runDependencyChecks(guidance, context) {
 function runCleanupChecks(guidance, context) {
   const checks = [];
 
-  // "All tests still pass"
+  // "Affected tests still pass"
   checks.push(createCheck(
-    'All tests still pass',
+    'Affected tests still pass',
     context.testResult?.passed === true,
     context.testResult?.passed ? null : 'Tests failed after cleanup'
   ));
@@ -204,6 +208,43 @@ function runToolingChecks(guidance, context) {
   return checks;
 }
 
+/**
+ * Run enhancement-specific verification checks (TDD)
+ */
+function runEnhancementChecks(guidance, context) {
+  const checks = [];
+
+  // "New tests written BEFORE implementation (TDD red phase)"
+  checks.push(createCheck(
+    'New tests written before implementation (TDD red phase)',
+    context.newTestsWritten === true,
+    context.newTestsWritten ? null : 'No new tests detected - enhancement chores require TDD'
+  ));
+
+  // "All new tests pass (TDD green phase)"
+  checks.push(createCheck(
+    'All new tests pass (TDD green phase)',
+    context.testResult?.passed === true,
+    context.testResult?.passed ? null : 'New tests failing - implementation incomplete'
+  ));
+
+  // "Code is clean and well-structured (TDD refactor phase)"
+  checks.push(createCheck(
+    'Code is clean and well-structured (TDD refactor phase)',
+    context.refactorComplete !== false,
+    context.refactorComplete === false ? 'Refactor phase not completed' : null
+  ));
+
+  // "Existing affected tests still pass"
+  checks.push(createCheck(
+    'Existing affected tests still pass',
+    context.existingTestsBroken !== true,
+    context.existingTestsBroken ? 'Existing tests broken by enhancement' : null
+  ));
+
+  return checks;
+}
+
 /**
  * Format verification results for display
  *
@@ -213,12 +254,12 @@ function runToolingChecks(guidance, context) {
 function formatVerificationResult(result) {
   const lines = [];
   lines.push('━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━');
-  lines.push('🔍 Verification Checklist');
+  lines.push('Verification Checklist');
   lines.push('━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━');
   lines.push('');
 
   for (const check of result.checks) {
-    const icon = check.passed ? '✅' : '❌';
+    const icon = check.passed ? '[PASS]' : '[FAIL]';
     lines.push(`${icon} ${check.description}`);
     if (check.details) {
       lines.push(`   └─ ${check.details}`);
@@ -227,10 +268,10 @@ function formatVerificationResult(result) {
 
   lines.push('');
   if (result.passed) {
-    lines.push('✅ All verification checks passed');
+    lines.push('All verification checks passed');
   } else {
     const failedCount = result.checks.filter(c => !c.passed).length;
-    lines.push(`❌ ${failedCount} verification check(s) failed`);
+    lines.push(`${failedCount} verification check(s) failed`);
   }
 
   return lines.join('\n');

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/design-system-selection/SKILL.md

@@ -0,0 +1,273 @@
+# Design System Selection Skill
+
+Walks users through discovering, configuring, and documenting their project's design system. Produces a standardized Brand Kit page.
+
+## When to Use
+
+Invoke when the user says things like:
+- "set up my design system"
+- "configure design system"
+- "help me with my brand kit"
+- "add my design tokens"
+
+## Instructions
+
+### Opening
+
+Start the conversation with enthusiasm. Design systems are the foundation of a polished product — they deserve excitement. Open with something like:
+
+> Design systems are one of the highest-leverage things you can set up. Once Claude knows your colors, typography, spacing, and component patterns, every piece of UI it builds will feel like *your* product — not a generic template.
+>
+> I'm going to walk you through a few decisions, scan your project for what you already have, and we'll leave with two things:
+>
+> 1. **Your design system directory configured** — so Claude always has your tokens as context
+> 2. **A Brand Kit page** — a living reference you (and Claude) can always check
+>
+> Here's what a finished Brand Kit looks like: `app/design-system/page.tsx` in this project.
+>
+> Let's start.
+
+**Then proceed to Step 1.**
+
+### Step 1: Scan for What Exists
+
+Before asking questions, scan the project to understand what's already in place. Run these in parallel:
+
+**Directory search:**
+```bash
+find . -maxdepth 3 -type d \( -name "design-system" -o -name "design-tokens" -o -name "tokens" -o -name "theme" -o -name "styles" -o -name "ui-kit" -o -name "foundations" -o -name "primitives" \) -not -path "*/node_modules/*" -not -path "*/.git/*" 2>/dev/null
+```
+
+**File pattern search** (use Glob tool):
+- `**/tokens.{css,scss,json,ts,js}`
+- `**/theme.{css,scss,json,ts,js}`
+- `**/variables.{css,scss}`
+- `**/_variables.scss`
+- `**/design-tokens/**`
+- `**/globals.css`
+- `**/tailwind.config.*`
+
+**Content signals** (use Grep tool):
+- CSS custom properties: `--color-`, `--spacing-`, `--font-`
+- Tailwind theme config: `colors:`, `spacing:`, `fontFamily:`
+- Design token patterns: `$color-`, `$spacing-`
+
+**Present what you found:**
+
+If tokens/theme files exist:
+> I found some existing design assets. Here's what I see:
+> - [list files with brief content summary]
+>
+> Let me ask you a few questions to fill in the gaps.
+
+If nothing found:
+> Starting fresh — that's fine. Let me walk you through the key decisions.
+
+### Step 2: Walk Through Decisions
+
+Guide the user through each design system category. For each, present a focused question. Don't overwhelm — one topic at a time.
+
+**2a. Brand Palette**
+
+> **Colors first.** Every brand needs at minimum:
+> - **Primary** — your main action color (buttons, links, active states)
+> - **Accent** — warm emphasis (CTAs, highlights, banners)
+> - **Neutral black** — text, borders, outlined buttons
+>
+> Do you have brand colors already? Paste hex codes, a brand guide link, or describe the vibe you want (e.g., "calm and professional", "bold and energetic").
+
+**WAIT for user response.**
+
+For each color, derive three shades:
+- **Solid** — the main color (buttons, fills)
+- **Tint** — light background version (badges, callouts) — mix ~85% white
+- **Text** — darker version for text on the tint — darken ~30%
+
+**2b. Typography**
+
+> **Typography.** What font does your project use? Check your CSS/config, or tell me what you'd like.
+>
+> I also need to know your heading style preference — tight tracking (modern/bold) or normal tracking (classic/readable)?
+
+**WAIT for user response.**
+
+**2c. Surface & Elevation**
+
+> **Surfaces.** Two quick decisions:
+> 1. **Background warmth** — Pure white canvas, or slightly warm (cream/gray tint)?
+> 2. **Cards** — Separated by borders, or by shadow + background contrast (no borders)?
+
+**WAIT for user response.**
+
+**2d. Border Philosophy**
+
+> **Borders.** I recommend the binary approach: thick borders (2px) on interactive elements (inputs, outlined buttons), and NO borders on containers (use shadow + background contrast instead). Sound good, or do you prefer a different approach?
+
+**WAIT for user response.**
+
+**2e. Spacing & Radius**
+
+> **Last two quick ones:**
+> - **Border radius** — Rounded (16px cards, 12px buttons) or sharp (4-8px everywhere)?
+> - **Spacing** — Generous (lots of breathing room) or compact (dense, information-heavy)?
+
+**WAIT for user response.**
+
+### Step 3: Configure the Design System Directory
+
+Based on the scan results from Step 1, identify or create the design system directory.
+
+**If a clear candidate exists:**
+> I'll configure `[path]` as your design system directory.
+
+**If no directory exists, create one:**
+> I'll create a `design-system/` directory with your tokens.
+
+Write a CSS tokens file with all the decisions from Step 2:
+
+```css
+/* design-system/tokens.css */
+:root {
+  /* Brand Palette - Primary */
+  --color-primary: [solid];
+  --color-primary-tint: [tint];
+  --color-primary-text: [text-on-tint];
+
+  /* Brand Palette - Accent */
+  --color-accent: [solid];
+  --color-accent-tint: [tint];
+  --color-accent-text: [text-on-tint];
+
+  /* Brand Palette - Neutral */
+  --color-black: [black];
+
+  /* Surfaces */
+  --color-background: [background];
+  --color-card: [card];
+
+  /* Typography */
+  --font-sans: [font];
+  --font-mono: [mono font];
+
+  /* Spacing */
+  --space-xs: [value];
+  --space-sm: [value];
+  --space-md: [value];
+  --space-lg: [value];
+  --space-xl: [value];
+
+  /* Radius */
+  --radius-sm: [value];
+  --radius-md: [value];
+  --radius-lg: [value];
+
+  /* Shadows */
+  --shadow-sm: [value];
+  --shadow-md: [value];
+  --shadow-lg: [value];
+}
+```
+
+Then configure it:
+
+```bash
+node -e "
+const fs = require('fs');
+const path = require('path');
+const dir = path.resolve('<selected-directory>');
+const configPath = '.jettypod/config.json';
+const config = fs.existsSync(configPath) ? JSON.parse(fs.readFileSync(configPath, 'utf-8')) : {};
+config.designSystemDir = dir;
+fs.writeFileSync(configPath, JSON.stringify(config, null, 2));
+console.log('Set designSystemDir to:', dir);
+"
+```
+
+Regenerate CLAUDE.md:
+```bash
+jettypod claude generate
+```
+
+Verify:
+```bash
+grep -c "design_system" CLAUDE.md
+```
+
+### Step 4: Generate the Brand Kit Page
+
+**This is the key deliverable.** Create a standardized Brand Kit page that serves as a living reference.
+
+The page MUST follow this exact structure (same sections, same order, every time):
+
+```
+app/design-system/page.tsx
+```
+
+**Required sections (in order):**
+
+| # | Section | What it shows |
+|---|---------|---------------|
+| 0 | Border Philosophy | Binary borders rule — thick on interactive, none on containers |
+| 1 | Brand Palette | Each color with solid/tint/text swatches + in-context badges |
+| 2 | Surface Hierarchy | Background → card → content layering with actual nesting demo |
+| 3 | Elevation Scale | Shadow levels (sm/md/lg/overlay) with visual boxes |
+| 4 | Typography | Full type scale from display (4xl) to caption (xs) |
+| 5 | Motion & Easing | Duration, easing, and live hover demos |
+| 6 | Border Radius | Visual comparison of radius tiers |
+| 7 | Button Variants | All variants × all sizes, including loading states |
+| 8 | Hover/Active/Disabled | Interactive state demos |
+| 9 | Input Focus States | Resting vs focused with live interaction |
+| 10 | Focus Rings | Tab-accessible focus-visible demos |
+| 11 | Loading States | Skeletons and spinners |
+| 12 | Toast Patterns | Success, error, info, warning static examples |
+| 13 | Composition Examples | Cards with actions, forms, banners — how pieces fit together |
+| 14 | Design Decisions | Resolved decisions (with DECIDED labels) and open questions |
+
+**Each section uses:**
+- `<Section title="N. Section Name" description="One-line explanation">` wrapper
+- `<Card>` container with shadow (no borders)
+- Monospace labels (`text-xs font-mono text-zinc-400`) for technical annotations
+- Live interactive demos where applicable (hover, focus, click)
+
+**Page infrastructure:**
+- Dark mode toggle in header
+- `max-w-5xl mx-auto` content width
+- `space-y-20` between sections
+- Helper components: `Section`, `ColorSwatch`, `Card`
+
+**The page should use the user's actual tokens from Step 2** — not placeholder values. Every color swatch, button, and example should reflect their real brand.
+
+Present the generated page to the user:
+
+> Here's your Brand Kit page. It's a living reference — you and Claude can always check `app/design-system/page.tsx` to see your design system in action.
+>
+> Every section is interactive: hover the cards, click the inputs, tab through the buttons.
+
+### Step 5: Wrap Up
+
+Summarize what was accomplished:
+
+> **Done! Here's what we set up:**
+>
+> 1. **Design system directory** — `[path]` configured in `.jettypod/config.json`
+> 2. **CLAUDE.md updated** — Claude now sees your design tokens as context in every conversation
+> 3. **Brand Kit page** — `app/design-system/page.tsx` is your living reference
+>
+> From now on, when Claude builds UI for you, it'll use your exact colors, typography, spacing, and component patterns. No more generic-looking output.
+
+## Clearing
+
+If user wants to remove the design system:
+
+```bash
+node -e "
+const fs = require('fs');
+const configPath = '.jettypod/config.json';
+const config = fs.existsSync(configPath) ? JSON.parse(fs.readFileSync(configPath, 'utf-8')) : {};
+delete config.designSystemDir;
+fs.writeFileSync(configPath, JSON.stringify(config, null, 2));
+console.log('Removed designSystemDir');
+"
+```
+
+Then: `jettypod claude generate`