@su-record/vibe 3.2.6 → 3.2.8

package/skills/vibe.test/references/report-template.md

@@ -0,0 +1,101 @@
+# vibe.test — Report Template (JSON + Markdown)
+
+> vibe.test SKILL.md 의 Report 섹션에서 참조. `~/.vibe/test-reports/<ts>-<harness>.{json,md}` 의 정확한 스키마.
+
+## Report template
+
+Written to `~/.vibe/test-reports/<YYYYMMDD-HHmm>-<harness>.{json,md}`. Exact schema:
+
+### JSON
+
+```json
+{
+  "harness": "cc",
+  "timestamp": "2026-04-16T18:30:00+09:00",
+  "vibe_version": "2.9.24",
+  "install_dir": "/Users/grove/.claude",
+  "summary": {
+    "total": 42,
+    "passed": 38,
+    "warned": 2,
+    "failed": 2
+  },
+  "probes": {
+    "entrySkills": [
+      { "name": "vibe.spec", "status": "pass" },
+      { "name": "vibe.test", "status": "pass" }
+    ],
+    "skills": [
+      { "name": "vibe.verify", "status": "pass",
+        "quality": { "scope": "pass", "context": "pass", "trigger": "pass", "verify": "pass" } },
+      { "name": "vibe.run", "status": "fail",
+        "quality": { "scope": "fail", "context": "warn", "trigger": "warn", "verify": "warn" },
+        "error": "scope: 845 lines (>400)" },
+      { "name": "spec", "status": "fail", "error": "invocation includes `auto` but triggers array is empty" }
+    ],
+    "hooks": [
+      { "name": "pre-tool-guard", "status": "pass", "tests": "38/38" },
+      { "name": "scope-guard", "status": "pass", "tests": "12/12" }
+    ],
+    "agents": [
+      { "name": "implementer", "status": "pass" },
+      { "name": "ui/design-reviewer", "status": "pass" },
+      { "name": "event/event-planner", "status": "pass" }
+    ]
+  },
+  "failed": [
+    {
+      "category": "skills",
+      "name": "spec",
+      "error": "frontmatter: triggers array is empty"
+    }
+  ],
+  "warned": [
+    {
+      "category": "skills",
+      "name": "vibe.docs",
+      "error": "verify: no Done Criteria section"
+    }
+  ]
+}
+```
+
+- `status`: `"pass"` | `"warn"` | `"fail"` — worst verdict across the entry's structural check and its four quality axes
+- `error`: required when `status` is `"warn"` or `"fail"`, omitted otherwise. Prefix with the axis (`scope:`, `context:`, `trigger:`, `verify:`) when the verdict comes from a quality axis
+- `quality` (skills only): per-axis verdicts — `{ scope, context, trigger, verify }`, each `"pass"` | `"warn"` | `"fail"` | `"n/a"` (alias-exempt axis)
+- `tests` (hooks only): short `passed/total` string from the vitest JSON reporter
+- `failed[]`: flat list of every `fail` for quick scanning — mirrors entries found across `probes.*`
+- `warned[]`: same shape as `failed[]`, for `warn` entries. **Advisory only — never feeds `/vibe.regress`**
+
+### Markdown
+
+```markdown
+# vibe self-test · cc · 2026-04-16 18:30
+
+**Version**: 2.9.24   **Install**: /Users/grove/.claude
+
+| Category | Pass | Warn | Fail |
+|---|---:|---:|---:|
+| entry skills | 15 | 0 | 0 |
+| skills   | 15 | 2 | 1 |
+| hooks    |  6 | 0 | 0 |
+| agents   |  3 | 0 | 1 |
+| **total**| **39** | **2** | **2** |
+
+## Skill quality (STCV)
+
+| Skill | Scope | Context | Trigger | Verify |
+|---|---|---|---|---|
+| vibe.run | ❌ 845 | ⚠️ | ⚠️ | ⚠️ |
+| vibe.docs | ⚠️ 292 | ✅ | ✅ | ⚠️ |
+
+Only skills with at least one non-pass axis are listed. If every skill passes all four axes,
+replace this section with `_All skills pass STCV._`
+
+## Failures
+
+- **skills / spec** — invocation includes `auto` but triggers array is empty
+- **agents / implementer** — agent file not found
+```
+
+If `failed` is empty, replace the Failures section with `_All probes passed._`.

package/skills/vibe.tool-fallback/SKILL.md

@@ -2,7 +2,7 @@
 name: vibe.tool-fallback
 invocation: [auto]
 tier: optional
-description: "Tool failure fallback strategies with circuit breaker. Auto-activates on API errors, search failures, timeouts, 429, 5xx, overloaded errors."
+description: "Use when a tool or provider returns API errors, search failures, timeouts, 429, 5xx, or overload responses and a circuit-breaker fallback is required."
 triggers: [search failure, 429, 5xx, overloaded, fallback, circuit breaker, rate limit]
 priority: 60
 ---
@@ -33,32 +33,11 @@ priority: 60
 
 ## Decision Trees
 
-### Web Search Fails
+Select exactly one conditional reference for the failing capability; unrelated failures do not load it:
 
-```
-Web Search fails (429, 529, timeout)
-  → Check circuit state
-  → OPEN? → Skip to alternative immediately
-  → CLOSED? → Try context7 for library docs
-  → Still fails? → Claude's built-in knowledge (last resort)
-```
-
-### External LLM Fails
-
-```
-VibeOrchestrator.smartRoute({ type, prompt })
-  → Primary LLM fails (429, 401, 5xx)
-  → Skip to secondary LLM (no retry on rate limit)
-  → Secondary fails → Claude handles directly
-```
-
-### File/Code Not Found
-
-```
-Glob fails → Expand pattern: *.ts → **/*.ts → **/*
-  → Use Grep for content-based search
-  → Check git log for file history
-```
+- Web search failure → `references/web-search.md`
+- External LLM failure → `references/external-llm.md`
+- File/code lookup failure → `references/file-lookup.md`
 
 ## Error Response Actions
 
@@ -83,13 +62,12 @@ Request → Check circuit
                       └─ Use alternative
 ```
 
-## LLM Priority by Task Type
+## Model Selection
 
-| Task Type | Primary → Secondary → Fallback |
-|-----------|-------------------------------|
-| architecture, debugging | GPT → Antigravity → Claude |
-| uiux, code-analysis | Antigravity → GPT → Claude |
-| code-gen, general | Claude only |
+Inherit the active session model by default. Use the configured provider/model
+SSOT for external fallbacks instead of a hardcoded provider order. The only
+permitted override is an `opus` tier for an explicitly requested deep
+architecture review; if unavailable, keep the inherited model.
 
 ## Principles
 

package/skills/vibe.tool-fallback/references/external-llm.md

@@ -0,0 +1,10 @@
+# External LLM Fallback
+
+Load only for external LLM failures.
+
+```
+VibeOrchestrator.smartRoute({ type, prompt })
+  → Primary LLM fails (429, 401, 5xx)
+  → Skip to secondary LLM (no retry on rate limit)
+  → Secondary fails → active harness handles directly
+```

package/skills/vibe.tool-fallback/references/file-lookup.md

@@ -0,0 +1,9 @@
+# File and Code Lookup Fallback
+
+Load only for file or code lookup failures.
+
+```
+File-pattern search fails → Expand pattern: *.ts → **/*.ts → **/*
+  → Use content-based text search
+  → Check git log for file history
+```

package/skills/vibe.tool-fallback/references/web-search.md

@@ -0,0 +1,11 @@
+# Web Search Fallback
+
+Load only for web search failures.
+
+```
+Web Search fails (429, 529, timeout)
+  → Check circuit state
+  → OPEN? → Skip to alternative immediately
+  → CLOSED? → Try Context7 for library docs
+  → Still fails? → active harness knowledge (last resort, label uncertainty)
+```

package/skills/vibe.trace/SKILL.md

@@ -1,270 +1,8 @@
 ---
 name: vibe.trace
-description: Generate and display Requirements Traceability Matrix (RTM) — REQ → SPEC → Feature → Code 관계 추적
+description: 요구사항과 구현의 추적 관계를 확인하거나 RTM이 필요할 때 vibe.verify trace mode를 로드하는 호환 진입점이다.
 argument-hint: "feature-name [--html] [--save]"
 user-invocable: true
 ---
 
-# /vibe.trace
-
-Generate and display Requirements Traceability Matrix (RTM).
-
-## Usage
-
-```bash
-/vibe.trace "feature-name"              # Generate RTM for feature
-/vibe.trace "feature-name" --html       # Output as HTML
-/vibe.trace "feature-name" --save       # Save to file
-```
-
-> **⏱️ Timer**: Call `getCurrentTime` tool at the START. Record the result as `{start_time}`.
-
-## Description
-
-Requirements Traceability Matrix (RTM) tracks the relationship between:
-- **Requirements** (REQ-xxx-xxx)
-- **SPEC sections** (Phase tasks)
-- **Feature scenarios** (BDD)
-- **Test files** (unit/integration tests)
-
-## Process
-
-### 1. Load Files
-
-**Search order (check BOTH file AND folder):**
-
-```
-Step 1: Check if SPLIT structure exists (folder)
-  📁 .vibe/specs/{feature-name}/        → Folder with _index.md + phase files
-  📁 .vibe/features/{feature-name}/      → Folder with _index.feature + phase files
-
-Step 2: If no folder, check single file
-  📄 .vibe/specs/{feature-name}.md       → Single SPEC file
-  📄 .vibe/features/{feature-name}.feature → Single Feature file
-
-Step 3: If neither exists → Error
-```
-
-**Split structure (folder) detected:**
-```
-📁 .vibe/specs/{feature-name}/
-├── _index.md              → Master SPEC (read first)
-├── phase-1-{name}.md      → Phase 1 SPEC
-└── ...
-
-📁 .vibe/features/{feature-name}/
-├── _index.feature         → Master Feature (read first)
-├── phase-1-{name}.feature → Phase 1 scenarios
-└── ...
-
-→ Load all phase files, generate RTM across all phases
-```
-
-**Single file detected:**
-```
-📄 .vibe/specs/{feature-name}.md      → SPEC
-📄 .vibe/features/{feature-name}.feature → Feature
-```
-
-**Additional (auto-detect):**
-```
-📄 src/**/*.test.ts                           → Tests (auto-detect)
-```
-
-**Error if NEITHER file NOR folder found:**
-```
-❌ SPEC not found. Searched:
-   - .vibe/specs/{feature-name}/  (folder)
-   - .vibe/specs/{feature-name}.md (file)
-
-   Run /vibe.spec "{feature-name}" first.
-```
-
-### 2. Extract Mappings
-
-For each requirement ID (REQ-xxx-xxx):
-1. Find corresponding SPEC section
-2. Find matching Feature scenario
-3. Find related test file
-
-### 3. Calculate Coverage
-
-```
-Coverage = (Full coverage items / Total requirements) × 100%
-
-Full coverage = Has SPEC + Feature + Test
-Partial = Missing one or more
-None = Only in SPEC
-```
-
-### 4. Output RTM
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📊 REQUIREMENTS TRACEABILITY MATRIX: {feature-name}
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-## Summary
-| Metric            | Value    |
-|-------------------|----------|
-| Total Requirements| 10       |
-| SPEC Coverage     | 10/10    |
-| Feature Coverage  | 8/10     |
-| Test Coverage     | 6/10     |
-| **Overall**       | **60%**  |
-
-## Traceability Matrix
-
-| Requirement | SPEC | Feature | Test | Coverage |
-|-------------|------|---------|------|----------|
-| REQ-login-001 | ✅ Phase 1 | ✅ Scenario 1 | ✅ login.test.ts | ✅ Full |
-| REQ-login-002 | ✅ Phase 1 | ✅ Scenario 2 | ❌ | ⚠️ Partial |
-| REQ-login-003 | ✅ Phase 2 | ❌ | ❌ | ❌ None |
-
-## Uncovered Requirements
-
-The following requirements lack full coverage:
-
-- **REQ-login-002**: Password validation
-  - Missing: Test file
-
-- **REQ-login-003**: Remember me functionality
-  - Missing: Feature scenario, Test file
-
-## Recommendations
-
-⚠️ Coverage is at 60%. Consider:
-- Add Feature scenarios for uncovered requirements
-- Add test cases for uncovered requirements
-
-⏱️ Started: {start_time}
-⏱️ Completed: {getCurrentTime 결과}
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Example
-
-```
-User: /vibe.trace "login"
-
-Claude:
-📊 Generating RTM for "login"...
-
-Loading files:
-  ✅ SPEC: .vibe/specs/login.md (5 requirements)
-  ✅ Feature: .vibe/features/login.feature (4 scenarios)
-  ✅ Tests: 3 test files found
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📊 REQUIREMENTS TRACEABILITY MATRIX: login
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-## Summary
-| Metric            | Value    |
-|-------------------|----------|
-| Total Requirements| 5        |
-| SPEC Coverage     | 5/5      |
-| Feature Coverage  | 4/5      |
-| Test Coverage     | 3/5      |
-| **Overall**       | **60%**  |
-
-## Traceability Matrix
-
-| Requirement | SPEC | Feature | Test | Coverage |
-|-------------|------|---------|------|----------|
-| REQ-login-001 | ✅ | ✅ | ✅ | ✅ Full |
-| REQ-login-002 | ✅ | ✅ | ✅ | ✅ Full |
-| REQ-login-003 | ✅ | ✅ | ✅ | ✅ Full |
-| REQ-login-004 | ✅ | ✅ | ❌ | ⚠️ Partial |
-| REQ-login-005 | ✅ | ❌ | ❌ | ❌ None |
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Tool Integration
-
-The RTM generation uses core tools:
-
-```bash
-# Generate RTM (generateTraceabilityMatrix is synchronous — no .then())
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => { const m = t.generateTraceabilityMatrix('login', {projectPath: process.cwd()}); console.log(t.formatMatrixAsMarkdown(m)); })"
-
-# Generate HTML
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => { const m = t.generateTraceabilityMatrix('login', {projectPath: process.cwd()}); console.log(t.formatMatrixAsHtml(m)); })"
-```
-
-> **Note:** Default SPEC path is `.vibe/specs/<feature>.md` (falls back to `.claude/vibe/specs/` then `.claude/specs/` for legacy projects).
-> `status === 'empty'` means the gate MUST be treated as failed/not-applicable, never as 100% pass.
-
-## Post-Trace Gates
-
-After `/vibe.trace` completes and the RTM is displayed, two downstream mechanisms consume the result.
-
-### Empty-result gate
-
-`generateTraceabilityMatrix` returns `status: 'empty'` when no `REQ-<feature>-NNN` IDs are found in the SPEC. This state **must be treated as a gate failure**, not as 100% coverage. When the matrix status is `empty`, report it explicitly and do not proceed as if the feature is verified.
-
-```
-RTM status === 'empty'
-  → Coverage gate: FAILED (no requirements to trace)
-  → Action: run /vibe.spec to add REQ-IDs before re-running /vibe.trace
-```
-
-### Run-ledger flow
-
-`/vibe.verify` records its outcome through `hooks/scripts/verify-ledger.js`, binding the current run ID and command-result evidence. This writes `verifyPassed` and `verifyAt` into `.vibe/metrics/run-ledger.json`. Downstream gates consume this record:
-
-| Gate | Behavior |
-|------|----------|
-| `auto-commit` | Commits only when `verifyPassed === true` AND `verifyAt > runStarted` |
-| Stop hook | Warns when `runStarted && !verifyPassed`; blocks once if `verifyGate.mode === 'block'` |
-
-**To register a passing trace as verified**, run `/vibe.verify` after `/vibe.trace` reports acceptable coverage. The verify skill records the current run ID and command evidence internally — you do not invoke the ledger CLI manually.
-
-```
-/vibe.trace "login"         → RTM: 9/9 (100%)
-/vibe.verify "login"        → runs checks → records pass + run ID + command results
-                            → .vibe/metrics/run-ledger.json updated
-auto-commit / Stop gate     → verifyPassed=true, gate clears
-```
-
-If `/vibe.verify` is skipped, `auto-commit` will log the skip reason and abort the commit.
-
-## Options
-
-| Option | Description |
-|--------|-------------|
-| `--html` | Output as HTML file |
-| `--save` | Save to `.vibe/reports/{feature}-rtm.md` |
-| `--json` | Output as JSON |
-
-## Coverage Targets
-
-| Coverage Level | Status |
-|----------------|--------|
-| 90-100% | ✅ Excellent - Ready for release |
-| 70-89% | ⚠️ Good - Minor gaps |
-| 50-69% | ⚠️ Fair - Significant gaps |
-| 0-49% | ❌ Poor - Major gaps |
-
----
-
-## `.last-feature` 포인터 삭제 (워크플로 완주)
-
-```
-/vibe.trace가 정상 완료되면 (RTM 출력 + 사용자 확인 후):
-  Delete ".vibe/.last-feature"
-
-이유: /vibe.trace는 vibe 워크플로의 마지막 Phase (Phase 7).
-     완주 후에는 다음 /vibe.spec 호출 시 "빈 시작" 또는 진행 중 목록에서 다른 feature를 시작해야 한다.
-     삭제하지 않으면 완료된 feature가 계속 "이어서?" 로 뜬다.
-
-예외:
-  - /vibe.trace가 에러로 중단된 경우 → 삭제하지 않음 (재시도 가능)
-  - --save 또는 --html 플래그와 무관하게 항상 삭제
-```
-
----
-
-ARGUMENTS: {feature-name}
+Load `vibe.verify` in trace mode and preserve the feature name and all output flags.

package/skills/vibe.ui-ux-pro-max/SKILL.md

@@ -79,9 +79,7 @@ Searchable database: 50+ styles, 97 color palettes, 57 font pairings, 99 UX guid
 
 ### 8. Charts & Data (LOW)
 
-- `chart-type` - Match chart type to data type
-- `color-guidance` - Use accessible color palettes
-- `data-table` - Provide table alternative for accessibility
+For dashboards or other data visualizations only, read `references/charts-and-data.md`. UI calls without charts do not load it.
 
 ---
 

package/skills/vibe.ui-ux-pro-max/references/charts-and-data.md

@@ -0,0 +1,7 @@
+# Charts and Data Visualization
+
+Load only when the requested UI includes charts or data visualization.
+
+- `chart-type` — Match chart type to data type.
+- `color-guidance` — Use accessible color palettes.
+- `data-table` — Provide a table alternative for accessibility.

package/skills/vibe.user-personas/SKILL.md

@@ -2,7 +2,7 @@
 name: vibe.user-personas
 invocation: [auto, chain]
 tier: standard
-description: "Create refined user personas from research data — 3 personas with JTBD, pains, gains, and unexpected insights."
+description: "Use when research data must be synthesized into three evidence-based user personas with JTBD, pains, gains, and unexpected insights."
 triggers: [persona, user persona, user profile, user segment, user research]
 priority: 50
 chain-next: [vibe.create-prd, vibe.prioritization]
@@ -10,6 +10,13 @@ chain-next: [vibe.create-prd, vibe.prioritization]
 
 # User Personas
 
+## Done Criteria
+
+- [ ] 정확히 3개의 persona가 생성되어 있다.
+- [ ] 각 persona에 JTBD, pains, gains가 모두 존재한다.
+- [ ] 각 핵심 특성이 research source와 연결되어 있다.
+- [ ] 근거 없는 추론은 inference로 표시되어 있다.
+
 > Based on the user persona framework from [Product Compass](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) by Pawel Huryn (MIT License).
 
 ## Purpose

package/skills/vibe.verify/SKILL.md

@@ -1,12 +1,19 @@
 ---
 name: vibe.verify
-description: Verify implementation against SPEC requirements
-argument-hint: "feature name"
+description: 승인된 SPEC에 대한 구현 완료를 판정하거나 REQ→SPEC→Feature→Code 추적표가 필요할 때 검증 또는 trace mode로 실행한다.
+argument-hint: "feature name [--e2e] | trace feature-name [--html] [--save] [--json]"
 user-invocable: true
 ---
 
 # /vibe.verify
 
+## 완료 기준
+
+- [ ] 승인된 SPEC의 모든 REQ가 pass 또는 fail로 판정되어 있다.
+- [ ] 각 판정에 test output, 파일·행 또는 산출물 경로 근거가 있다.
+- [ ] verify mode 성공 시 run ledger의 `verifyPassed`가 true다.
+- [ ] trace mode에서는 RTM 파일이 존재하고 누락 REQ가 0개다.
+
 SPEC-driven verification. Check the implementation against the SPEC's **Done criteria** and Feature scenarios, record the result to the **run ledger** (`recordVerify`), and auto-register regressions on failure. The JUDGE gate is code-enforced by the ledger — a verification never counts as passed by self-report.
 
 ## Usage
@@ -14,8 +21,18 @@ SPEC-driven verification. Check the implementation against the SPEC's **Done cri
 ```
 /vibe.verify "feature-name"           # SPEC-based verification
 /vibe.verify --e2e "feature-name"     # + E2E browser verification (agents/e2e-tester.md)
+/vibe.verify trace "feature-name"     # Requirements Traceability Matrix
+/vibe.verify trace "feature-name" --html | --save | --json
 ```
 
+## Trace mode
+
+When the first argument is `trace`, read `references/trace-mode.md` and execute
+that RTM workflow instead of the verification process below. Preserve the
+feature name and `--html`, `--save`, and `--json` flags. An empty RTM is a gate
+failure. Trace output alone does not set `verifyPassed`; run normal verify mode
+to bind command evidence to the run ledger.
+
 ## Scope
 
 - **Changed files only** — never full-project scan.
@@ -39,7 +56,11 @@ Extract the Done criteria / scenarios — this list is the verification checklis
 
 ### 2. Verify each Done criterion (parallel, deterministic)
 
-Run all applicable methods as parallel sub-agents in ONE message; each returns a short pass/fail summary instead of bloating main context:
+Run all applicable methods through the harness's native collaboration
+capability; each worker returns a short pass/fail summary instead of bloating
+the coordinator context. Claude Code maps workers to Task/Agent; Codex maps
+them to native collaboration. Inherit the session model by default and run
+independent methods concurrently when capacity permits:
 
 | Method | How | Condition |
 |---|---|---|
@@ -104,7 +125,12 @@ Load skill `vibe.contract` with: check "{feature}"
 
 ### 7. Metrics + Ledger update (MANDATORY final step)
 
-Record run metrics, then write the verify result to the run ledger. This is the machine-readable deterministic JUDGE record consumed by the Stop-hook verify gate, auto-commit verify gate, and loop-contract gates. `recordVerify` also writes `.vibe/runs/{run-id}/evidence.json`; Model Judge findings remain advisory-only and Human Taste remains release-only.
+Record run metrics, then explicitly write the verify result to the run ledger.
+This machine-readable record is the deterministic JUDGE consumed by the
+loop-contract gates. Lifecycle Stop/auto-commit hooks may consume the same
+record for earlier feedback, but correctness does not depend on either hook.
+`recordVerify` also writes `.vibe/runs/{run-id}/evidence.json`; Model Judge
+findings remain advisory-only and Human Taste remains release-only.
 
 ```bash
 # Append step-count history (ok if current-run.json missing)