@su-record/vibe 3.2.64 → 4.0.0

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

@@ -1,83 +0,0 @@
----
-name: vibe.user-personas
-invocation: [auto, chain]
-tier: standard
-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]
----
-
-# 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
-
-Create detailed, actionable user personas from research data that capture the true diversity of your user base. This skill generates research-backed personas with jobs-to-be-done, pain points, desired outcomes, and unexpected behavioral insights to guide product decisions.
-
-## Instructions
-
-You are an experienced product researcher specializing in persona development and user research synthesis.
-
-### Input
-
-Your task is to create 3 refined user personas for **$ARGUMENTS**.
-
-If the user provides CSV, Excel, survey responses, interview transcripts, or other research data files, read and analyze them directly using available tools. Extract key patterns, demographics, motivations, and behaviors.
-
-### Analysis Steps (Think Step by Step)
-
-1. **Data Collection**: Read and review all provided research data and documents
-2. **Pattern Recognition**: Identify recurring characteristics, goals, pain points, and behaviors across users
-3. **Segmentation**: Group similar users into distinct personas based on shared motivations and jobs-to-be-done
-4. **Enrichment**: For each persona, synthesize data into a coherent profile
-5. **Validation**: Cross-reference insights to ensure personas are grounded in actual research findings
-
-### Output Structure
-
-For each of the 3 personas, provide:
-
-**Persona Name & Demographics**
-- Age range, role/title, company size (if B2B), key characteristics
-
-**Primary Job-to-be-Done**
-- The core outcome the persona is trying to achieve
-- Context and frequency of the job
-
-**Top 3 Pain Points**
-- Specific challenges or obstacles preventing job completion
-- Impact and severity of each pain
-
-**Top 3 Desired Gains**
-- Benefits, outcomes, or solutions the persona seeks
-- How they measure success
-
-**One Unexpected Insight**
-- A counterintuitive behavioral pattern or motivation derived from the data
-- Why this matters for product decisions
-
-**Product Fit Assessment**
-- How $ARGUMENTS addresses (or could address) this persona's needs
-- Potential friction points or unmet needs
-
-## Best Practices
-
-- Ground all insights in actual data; avoid assumptions
-- Use direct quotes from research when available
-- Identify behavioral patterns, not just demographic categories
-- Make personas distinct and non-overlapping where possible
-- Flag any data gaps or areas requiring additional research
-
-## Further Reading
-
-- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate)
-- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques)
-- [Jobs-to-be-Done Masterclass with Tony Ulwick and Sabeen Sattar](https://www.productcompass.pm/p/jobs-to-be-done-masterclass-with)

package/skills/vibe.user-personas/rubrics/research-methods.md

@@ -1,56 +0,0 @@
-# Persona Research Methodology
-
-## Research Method Selection
-
-| Situation | Recommended Method | Sample Size |
-|-----------|-------------------|-------------|
-| New product, no users yet | Exploratory interviews | 8–12 participants |
-| Existing product, need depth | In-depth interviews | 5–8 per segment |
-| Validating existing personas | Survey | 50+ respondents |
-| Behavioral patterns | Analytics + session recordings | All available data |
-| Competitive landscape | Competitor review + job forums | Qualitative |
-
-## Interview Design Checklist
-
-- [ ] Questions focus on past behavior, not hypothetical future behavior
-- [ ] "Tell me about a time when..." used instead of "Would you...?"
-- [ ] No leading questions (avoid "Don't you find X frustrating?")
-- [ ] Follow-up probes prepared: "Why?", "What happened next?", "How did that make you feel?"
-- [ ] Job-to-be-done lens: ask what they're trying to accomplish, not what features they want
-- [ ] Session recorded (with consent) for later synthesis
-- [ ] Duration: 45–60 minutes per interview
-
-## Data Collection Quality Gates
-
-- [ ] Minimum 5 interviews per distinct segment before drawing conclusions
-- [ ] Direct quotes captured verbatim (not paraphrased during interview)
-- [ ] Demographic bias checked — sample matches target market
-- [ ] B2B: multiple roles interviewed (buyer, user, influencer)
-- [ ] Negative cases included — interview users who churned or rejected the product
-
-## Synthesis Process
-
-1. **Affinity mapping**: Group raw observations by theme (not by participant)
-2. **Pattern extraction**: Identify recurring pain points and jobs across 3+ participants
-3. **Segmentation**: Cluster participants by shared motivations (not demographics)
-4. **Persona drafting**: One persona per distinct motivation cluster
-5. **Validation**: Cross-reference each persona claim against source data
-
-## Persona Validity Checklist
-
-- [ ] Each persona grounded in ≥3 real participants from research
-- [ ] Personas are mutually distinct — overlapping personas should be merged
-- [ ] Unexpected insights included — if all insights are obvious, dig deeper
-- [ ] Demographics are secondary — job-to-be-done drives persona definition
-- [ ] Quotes used are verbatim from research (not invented)
-- [ ] Data gaps explicitly flagged — don't fill gaps with assumptions
-
-## Common Research Mistakes
-
-| Mistake | Consequence | Fix |
-|---------|-------------|-----|
-| Asking "what features do you want?" | Users design solutions, not needs | Ask about current behavior and pain |
-| Only interviewing enthusiasts | Survivorship bias | Include churned users and non-adopters |
-| Conflating segment with persona | Personas become stereotypes | Base personas on motivations, not age/gender |
-| Too many personas (>5) | Team ignores them | Merge overlapping clusters, max 3–4 |
-| No data gaps acknowledged | False confidence | Flag what you don't yet know |

package/skills/vibe.user-personas/templates/persona.md

@@ -1,89 +0,0 @@
-# User Persona: {{PERSONA_NAME}}
-
-> Product: {{PRODUCT_NAME}} | Research basis: {{DATA_SOURCE}} | Created: {{DATE}}
-
----
-
-## Identity
-
-| Field | Value |
-|-------|-------|
-| Name (fictional) | {{PERSONA_NAME}} |
-| Age range | {{AGE_RANGE}} |
-| Role / Title | {{ROLE}} |
-| Company size | {{COMPANY_SIZE}} (if B2B) |
-| Location | {{LOCATION}} |
-| Tech comfort | {{LOW / MEDIUM / HIGH}} |
-
-**In their own words**: "{{REPRESENTATIVE_QUOTE_FROM_RESEARCH}}"
-
----
-
-## Primary Job-to-be-Done
-
-> {{THE CORE OUTCOME THIS PERSONA IS TRYING TO ACHIEVE}}
-
-**Context**: {{WHEN AND HOW OFTEN DOES THIS JOB ARISE?}}
-**Definition of done**: {{HOW DOES THIS PERSONA KNOW THEY SUCCEEDED?}}
-
----
-
-## Top 3 Pain Points
-
-| # | Pain | Impact | Severity |
-|---|------|--------|----------|
-| 1 | {{PAIN_1}} | {{CONSEQUENCE}} | High / Med / Low |
-| 2 | {{PAIN_2}} | {{CONSEQUENCE}} | High / Med / Low |
-| 3 | {{PAIN_3}} | {{CONSEQUENCE}} | High / Med / Low |
-
----
-
-## Top 3 Desired Gains
-
-| # | Gain | How They Measure It |
-|---|------|---------------------|
-| 1 | {{GAIN_1}} | {{METRIC_OR_FEELING}} |
-| 2 | {{GAIN_2}} | {{METRIC_OR_FEELING}} |
-| 3 | {{GAIN_3}} | {{METRIC_OR_FEELING}} |
-
----
-
-## Unexpected Insight
-
-> {{A COUNTERINTUITIVE BEHAVIORAL PATTERN OR MOTIVATION FROM RESEARCH DATA}}
-
-**Why it matters for product decisions**: {{IMPLICATION}}
-
----
-
-## Current Alternatives
-
-How does this persona solve the problem today?
-
-| Alternative | Why they use it | What frustrates them |
-|-------------|----------------|----------------------|
-| {{ALT_1}} | {{REASON}} | {{FRUSTRATION}} |
-| {{ALT_2}} | {{REASON}} | {{FRUSTRATION}} |
-
----
-
-## Product Fit Assessment
-
-**How {{PRODUCT_NAME}} addresses their needs**:
-- {{FIT_POINT_1}}
-- {{FIT_POINT_2}}
-
-**Potential friction points**:
-- {{FRICTION_1}}
-- {{FRICTION_2}}
-
-**Unmet needs (future opportunities)**:
-- {{UNMET_NEED_1}}
-
----
-
-## Data Sources
-
-- {{SOURCE_1}} (e.g., "10 user interviews, March 2026")
-- {{SOURCE_2}} (e.g., "NPS survey, n=142")
-- **Data gaps**: {{WHAT WE DON'T KNOW YET}}

package/skills/vibe.verify/SKILL.md

@@ -1,175 +0,0 @@
----
-name: vibe.verify
-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
-
-```
-/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.
-- Verification target = the SPEC's Done criteria + Given/When/Then scenarios. Read whatever is needed to judge each criterion accurately; choose your own reading strategy, but never mark a criterion passed without concrete evidence (test exit code, build result, or a verified code location).
-
-## Process
-
-### 1. Load SPEC / Feature
-
-Search order (folder first, then single file):
-
-1. `.vibe/features/{feature}/` (split structure: `_index.feature` + `phase-N-*.feature`) or `.vibe/specs/{feature}/` (`_index.md` + phase files) — read `_index` first, then verify phase by phase
-2. `.vibe/features/{feature}.feature` or `.vibe/specs/{feature}.md`
-3. Neither exists → error:
-
-```
-❌ Feature file not found. Run /vibe.spec "{feature}" first.
-```
-
-Extract the Done criteria / scenarios — this list is the verification checklist.
-
-### 2. Verify each Done criterion (parallel, deterministic)
-
-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 |
-|---|---|---|
-| Test execution | `npm test` (judge by exit code) | test files exist |
-| Build | `npm run build` | build script exists |
-| Type check | `tsc --noEmit` / code-reviewer agent (focus: idioms) | TypeScript project |
-| Code analysis | verify Given/When/Then logic against changed files | always |
-| E2E closed loop | e2e-tester agent drives browser scenarios | `--e2e` flag or UI scenarios |
-
-**E2E closed loop** (`--e2e`): per scenario — navigate → interact → assert. On fail: collect evidence (screenshot, console errors) → root-cause → fix → re-run **only the failed scenario**. Prefer accessibility-tree tools over raw DOM dumps to keep the loop cheap.
-
-### 3. Visual drift (auto, only if `DESIGN.md` exists + UI stack)
-
-```
-Load skill `vibe.design` with: verify --files=<changed-ui-files>
-```
-
-P1 drift (hex hardcoded outside the DESIGN.md token set) → verify fails. DESIGN.md absent → notify and silently skip (never block).
-
-### 4. Result summary (short markdown — no box art)
-
-```markdown
-## Verify: {feature} — PASS | FAIL (n/m criteria)
-
-| Done criterion | Result | Evidence |
-|---|---|---|
-| Valid login returns JWT | PASS | auth.test.ts 12/12; src/auth/login.ts:42 |
-| Forgot-password link | FAIL | LoginForm.tsx:42 — link not implemented |
-
-Build: OK · Tests: 12/12 · Types: 0 errors
-Next: /vibe.run "{feature}" --fix   ← only when FAIL
-```
-
-One row per Done criterion: pass/fail + an evidence pointer (file:line, test name, or command result). Failure rows state expected vs actual and the exact location.
-
-**Pass condition**: ALL Done criteria pass AND build/tests/type check pass. Anything else = FAIL.
-
-### 5. Failure auto-register (MANDATORY on any failed criterion)
-
-Before printing the failure summary, register each failed scenario as a regression bug so the same failure cannot silently slip through again:
-
-```
-Load skill `vibe.regress` with:
-  subcommand: register --from-verify
-  feature: {feature}   scenario: {scenario}
-  error: {error-summary}   location: {file:line}
-```
-
-`--from-verify` skips user confirmation. The bug slug appears in the summary's Fix line. Follow up with `/vibe.regress generate <slug>` for a preventive test.
-
-### 6. Post-verify contract check (auto, only when a contract file exists)
-
-After all criteria pass, if `.vibe/contracts/{feature}.md` exists:
-
-```
-Load skill `vibe.contract` with: check "{feature}"
-```
-
-- No drift → verify still passes
-- **P1 drift** → demote verify to FAIL; auto-call `/vibe.regress register --from-contract`
-- P2/P3 drift → warning only
-
-### 7. Metrics + Ledger update (MANDATORY final step)
-
-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)
-node -e "
-const fs=require('fs'),p='.vibe/metrics';
-try{const c=JSON.parse(fs.readFileSync(p+'/current-run.json','utf-8'));
-fs.appendFileSync(p+'/history.jsonl',JSON.stringify({verifiedAt:new Date().toISOString(),feature:c.feature,startedAt:c.startedAt,steps:c.steps||0})+'\n');}catch{}"
-
-# Write the exact commands run in steps 2-3 and their exit codes.
-mkdir -p .vibe/metrics
-# Write `.vibe/metrics/verification-results.json` as:
-# [{"command":"npm test","exitCode":0}, ...]
-
-# Bind the result to the current run and its command evidence.
-HOOKS_DIR="${VIBE_PATH:-$(npm root -g 2>/dev/null)/@su-record/vibe}/hooks/scripts"
-RUN_ID=$(node -p "JSON.parse(require('fs').readFileSync('.vibe/metrics/run-ledger.json','utf8')).runId")
-[ -f "$HOOKS_DIR/verify-ledger.js" ] && node "$HOOKS_DIR/verify-ledger.js" pass "$RUN_ID" .vibe/metrics/verification-results.json   # or: fail
-
-# Recipe extraction (best-effort, silent)
-[ -f "$HOOKS_DIR/recipe-extractor.js" ] && node "$HOOKS_DIR/recipe-extractor.js" 2>/dev/null || true
-```
-
-Use `pass` only when the summary in step 4 is PASS; otherwise `fail`. A passing record requires at least one command result and every exit code must be zero. A stale run ID, missing evidence, or mismatched result leaves `verifyPassed` unset and downstream gates treat the run as unverified.
-
-## Failure escalation (convergence-based, no retry cap)
-
-```
-fix → re-verify → still failing?
-  different error → progress, continue looping
-  same error as previous attempt → STUCK:
-    interactive: ask user (fix hint / "proceed" → record .vibe/todos/verify-failure-{scenario}.md / "abort")
-    autonomous (automationLevel: autonomous): record TODO, continue to next scenario
-```
-
-## Next step
-
-- PASS → proceed to the next feature
-- FAIL → `/vibe.run "{feature}" --fix`
-
----
-
-ARGUMENTS: $ARGUMENTS

package/skills/vibe.verify/references/trace-mode.md

@@ -1,271 +0,0 @@
----
-name: verify-trace-mode-reference
-description: Generate and display Requirements Traceability Matrix (RTM) — REQ → SPEC → Feature → Code 관계 추적
-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**: Query the system clock at START and 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: {system clock result}
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Example
-
-```
-User: /vibe.trace "login"
-
-Active harness:
-📊 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/spec/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/spec/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` |
-| Explicit JUDGE | Run `/vibe.verify`; it must record `verifyPassed` and command evidence before completion |
-| Lifecycle hook (optional) | May warn when `runStarted && !verifyPassed`; never substitutes for the explicit JUDGE |
-
-**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}