@su-record/vibe 2.7.12 → 2.7.14

package/skills/arch-guard/SKILL.md

@@ -1,180 +1,180 @@
----
-name: arch-guard
-description: "Generate architecture boundary tests that mechanically enforce layer constraints."
-triggers: [arch guard, architecture test, layer test, boundary test, structural test, arch validation]
-priority: 60
----
-
-# Arch Guard — Architecture Boundary Test Generator
-
-> **Principle**: "Mechanical enforcement over documentation." If a rule exists only in docs, it will be violated. Turn architecture constraints into failing tests.
-
-## When to Use
-
-| Scenario | Signal |
-|----------|--------|
-| `vibe init` / `vibe update` | Auto-generate for detected stack |
-| New layer/module added | Boundaries need enforcement |
-| Architecture violation found in review | Prevent recurrence with test |
-| "Services should not import UI" type rules | Turn into automated check |
-
-## Core Flow
-
-```
-DETECT → INFER → GENERATE → VERIFY
-```
-
-### Step 1: DETECT — Identify Project Architecture
-
-Analyze the project to determine its layer structure:
-
-```
-Parallel exploration:
-- Agent 1: Scan directory structure (src/, app/, lib/, etc.)
-- Agent 2: Read existing architecture docs (CLAUDE.md, README, ADR)
-- Agent 3: Analyze import graph (which files import what)
-```
-
-**Common patterns to detect:**
-
-| Pattern | Layers | Typical Stacks |
-|---------|--------|----------------|
-| MVC | Controller → Service → Model | Rails, NestJS, Spring |
-| Clean Architecture | UI → Application → Domain → Infrastructure | General |
-| Feature-based | Feature A ↛ Feature B internals | Next.js, React |
-| Hexagonal | Adapters → Ports → Domain | DDD projects |
-| Component hierarchy | Page → Feature → Shared → UI Primitives | Frontend |
-
-### Step 2: INFER — Define Boundary Rules
-
-From detected structure, generate rules:
-
-```typescript
-// Rule format
-interface ArchRule {
-  name: string;           // "service-no-ui-import"
-  from: string;           // Glob pattern: "src/services/**"
-  cannotImport: string[]; // ["src/components/**", "src/pages/**"]
-  canImport: string[];    // ["src/models/**", "src/utils/**"]
-  reason: string;         // "Services must be UI-agnostic"
-}
-```
-
-**Default rules by stack:**
-
-| Stack | Rule |
-|-------|------|
-| Next.js / React | `components/` cannot import from `pages/` or `app/` |
-| Next.js / React | `lib/` cannot import from `components/` |
-| NestJS | `*.service.ts` cannot import from `*.controller.ts` |
-| NestJS | `*.module.ts` is the only valid cross-boundary import |
-| General TS | `src/domain/` cannot import from `src/infra/` |
-| General TS | No circular dependencies between top-level dirs |
-| Python Django | `models.py` cannot import from `views.py` |
-| Python FastAPI | `schemas/` cannot import from `routers/` |
-
-### Step 3: GENERATE — Create Test File
-
-Output: `tests/arch-guard.test.ts` (or equivalent for stack)
-
-```typescript
-/**
- * Architecture Boundary Tests
- * Generated by arch-guard skill
- *
- * These tests enforce architectural constraints mechanically.
- * If a test fails, it means an import violates the intended architecture.
- */
-import { describe, it, expect } from 'vitest';
-import fs from 'fs';
-import path from 'path';
-
-// Helper: extract imports from a file
-function extractImports(filePath: string): string[] {
-  const content = fs.readFileSync(filePath, 'utf-8');
-  const importRegex = /(?:import|require)\s*\(?['"]([^'"]+)['"]\)?/g;
-  const imports: string[] = [];
-  let match;
-  while ((match = importRegex.exec(content)) !== null) {
-    imports.push(match[1]);
-  }
-  return imports;
-}
-
-// Helper: resolve relative import to absolute path
-function resolveImport(fromFile: string, importPath: string): string {
-  if (importPath.startsWith('.')) {
-    return path.resolve(path.dirname(fromFile), importPath);
-  }
-  return importPath; // external package
-}
-
-// Helper: glob files matching pattern
-function globFiles(pattern: string, baseDir: string): string[] {
-  // Use fast-glob or manual recursive scan
-  // Implementation depends on available dependencies
-}
-
-describe('Architecture Boundaries', () => {
-  // GENERATED RULES GO HERE
-  // Each rule becomes a test case:
-
-  it('services cannot import UI components', () => {
-    const serviceFiles = globFiles('src/services/**/*.ts', process.cwd());
-    const violations: string[] = [];
-
-    for (const file of serviceFiles) {
-      const imports = extractImports(file);
-      for (const imp of imports) {
-        const resolved = resolveImport(file, imp);
-        if (resolved.includes('/components/') || resolved.includes('/pages/')) {
-          violations.push(`${file} imports ${imp}`);
-        }
-      }
-    }
-
-    expect(violations).toEqual([]);
-  });
-});
-```
-
-### Step 4: VERIFY — Run and Fix
-
-1. Run the generated tests: `npx vitest run tests/arch-guard.test.ts`
-2. If violations found:
-   - Report each violation with file:line
-   - Suggest fix (move shared code to appropriate layer)
-   - Do NOT auto-fix — violations need human review
-
-## Output Files
-
-| File | Purpose |
-|------|---------|
-| `tests/arch-guard.test.ts` | Executable boundary tests |
-| `.claude/vibe/arch-rules.json` | Machine-readable rules (for CI) |
-
-## Customization
-
-Users can add custom rules to `.claude/vibe/arch-rules.json`:
-
-```json
-{
-  "rules": [
-    {
-      "name": "no-direct-db-in-handlers",
-      "from": "src/handlers/**",
-      "cannotImport": ["src/db/**"],
-      "reason": "Handlers must use services, not direct DB access"
-    }
-  ]
-}
-```
-
-The test generator reads this file and adds custom rules to the test suite.
-
-## Integration
-
-- `vibe init` → auto-detect and generate initial arch-guard tests
-- `vibe update` → refresh rules if directory structure changed
-- Pre-commit hook → run arch-guard tests before commit
-- `/vibe.review` → architecture-reviewer checks against arch-rules.json
+---
+name: arch-guard
+description: "Generate architecture boundary tests that mechanically enforce layer constraints."
+triggers: [arch guard, architecture test, layer test, boundary test, structural test, arch validation]
+priority: 60
+---
+
+# Arch Guard — Architecture Boundary Test Generator
+
+> **Principle**: "Mechanical enforcement over documentation." If a rule exists only in docs, it will be violated. Turn architecture constraints into failing tests.
+
+## When to Use
+
+| Scenario | Signal |
+|----------|--------|
+| `vibe init` / `vibe update` | Auto-generate for detected stack |
+| New layer/module added | Boundaries need enforcement |
+| Architecture violation found in review | Prevent recurrence with test |
+| "Services should not import UI" type rules | Turn into automated check |
+
+## Core Flow
+
+```
+DETECT → INFER → GENERATE → VERIFY
+```
+
+### Step 1: DETECT — Identify Project Architecture
+
+Analyze the project to determine its layer structure:
+
+```
+Parallel exploration:
+- Agent 1: Scan directory structure (src/, app/, lib/, etc.)
+- Agent 2: Read existing architecture docs (CLAUDE.md, README, ADR)
+- Agent 3: Analyze import graph (which files import what)
+```
+
+**Common patterns to detect:**
+
+| Pattern | Layers | Typical Stacks |
+|---------|--------|----------------|
+| MVC | Controller → Service → Model | Rails, NestJS, Spring |
+| Clean Architecture | UI → Application → Domain → Infrastructure | General |
+| Feature-based | Feature A ↛ Feature B internals | Next.js, React |
+| Hexagonal | Adapters → Ports → Domain | DDD projects |
+| Component hierarchy | Page → Feature → Shared → UI Primitives | Frontend |
+
+### Step 2: INFER — Define Boundary Rules
+
+From detected structure, generate rules:
+
+```typescript
+// Rule format
+interface ArchRule {
+  name: string;           // "service-no-ui-import"
+  from: string;           // Glob pattern: "src/services/**"
+  cannotImport: string[]; // ["src/components/**", "src/pages/**"]
+  canImport: string[];    // ["src/models/**", "src/utils/**"]
+  reason: string;         // "Services must be UI-agnostic"
+}
+```
+
+**Default rules by stack:**
+
+| Stack | Rule |
+|-------|------|
+| Next.js / React | `components/` cannot import from `pages/` or `app/` |
+| Next.js / React | `lib/` cannot import from `components/` |
+| NestJS | `*.service.ts` cannot import from `*.controller.ts` |
+| NestJS | `*.module.ts` is the only valid cross-boundary import |
+| General TS | `src/domain/` cannot import from `src/infra/` |
+| General TS | No circular dependencies between top-level dirs |
+| Python Django | `models.py` cannot import from `views.py` |
+| Python FastAPI | `schemas/` cannot import from `routers/` |
+
+### Step 3: GENERATE — Create Test File
+
+Output: `tests/arch-guard.test.ts` (or equivalent for stack)
+
+```typescript
+/**
+ * Architecture Boundary Tests
+ * Generated by arch-guard skill
+ *
+ * These tests enforce architectural constraints mechanically.
+ * If a test fails, it means an import violates the intended architecture.
+ */
+import { describe, it, expect } from 'vitest';
+import fs from 'fs';
+import path from 'path';
+
+// Helper: extract imports from a file
+function extractImports(filePath: string): string[] {
+  const content = fs.readFileSync(filePath, 'utf-8');
+  const importRegex = /(?:import|require)\s*\(?['"]([^'"]+)['"]\)?/g;
+  const imports: string[] = [];
+  let match;
+  while ((match = importRegex.exec(content)) !== null) {
+    imports.push(match[1]);
+  }
+  return imports;
+}
+
+// Helper: resolve relative import to absolute path
+function resolveImport(fromFile: string, importPath: string): string {
+  if (importPath.startsWith('.')) {
+    return path.resolve(path.dirname(fromFile), importPath);
+  }
+  return importPath; // external package
+}
+
+// Helper: glob files matching pattern
+function globFiles(pattern: string, baseDir: string): string[] {
+  // Use fast-glob or manual recursive scan
+  // Implementation depends on available dependencies
+}
+
+describe('Architecture Boundaries', () => {
+  // GENERATED RULES GO HERE
+  // Each rule becomes a test case:
+
+  it('services cannot import UI components', () => {
+    const serviceFiles = globFiles('src/services/**/*.ts', process.cwd());
+    const violations: string[] = [];
+
+    for (const file of serviceFiles) {
+      const imports = extractImports(file);
+      for (const imp of imports) {
+        const resolved = resolveImport(file, imp);
+        if (resolved.includes('/components/') || resolved.includes('/pages/')) {
+          violations.push(`${file} imports ${imp}`);
+        }
+      }
+    }
+
+    expect(violations).toEqual([]);
+  });
+});
+```
+
+### Step 4: VERIFY — Run and Fix
+
+1. Run the generated tests: `npx vitest run tests/arch-guard.test.ts`
+2. If violations found:
+   - Report each violation with file:line
+   - Suggest fix (move shared code to appropriate layer)
+   - Do NOT auto-fix — violations need human review
+
+## Output Files
+
+| File | Purpose |
+|------|---------|
+| `tests/arch-guard.test.ts` | Executable boundary tests |
+| `.claude/vibe/arch-rules.json` | Machine-readable rules (for CI) |
+
+## Customization
+
+Users can add custom rules to `.claude/vibe/arch-rules.json`:
+
+```json
+{
+  "rules": [
+    {
+      "name": "no-direct-db-in-handlers",
+      "from": "src/handlers/**",
+      "cannotImport": ["src/db/**"],
+      "reason": "Handlers must use services, not direct DB access"
+    }
+  ]
+}
+```
+
+The test generator reads this file and adds custom rules to the test suite.
+
+## Integration
+
+- `vibe init` → auto-detect and generate initial arch-guard tests
+- `vibe update` → refresh rules if directory structure changed
+- Pre-commit hook → run arch-guard tests before commit
+- `/vibe.review` → architecture-reviewer checks against arch-rules.json

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