@su-record/vibe 2.7.14 → 2.7.15

package/skills/exec-plan/SKILL.md

@@ -1,147 +1,147 @@
----
-name: exec-plan
-description: "Convert SPEC into a self-contained execution plan that agents can run autonomously for hours."
-triggers: [exec plan, execution plan, autonomous plan, self-contained plan, long-running]
-priority: 70
----
-
-# ExecPlan — Self-Contained Execution Plan Generator
-
-> **Principle**: "If the agent can't see it, it doesn't exist." Every decision, file path, pattern, and verification step must be explicit in the plan — no implicit knowledge allowed.
-
-## When to Use
-
-Before `/vibe.run`, generate an ExecPlan to make execution deterministic:
-
-| Scenario | Signal |
-|----------|--------|
-| Complex SPEC (3+ phases) | Agent needs long autonomous execution |
-| Team/multi-agent execution | Multiple agents need shared understanding |
-| Context window pressure | Plan survives `/new` session handoff |
-| Unfamiliar codebase | Agent can't rely on implicit knowledge |
-
-## Core Flow
-
-```
-SPEC + Feature → ANALYZE → RESOLVE → GENERATE → PERSIST
-```
-
-### Step 1: ANALYZE — Extract Everything Needed
-
-Read the SPEC and Feature files, then extract:
-
-```
-For each Phase → For each Scenario:
-  1. Requirements (REQ-* IDs)
-  2. Given/When/Then conditions
-  3. Affected files (MUST exist — verify with Glob)
-  4. Dependencies (imports, packages)
-  5. Existing patterns to follow (read actual code, don't assume)
-```
-
-**Parallel exploration** (3+ agents):
-- Agent 1: Map all file paths mentioned/implied in SPEC → verify they exist
-- Agent 2: For each affected file, extract current interfaces/types/exports
-- Agent 3: Find existing patterns (naming conventions, error handling, test structure)
-
-### Step 2: RESOLVE — Eliminate All Ambiguity
-
-For every decision point in the SPEC, resolve it NOW:
-
-| Ambiguity | Resolution |
-|-----------|------------|
-| "Add validation" | → Which fields? What rules? What error messages? |
-| "Handle errors" | → Which error codes? What response format? |
-| "Follow existing pattern" | → Copy the ACTUAL pattern code into the plan |
-| "Update tests" | → Which test file? What test framework? What assertions? |
-
-**Rule**: If you'd need to "figure it out later", resolve it now. The plan must be executable by an agent with ZERO codebase knowledge.
-
-### Step 3: GENERATE — Write the ExecPlan
-
-Output format: `.claude/vibe/specs/{feature-name}-execplan.md`
-
-```markdown
-# ExecPlan: {feature-name}
-
-## Meta
-- SPEC: .claude/vibe/specs/{name}.md
-- Feature: .claude/vibe/features/{name}.feature
-- Generated: {timestamp}
-- Phases: {count}
-- Scenarios: {count}
-
-## Pre-flight Checks
-- [ ] `npm run build` passes
-- [ ] `npx vitest run` passes (baseline)
-- [ ] Required files exist: {list}
-
-## Phase {N}: {phase-name}
-
-### Environment
-- Files to modify: {exact paths}
-- Files to create: {exact paths}
-- Dependencies to add: {package@version}
-- Patterns to follow: (inline code snippets from codebase)
-
-### Scenario {N}.{M}: {scenario-name}
-
-**Given**: {precondition}
-→ Setup: {exact code/commands to establish precondition}
-
-**When**: {action}
-→ Implement: {step-by-step implementation instructions}
-  - File: {path}
-  - Location: after line containing `{anchor text}`
-  - Code: (inline snippet)
-  - Imports needed: {list}
-
-**Then**: {expected result}
-→ Verify:
-  - Command: `{test command}`
-  - Expected: {output/behavior}
-  - Fallback: {what to do if verification fails}
-
-### Phase {N} Gate
-- [ ] Build: `npm run build`
-- [ ] Tests: `npx vitest run {relevant-test-files}`
-- [ ] Type check: `npx tsc --noEmit`
-
-## Completion Criteria
-- Coverage threshold: ≥95%
-- All scenarios passing
-- No regressions in existing tests
-- RTM: `generateTraceabilityMatrix("{feature-name}")`
-```
-
-### Step 4: PERSIST — Save and Link
-
-1. Save ExecPlan to `.claude/vibe/specs/{feature-name}-execplan.md`
-2. Save session context: `save_memory("execplan-{feature}", {summary})`
-3. Output execution command:
-
-```
-Ready to execute:
-  /vibe.run "{feature-name}" ultrawork
-
-Or hand off to new session:
-  /vibe.utils --continue
-  → Load: .claude/vibe/specs/{feature-name}-execplan.md
-```
-
-## Quality Checks
-
-| Check | Criteria |
-|-------|----------|
-| No implicit knowledge | Every file path verified with Glob |
-| No "figure it out" | Every decision resolved with actual code |
-| Survives handoff | Plan readable without any prior context |
-| Inline patterns | Actual code snippets, not "follow existing pattern" |
-| Verification steps | Every scenario has a concrete verification command |
-
-## Anti-patterns
-
-- "See the existing implementation" → Copy the relevant code inline
-- "Follow the pattern in X" → Show the actual pattern
-- "Standard error handling" → Specify exact error codes and messages
-- "Update tests accordingly" → Name the test file, framework, and assertions
+---
+name: exec-plan
+description: "Convert SPEC into a self-contained execution plan that agents can run autonomously for hours."
+triggers: [exec plan, execution plan, autonomous plan, self-contained plan, long-running]
+priority: 70
+---
+
+# ExecPlan — Self-Contained Execution Plan Generator
+
+> **Principle**: "If the agent can't see it, it doesn't exist." Every decision, file path, pattern, and verification step must be explicit in the plan — no implicit knowledge allowed.
+
+## When to Use
+
+Before `/vibe.run`, generate an ExecPlan to make execution deterministic:
+
+| Scenario | Signal |
+|----------|--------|
+| Complex SPEC (3+ phases) | Agent needs long autonomous execution |
+| Team/multi-agent execution | Multiple agents need shared understanding |
+| Context window pressure | Plan survives `/new` session handoff |
+| Unfamiliar codebase | Agent can't rely on implicit knowledge |
+
+## Core Flow
+
+```
+SPEC + Feature → ANALYZE → RESOLVE → GENERATE → PERSIST
+```
+
+### Step 1: ANALYZE — Extract Everything Needed
+
+Read the SPEC and Feature files, then extract:
+
+```
+For each Phase → For each Scenario:
+  1. Requirements (REQ-* IDs)
+  2. Given/When/Then conditions
+  3. Affected files (MUST exist — verify with Glob)
+  4. Dependencies (imports, packages)
+  5. Existing patterns to follow (read actual code, don't assume)
+```
+
+**Parallel exploration** (3+ agents):
+- Agent 1: Map all file paths mentioned/implied in SPEC → verify they exist
+- Agent 2: For each affected file, extract current interfaces/types/exports
+- Agent 3: Find existing patterns (naming conventions, error handling, test structure)
+
+### Step 2: RESOLVE — Eliminate All Ambiguity
+
+For every decision point in the SPEC, resolve it NOW:
+
+| Ambiguity | Resolution |
+|-----------|------------|
+| "Add validation" | → Which fields? What rules? What error messages? |
+| "Handle errors" | → Which error codes? What response format? |
+| "Follow existing pattern" | → Copy the ACTUAL pattern code into the plan |
+| "Update tests" | → Which test file? What test framework? What assertions? |
+
+**Rule**: If you'd need to "figure it out later", resolve it now. The plan must be executable by an agent with ZERO codebase knowledge.
+
+### Step 3: GENERATE — Write the ExecPlan
+
+Output format: `.claude/vibe/specs/{feature-name}-execplan.md`
+
+```markdown
+# ExecPlan: {feature-name}
+
+## Meta
+- SPEC: .claude/vibe/specs/{name}.md
+- Feature: .claude/vibe/features/{name}.feature
+- Generated: {timestamp}
+- Phases: {count}
+- Scenarios: {count}
+
+## Pre-flight Checks
+- [ ] `npm run build` passes
+- [ ] `npx vitest run` passes (baseline)
+- [ ] Required files exist: {list}
+
+## Phase {N}: {phase-name}
+
+### Environment
+- Files to modify: {exact paths}
+- Files to create: {exact paths}
+- Dependencies to add: {package@version}
+- Patterns to follow: (inline code snippets from codebase)
+
+### Scenario {N}.{M}: {scenario-name}
+
+**Given**: {precondition}
+→ Setup: {exact code/commands to establish precondition}
+
+**When**: {action}
+→ Implement: {step-by-step implementation instructions}
+  - File: {path}
+  - Location: after line containing `{anchor text}`
+  - Code: (inline snippet)
+  - Imports needed: {list}
+
+**Then**: {expected result}
+→ Verify:
+  - Command: `{test command}`
+  - Expected: {output/behavior}
+  - Fallback: {what to do if verification fails}
+
+### Phase {N} Gate
+- [ ] Build: `npm run build`
+- [ ] Tests: `npx vitest run {relevant-test-files}`
+- [ ] Type check: `npx tsc --noEmit`
+
+## Completion Criteria
+- Coverage threshold: ≥95%
+- All scenarios passing
+- No regressions in existing tests
+- RTM: `generateTraceabilityMatrix("{feature-name}")`
+```
+
+### Step 4: PERSIST — Save and Link
+
+1. Save ExecPlan to `.claude/vibe/specs/{feature-name}-execplan.md`
+2. Save session context: `save_memory("execplan-{feature}", {summary})`
+3. Output execution command:
+
+```
+Ready to execute:
+  /vibe.run "{feature-name}" ultrawork
+
+Or hand off to new session:
+  /vibe.utils --continue
+  → Load: .claude/vibe/specs/{feature-name}-execplan.md
+```
+
+## Quality Checks
+
+| Check | Criteria |
+|-------|----------|
+| No implicit knowledge | Every file path verified with Glob |
+| No "figure it out" | Every decision resolved with actual code |
+| Survives handoff | Plan readable without any prior context |
+| Inline patterns | Actual code snippets, not "follow existing pattern" |
+| Verification steps | Every scenario has a concrete verification command |
+
+## Anti-patterns
+
+- "See the existing implementation" → Copy the relevant code inline
+- "Follow the pattern in X" → Show the actual pattern
+- "Standard error handling" → Specify exact error codes and messages
+- "Update tests accordingly" → Name the test file, framework, and assertions

package/skills/frontend-design/SKILL.md

@@ -1,73 +1,73 @@
----
-name: frontend-design
-description: "Production-grade frontend with bold aesthetic direction for UI-focused projects"
-triggers: [frontend, ui design, aesthetic, beautiful ui, design system, ui quality, visual design]
-priority: 70
----
-
-# Frontend Design Skill
-
-Create production-grade frontend with bold aesthetic direction.
-
-## Pre-check (K1)
-
-> Does this project need a custom design direction? If using an existing design system (shadcn/ui, Material UI, Ant Design) without customization, standard component docs suffice.
-
-## When to Use
-
-- UI-focused projects requiring high visual quality
-- Design system implementation from scratch
-- User-facing features where aesthetics matter
-
-## Core Principles
-
-### 1. Typography
-- Choose distinctive typefaces that set the tone
-- Establish clear hierarchy through size, weight, and spacing
-- Consider custom fonts that reflect brand personality
-
-### 2. Color & Theme
-- Develop unique color palettes beyond defaults
-- Consider dark/light mode with intentional contrast
-- Use color purposefully for hierarchy and emphasis
-
-### 3. Motion & Animation
-- Add meaningful micro-interactions
-- Use motion to guide user attention
-- Implement smooth transitions between states
-
-### 4. Composition & Layout
-- Create visual rhythm through spacing
-- Use asymmetry and unconventional layouts when appropriate
-- Balance density with breathing room
-
-### 5. Visual Details
-- Custom icons and illustrations
-- Thoughtful shadows and depth
-- Refined borders, corners, and surfaces
-
-## Anti-Patterns to Avoid
-
-- Generic Bootstrap/Tailwind defaults without customization
-- Overused fonts (Inter, Roboto without styling)
-- Predictable card-based layouts everywhere
-- Stock photography without curation
-- Safe, corporate color palettes
-
-## Quality Checklist
-
-- [ ] Typography creates clear hierarchy
-- [ ] Color palette is distinctive and accessible
-- [ ] Animations are smooth (60fps)
-- [ ] Layout works across breakpoints
-- [ ] Empty/loading/error states are designed
-- [ ] Dark mode (if applicable) is intentional
-- [ ] Micro-interactions provide feedback
-
-## Done Criteria (K4)
-
-- [ ] Design tokens defined (colors, typography, spacing, motion)
-- [ ] Visual hierarchy clear at all breakpoints
-- [ ] No default/uncustomized framework styles remain
-- [ ] All interactive states designed (hover, focus, active, disabled)
-- [ ] Accessibility verified (contrast, focus rings, motion preferences)
+---
+name: frontend-design
+description: "Production-grade frontend with bold aesthetic direction for UI-focused projects"
+triggers: [frontend, ui design, aesthetic, beautiful ui, design system, ui quality, visual design]
+priority: 70
+---
+
+# Frontend Design Skill
+
+Create production-grade frontend with bold aesthetic direction.
+
+## Pre-check (K1)
+
+> Does this project need a custom design direction? If using an existing design system (shadcn/ui, Material UI, Ant Design) without customization, standard component docs suffice.
+
+## When to Use
+
+- UI-focused projects requiring high visual quality
+- Design system implementation from scratch
+- User-facing features where aesthetics matter
+
+## Core Principles
+
+### 1. Typography
+- Choose distinctive typefaces that set the tone
+- Establish clear hierarchy through size, weight, and spacing
+- Consider custom fonts that reflect brand personality
+
+### 2. Color & Theme
+- Develop unique color palettes beyond defaults
+- Consider dark/light mode with intentional contrast
+- Use color purposefully for hierarchy and emphasis
+
+### 3. Motion & Animation
+- Add meaningful micro-interactions
+- Use motion to guide user attention
+- Implement smooth transitions between states
+
+### 4. Composition & Layout
+- Create visual rhythm through spacing
+- Use asymmetry and unconventional layouts when appropriate
+- Balance density with breathing room
+
+### 5. Visual Details
+- Custom icons and illustrations
+- Thoughtful shadows and depth
+- Refined borders, corners, and surfaces
+
+## Anti-Patterns to Avoid
+
+- Generic Bootstrap/Tailwind defaults without customization
+- Overused fonts (Inter, Roboto without styling)
+- Predictable card-based layouts everywhere
+- Stock photography without curation
+- Safe, corporate color palettes
+
+## Quality Checklist
+
+- [ ] Typography creates clear hierarchy
+- [ ] Color palette is distinctive and accessible
+- [ ] Animations are smooth (60fps)
+- [ ] Layout works across breakpoints
+- [ ] Empty/loading/error states are designed
+- [ ] Dark mode (if applicable) is intentional
+- [ ] Micro-interactions provide feedback
+
+## Done Criteria (K4)
+
+- [ ] Design tokens defined (colors, typography, spacing, motion)
+- [ ] Visual hierarchy clear at all breakpoints
+- [ ] No default/uncustomized framework styles remain
+- [ ] All interactive states designed (hover, focus, active, disabled)
+- [ ] Accessibility verified (contrast, focus rings, motion preferences)

package/skills/git-worktree/SKILL.md

@@ -1,72 +1,72 @@
----
-name: git-worktree
-description: "Git Worktree for parallel branch work. Auto-activates for PR review, hotfix, parallel testing, or working on multiple branches simultaneously."
-triggers: [worktree, PR review, hotfix, parallel branch, multiple branches]
-priority: 50
----
-
-# Git Worktree
-
-## Pre-check (K1)
-
-> Do you need to work on another branch without losing current work? If you can just `git stash` and switch, worktree may be overkill.
-
-## Core Commands
-
-```bash
-# Create worktree for PR review
-git worktree add ../review-{pr_number} origin/pr/{pr_number}
-
-# Create worktree with new branch (hotfix)
-git worktree add -b hotfix/urgent ../hotfix main
-
-# List all worktrees
-git worktree list
-
-# Remove when done
-git worktree remove ../review-{pr_number}
-
-# Clean up stale entries
-git worktree prune
-```
-
-## PR Review Workflow
-
-```
-1. git worktree add ../review-123 origin/pr/123
-2. cd ../review-123
-3. npm install && npm test
-4. Run review agents
-5. cd - && git worktree remove ../review-123
-```
-
-## Hotfix Workflow
-
-```
-1. git worktree add -b hotfix/critical ../hotfix main
-2. cd ../hotfix
-3. Fix bug → commit → push
-4. cd - && git worktree remove ../hotfix
-```
-
-## Naming Convention
-
-```bash
-../review-{pr_number}         # PR review
-../hotfix-{issue_number}      # Hotfix
-../experiment-{feature_name}  # Experiment
-```
-
-## Troubleshooting
-
-| Error | Fix |
-|-------|-----|
-| "already checked out" | Branch is in another worktree — `git worktree list`, then remove |
-| Locked worktree | `git worktree unlock <path>` |
-| Stale worktree | `git worktree prune` |
-
-## Done Criteria (K4)
-
-- [ ] Worktree created and work completed in isolation
-- [ ] Worktree removed after work is done
-- [ ] No stale worktrees left (`git worktree list` clean)
+---
+name: git-worktree
+description: "Git Worktree for parallel branch work. Auto-activates for PR review, hotfix, parallel testing, or working on multiple branches simultaneously."
+triggers: [worktree, PR review, hotfix, parallel branch, multiple branches]
+priority: 50
+---
+
+# Git Worktree
+
+## Pre-check (K1)
+
+> Do you need to work on another branch without losing current work? If you can just `git stash` and switch, worktree may be overkill.
+
+## Core Commands
+
+```bash
+# Create worktree for PR review
+git worktree add ../review-{pr_number} origin/pr/{pr_number}
+
+# Create worktree with new branch (hotfix)
+git worktree add -b hotfix/urgent ../hotfix main
+
+# List all worktrees
+git worktree list
+
+# Remove when done
+git worktree remove ../review-{pr_number}
+
+# Clean up stale entries
+git worktree prune
+```
+
+## PR Review Workflow
+
+```
+1. git worktree add ../review-123 origin/pr/123
+2. cd ../review-123
+3. npm install && npm test
+4. Run review agents
+5. cd - && git worktree remove ../review-123
+```
+
+## Hotfix Workflow
+
+```
+1. git worktree add -b hotfix/critical ../hotfix main
+2. cd ../hotfix
+3. Fix bug → commit → push
+4. cd - && git worktree remove ../hotfix
+```
+
+## Naming Convention
+
+```bash
+../review-{pr_number}         # PR review
+../hotfix-{issue_number}      # Hotfix
+../experiment-{feature_name}  # Experiment
+```
+
+## Troubleshooting
+
+| Error | Fix |
+|-------|-----|
+| "already checked out" | Branch is in another worktree — `git worktree list`, then remove |
+| Locked worktree | `git worktree unlock <path>` |
+| Stale worktree | `git worktree prune` |
+
+## Done Criteria (K4)
+
+- [ ] Worktree created and work completed in isolation
+- [ ] Worktree removed after work is done
+- [ ] No stale worktrees left (`git worktree list` clean)