@su-record/vibe 2.7.11 → 2.7.13

package/skills/brand-assets/SKILL.md

@@ -1,146 +1,146 @@
----
-name: brand-assets
-description: "Auto-generate app icons and favicons from SPEC brand information using Gemini Image API"
-triggers: [icon, favicon, brand, logo, app icon, branding, assets]
-priority: 65
----
-# Brand Assets Generation Skill
-
-Auto-generate app icons and favicons based on SPEC brand information.
-
-## When to Use
-
-- First-time project setup with `/vibe.run`
-- When SPEC contains brand/design information
-- When Gemini API key is configured
-
-## Prerequisites
-
-- Gemini API key configured (`vibe gemini auth`)
-- SPEC with brand context (app name, colors, style)
-
-## Generated Assets
-
-### Web
-- `favicon.ico` (16x16, 32x32, 48x48)
-- `favicon-16x16.png`
-- `favicon-32x32.png`
-- `apple-touch-icon.png` (180x180)
-- `android-chrome-192x192.png`
-- `android-chrome-512x512.png`
-
-### Mobile (if applicable)
-- iOS: `AppIcon.appiconset/` with all sizes
-- Android: `mipmap-*/` adaptive icons
-
-## SPEC Brand Section
-
-For best results, include brand info in your SPEC:
-
-```yaml
-<context>
-Brand:
-  - App Name: MyApp
-  - Primary Color: #2F6BFF
-  - Style: Modern, minimal, flat design
-  - Icon Concept: Abstract geometric shape representing connectivity
-</context>
-```
-
-## Generation Flow
-
-```
-SPEC Brand Info
-      |
-      v
-Extract: name, colors, style keywords
-      |
-      v
-Generate Prompt: "App icon for [name], [style], [colors]..."
-      |
-      v
-Gemini Image API (gemini-2.5-flash-image)
-      |
-      v
-Resize & Convert: All platform sizes
-      |
-      v
-Save to: public/ or assets/
-```
-
-## Auto-Trigger Conditions
-
-1. First `/vibe.run` execution (no existing icons)
-2. SPEC contains brand/design context
-3. Gemini API key is available
-4. `--generate-icons` flag passed
-
-## Skip Conditions
-
-- Icons already exist (unless `--regenerate-icons`)
-- No brand info in SPEC
-- Gemini API not configured
-
-## Prompt Template
-
-```
-Create a modern app icon for "[APP_NAME]".
-
-Style: [STYLE_KEYWORDS]
-Primary color: [PRIMARY_COLOR]
-Design: Minimalist, professional, suitable for mobile app
-Format: Square, clean edges, simple recognizable shape
-Background: Solid color or subtle gradient
-
-Requirements:
-- Works at small sizes (16x16 to 512x512)
-- No text or letters
-- Single focal element
-- High contrast for visibility
-```
-
-## Manual Usage
-
-```bash
-# [LLM_SCRIPT] = {{CORE_PATH}}/hooks/scripts/llm-orchestrate.js
-# Generate via llm-orchestrate (when Gemini configured)
-node "[LLM_SCRIPT]" gemini image "App icon for MyApp, primary color #2F6BFF, square format 1:1, simple recognizable design, works well at small sizes, no text or letters, solid or gradient background, modern minimalist" --output "./public/app-icon.png"
-```
-
-## Integration with /vibe.run
-
-During Phase 1 (Setup), if brand assets don't exist:
-
-1. Parse SPEC for brand context
-2. Generate icon via Gemini Image API
-3. Create all size variants
-4. Place in appropriate directories
-5. Update manifest files if needed
-
-## Fallback Strategy
-
-If Gemini Image fails:
-1. Generate text-based monogram icon (first letter)
-2. Use project primary color as background
-3. Create simple geometric placeholder
-
-## Output Structure
-
-```
-public/
-  favicon.ico
-  favicon-16x16.png
-  favicon-32x32.png
-  apple-touch-icon.png
-  android-chrome-192x192.png
-  android-chrome-512x512.png
-  site.webmanifest
-```
-
-## Done Criteria (K4)
-
-- [ ] All required sizes generated (16x16 through 512x512)
-- [ ] Icons work at small sizes (recognizable at 16x16)
-- [ ] No text/letters in icon (illegible at small sizes)
-- [ ] `site.webmanifest` updated with icon paths
-- [ ] Fallback generated if Gemini API unavailable
+---
+name: brand-assets
+description: "Auto-generate app icons and favicons from SPEC brand information using Gemini Image API"
+triggers: [icon, favicon, brand, logo, app icon, branding, assets]
+priority: 65
+---
+# Brand Assets Generation Skill
+
+Auto-generate app icons and favicons based on SPEC brand information.
+
+## When to Use
+
+- First-time project setup with `/vibe.run`
+- When SPEC contains brand/design information
+- When Gemini API key is configured
+
+## Prerequisites
+
+- Gemini API key configured (`vibe gemini auth`)
+- SPEC with brand context (app name, colors, style)
+
+## Generated Assets
+
+### Web
+- `favicon.ico` (16x16, 32x32, 48x48)
+- `favicon-16x16.png`
+- `favicon-32x32.png`
+- `apple-touch-icon.png` (180x180)
+- `android-chrome-192x192.png`
+- `android-chrome-512x512.png`
+
+### Mobile (if applicable)
+- iOS: `AppIcon.appiconset/` with all sizes
+- Android: `mipmap-*/` adaptive icons
+
+## SPEC Brand Section
+
+For best results, include brand info in your SPEC:
+
+```yaml
+<context>
+Brand:
+  - App Name: MyApp
+  - Primary Color: #2F6BFF
+  - Style: Modern, minimal, flat design
+  - Icon Concept: Abstract geometric shape representing connectivity
+</context>
+```
+
+## Generation Flow
+
+```
+SPEC Brand Info
+      |
+      v
+Extract: name, colors, style keywords
+      |
+      v
+Generate Prompt: "App icon for [name], [style], [colors]..."
+      |
+      v
+Gemini Image API (gemini-2.5-flash-image)
+      |
+      v
+Resize & Convert: All platform sizes
+      |
+      v
+Save to: public/ or assets/
+```
+
+## Auto-Trigger Conditions
+
+1. First `/vibe.run` execution (no existing icons)
+2. SPEC contains brand/design context
+3. Gemini API key is available
+4. `--generate-icons` flag passed
+
+## Skip Conditions
+
+- Icons already exist (unless `--regenerate-icons`)
+- No brand info in SPEC
+- Gemini API not configured
+
+## Prompt Template
+
+```
+Create a modern app icon for "[APP_NAME]".
+
+Style: [STYLE_KEYWORDS]
+Primary color: [PRIMARY_COLOR]
+Design: Minimalist, professional, suitable for mobile app
+Format: Square, clean edges, simple recognizable shape
+Background: Solid color or subtle gradient
+
+Requirements:
+- Works at small sizes (16x16 to 512x512)
+- No text or letters
+- Single focal element
+- High contrast for visibility
+```
+
+## Manual Usage
+
+```bash
+# [LLM_SCRIPT] = {{CORE_PATH}}/hooks/scripts/llm-orchestrate.js
+# Generate via llm-orchestrate (when Gemini configured)
+node "[LLM_SCRIPT]" gemini image "App icon for MyApp, primary color #2F6BFF, square format 1:1, simple recognizable design, works well at small sizes, no text or letters, solid or gradient background, modern minimalist" --output "./public/app-icon.png"
+```
+
+## Integration with /vibe.run
+
+During Phase 1 (Setup), if brand assets don't exist:
+
+1. Parse SPEC for brand context
+2. Generate icon via Gemini Image API
+3. Create all size variants
+4. Place in appropriate directories
+5. Update manifest files if needed
+
+## Fallback Strategy
+
+If Gemini Image fails:
+1. Generate text-based monogram icon (first letter)
+2. Use project primary color as background
+3. Create simple geometric placeholder
+
+## Output Structure
+
+```
+public/
+  favicon.ico
+  favicon-16x16.png
+  favicon-32x32.png
+  apple-touch-icon.png
+  android-chrome-192x192.png
+  android-chrome-512x512.png
+  site.webmanifest
+```
+
+## Done Criteria (K4)
+
+- [ ] All required sizes generated (16x16 through 512x512)
+- [ ] Icons work at small sizes (recognizable at 16x16)
+- [ ] No text/letters in icon (illegible at small sizes)
+- [ ] `site.webmanifest` updated with icon paths
+- [ ] Fallback generated if Gemini API unavailable

package/skills/capability-loop/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: capability-loop
+description: "When an agent fails, diagnose which capability is missing and build it into the repo."
+triggers: [capability loop, failure loop, build capability, missing capability, agent failed, why did it fail]
+priority: 75
+---
+
+# Capability Loop — Failure → Capability Building
+
+> **Principle**: "Ask what capability is missing, not why it failed." Every failure is a missing tool, guardrail, abstraction, or piece of documentation. Build the capability so the failure NEVER recurs.
+
+## When to Use
+
+| Trigger | Signal |
+|---------|--------|
+| Agent fails a task | Error, wrong output, timeout, confusion |
+| Same error occurs twice | Pattern of missing capability |
+| Agent asks clarifying question | Information not discoverable |
+| Review finds recurring issue | Systemic gap, not one-off mistake |
+| Manual intervention needed | Agent should have been self-sufficient |
+
+## Core Flow
+
+```
+FAILURE → DIAGNOSE → CLASSIFY → BUILD → VERIFY → PERSIST
+```
+
+### Step 1: DIAGNOSE — What Capability is Missing?
+
+Do NOT ask "why did it fail?" Instead ask: **"What would have prevented this failure?"**
+
+```
+Diagnosis questions (answer ALL):
+
+1. TOOL: Did the agent lack a tool to accomplish the task?
+   → Missing CLI command, missing API, missing utility function
+
+2. GUARDRAIL: Did the agent do something it shouldn't have?
+   → Missing lint rule, missing test, missing hook check
+
+3. ABSTRACTION: Did the agent struggle with unnecessary complexity?
+   → Missing helper, missing wrapper, missing shared module
+
+4. DOCUMENTATION: Did the agent lack discoverable information?
+   → Missing CLAUDE.md entry, missing code comment, missing type definition
+
+5. FEEDBACK: Did the agent not know it was doing the wrong thing?
+   → Missing error message, missing test assertion, missing type error
+```
+
+### Step 2: CLASSIFY — What Type of Capability?
+
+| Category | Example | Where to Build |
+|----------|---------|---------------|
+| **Tool** | "No way to validate schema" | New CLI command or skill |
+| **Guardrail** | "Accidentally deleted migration" | New hook or test |
+| **Abstraction** | "Copy-pasted auth logic 3 times" | New shared module |
+| **Documentation** | "Didn't know config format" | CLAUDE.md or code comments |
+| **Feedback** | "Didn't realize test was wrong" | Better error messages or types |
+
+### Step 3: BUILD — Create the Capability
+
+Based on classification, build the appropriate artifact:
+
+#### Tool → New Skill or Command
+```
+1. Create skills/{capability-name}/SKILL.md
+2. Add triggers for automatic activation
+3. Test with a simulated scenario
+```
+
+#### Guardrail → New Test or Hook
+```
+1. Add test to tests/arch-guard.test.ts (if structural)
+2. Or add check to hooks/scripts/ (if runtime)
+3. Verify it catches the original failure
+```
+
+#### Abstraction → New Module
+```
+1. Extract shared code into appropriate location
+2. Update existing callers to use new abstraction
+3. Add tests for the abstraction
+```
+
+#### Documentation → CLAUDE.md or Inline
+```
+1. If it's a constraint/gotcha → add to CLAUDE.md "Gotchas" section
+2. If it's discoverable from code → add code comment or type definition
+3. If it's a pattern → add to relevant language rule file
+```
+
+#### Feedback → Better Types or Errors
+```
+1. Add TypeScript type that prevents the mistake at compile time
+2. Or add runtime validation with clear error message
+3. Or add test that catches the mistake early
+```
+
+### Step 4: VERIFY — Reproduce and Confirm Fix
+
+```
+1. Reproduce the original failure scenario
+2. Confirm the new capability prevents it
+3. Run existing tests to verify no regressions
+4. If the capability is a test, verify it FAILS without the fix
+```
+
+### Step 5: PERSIST — Record for Future Reference
+
+Save the capability-building decision:
+
+```
+save_memory("capability-{name}", {
+  failure: "description of what failed",
+  diagnosis: "what capability was missing",
+  category: "tool|guardrail|abstraction|documentation|feedback",
+  solution: "what was built",
+  files_changed: ["list of files"]
+})
+```
+
+Update `.claude/vibe/capabilities-log.md`:
+
+```markdown
+## {date} — {capability-name}
+
+**Failure**: {what happened}
+**Missing**: {what capability was absent}
+**Built**: {what was created}
+**Files**: {list}
+**Prevents**: {what class of failures this prevents}
+```
+
+## Decision Tree
+
+```
+Agent failed
+    │
+    ├─ Could a TOOL have done it automatically?
+    │   YES → Build tool (skill/command/script)
+    │
+    ├─ Should the agent have been PREVENTED from doing it?
+    │   YES → Build guardrail (hook/test/lint rule)
+    │
+    ├─ Was the agent REPEATING work that should be shared?
+    │   YES → Build abstraction (module/helper/utility)
+    │
+    ├─ Did the agent lack KNOWLEDGE it needed?
+    │   YES → Add documentation (CLAUDE.md/comments/types)
+    │
+    └─ Did the agent not KNOW it was wrong?
+        YES → Build feedback (types/errors/tests)
+```
+
+## Anti-patterns
+
+- "Add a note to be more careful" → Build a guardrail instead
+- "Document the right way to do it" → If possible, make the wrong way a compile/test error
+- "Tell the agent to check X first" → Make X discoverable automatically
+- "It was a one-off mistake" → If it happened once, it will happen again. Build the capability.
+
+## Integration Points
+
+- After `/vibe.run` failure → auto-trigger capability-loop diagnosis
+- After `/vibe.review` findings → suggest capability-loop for recurring patterns
+- After manual agent correction → prompt "What capability would have prevented this?"