@su-record/vibe 2.16.3 → 3.0.0

package/skills/video-production/SKILL.md

@@ -3,7 +3,7 @@ name: video-production
 invocation: [auto]
 tier: standard
 description: "Video processing gotchas — FFmpeg commands, transcoding pipelines, HLS/DASH streaming setup, subtitle embedding (SRT/VTT), and thumbnail extraction. Use when the project involves any video manipulation, media processing, or streaming infrastructure. Covers codec selection, bitrate optimization, and common FFmpeg pitfalls. Must use this skill when user works with video files, mentions FFmpeg, or needs media processing — even for simple tasks like 'generate a thumbnail'."
-triggers: [video, ffmpeg, transcode, encode, stream, media, subtitle, thumbnail, hls, dash]
+triggers: [video, ffmpeg, transcode, subtitle, thumbnail, hls, video encoding, media processing]
 priority: 60
 ---
 

package/vibe/rules/orchestrator-contract.md

@@ -0,0 +1,57 @@
+# Orchestrator Contract — orchestrator 스킬 작성 계약 (SSOT)
+
+> `type: orchestrator` 스킬(fan-out/fan-in 으로 서브에이전트를 조율하는 스킬)의
+> **구조·스키마·네이밍 규칙**의 유일한 정의다. 각 orchestrator.md 는 이 스키마를 따르되
+> **내용(phase·실패모드·에이전트)은 스킬별로 고유**하다 — 내용을 공유 파일로 병합하지 않는다.
+>
+> 대상: `skills/{techdebt,parallel-research,exec-plan,design-review,create-prd}/orchestrator.md`
+
+## Frontmatter
+
+```yaml
+---
+name: <skill>-orchestrator      # 스킬 디렉토리명 + "-orchestrator"
+type: orchestrator
+agents: [<agent-basename>, ...]  # skills/<skill>/agents/ 의 파일 basename (접두사 없이)
+---
+```
+
+## 필수 섹션 (순서 고정)
+
+1. `## Workflow` — `### Phase N: <이름>` 목록. 각 Phase 는 아래 4개 필드를 갖는다:
+   - `**Agent**:` — 이 Phase 를 수행하는 에이전트의 **basename**(복수 가능), 또는 `orchestrator (self)`
+   - `**Input**:` / `**Output**:` — 데이터 계약
+   - `**Parallel**:` — `yes`/`no` + 한 줄 근거
+2. `## DAG (Dependency Graph)` — Phase 의존 관계를 `mermaid graph TD` 로.
+3. `## Error Handling` — 스키마 고정 3열 테이블. 행 내용은 스킬별 고유:
+
+   | Phase | Failure Mode | Strategy |
+   |-------|-------------|----------|
+
+4. `## Scalability Modes` — 스키마 고정 3열 테이블. `Full`/`Reduced`/`Single` 3-tier 분류:
+
+   | Mode | When | Agents Used |
+   |------|------|-------------|
+
+## 에이전트 네이밍 규칙
+
+전역 에이전트(`agents/**/*.md`, `CLAUDE_MODEL_MAPPING` 키)와의 **이름 충돌을 피하기 위해**
+skill-local 에이전트는 접두사를 붙인다:
+
+- 에이전트 파일의 frontmatter `name:` = `<prefix>-<agent-basename>`
+- 에이전트끼리의 상호 참조("Reports findings to: …", "… from …")도 **접두사 이름**으로
+- 단, orchestrator.md 의 frontmatter `agents:[]` 와 Workflow `**Agent**:` 는 **basename**(접두사 없이) — 파일명과 일치
+
+**Prefix registry** (스킬 → 접두사):
+
+| Skill | Prefix | 예 |
+|-------|--------|-----|
+| techdebt | `techdebt` | `techdebt-scanner` |
+| exec-plan | `plan` | `plan-decomposer` |
+| design-review | `design` | `design-a11y-auditor` |
+| parallel-research | `research` | `research-best-practices` |
+| create-prd | `prd` | `prd-requirements-writer` |
+
+> WHY: `reviewer`, `scorer`, `a11y-auditor` 등은 전역 에이전트/리뷰어(code-reviewer,
+> design-reviewer 등)와 basename 이 겹치거나 혼동된다. 접두사가 없으면 조율 LLM 이
+> 전역 에이전트와 skill-local 에이전트를 혼동한다.

package/vibe/rules/quality/performance.md

@@ -233,4 +233,4 @@ function findDuplicates(arr: string[]): string[] {
 - [ ] 대량 데이터 처리 시 스트리밍/청크 처리 적용
 - [ ] 메모리 누수 점검 (이벤트 리스너 해제, 타이머 정리)
 
-> **vibe 도구 연계**: `core_analyze_complexity`로 함수 복잡도 측정, `/vibe.review`의 performance-reviewer 에이전트로 자동 성능 리뷰
+> **vibe 도구 연계**: `core_analyze_complexity`로 함수 복잡도 측정, `/vibe.review`의 code-reviewer(focus: performance) 에이전트로 자동 성능 리뷰

package/vibe/templates/claudemd-template.md

@@ -68,7 +68,7 @@ At 85%+ context: `save_memory` → `/new` → `/vibe.utils --continue` (raised f
 
 ## Git Commit Rules
 
-**Include:** `.vibe/plans/`, `.vibe/specs/`, `.vibe/features/`, `.vibe/config.json`, `CLAUDE.md`
+**Include:** `.vibe/specs/`, `.vibe/features/`, `.vibe/config.json`, `CLAUDE.md` (legacy `.vibe/plans/` 는 있으면 유지)
 **Exclude:** `~/.claude/vibe/rules/`, `~/.claude/commands/`, `~/.claude/agents/`, `~/.claude/skills/`, `.claude/settings.local.json`
 
 <!-- VIBE:END -->

package/vibe/templates/spec-template.md

@@ -1,221 +1,71 @@
 # SPEC: {Feature Name}
 
-## Metadata
-
 - **Created**: {YYYY-MM-DD}
-- **Author**: {Name}
-- **Status**: DRAFT
-- **Priority**: {HIGH | MEDIUM | LOW}
-- **Language**: {en | ko}
-- **Assigned Agent**: {Agent Name}
-- **Tech Stack**: {Project Tech Stack Summary}
+- **Status**: DRAFT | APPROVED
+- **Tech Stack**: {Project tech stack summary}
 
 ---
 
-## 1. Feature Overview
-
-{1-2 sentence summary}
-
-### Background
-
-{Why is this feature needed}
-
-### Goals
-
-- Goal 1
-- Goal 2
-
-### Non-Goals
-
-- What we won't do this time 1
-- What we won't do this time 2
+## 1. Overview / Goal
 
-### Tech Stack Context
+{What and why — 1-3 sentences.}
 
-**Existing Technology:**
+### Assumptions
 
-- Backend: {FastAPI, Django, Express, etc.}
-- Frontend: {React, Flutter, Vue, etc.}
-- Database: {PostgreSQL, MySQL, MongoDB, etc.}
-- Infrastructure: {GCP, AWS, Azure, etc.}
-
-**New Technology Required for This Feature:**
-
-- {New library/service 1} - {Reason}
-- {New library/service 2} - {Reason}
-
-**External API/Service Integration:**
-
-- {Service name} - {Purpose}
-
-**Constraints:**
-
-- Cost limit: {Amount}
-- Performance requirements: {Target response time, throughput, etc.}
+- {Default adopted without asking — e.g., session expiry 24h}
 
 ---
 
-## 2. User Stories
-
-### Story 1: {Story Title}
-
-**As a** {User role}
-**I want** {Desired functionality}
-**So that** {Reason/Value}
+## 2. Done Criteria (deterministic gates)
 
-#### Acceptance Criteria
+> Each criterion must be judgeable by a command or observable behavior — never by self-report.
+> These are the JUDGE inputs of the loop (`vibe/rules/loop-contract.md`); `/vibe.verify` records the result in `.vibe/metrics/run-ledger.json`.
 
-- [ ] {Verifiable condition 1}
-- [ ] {Verifiable condition 2}
+| # | Criterion | Verified by |
+|---|-----------|-------------|
+| D1 | {e.g., all scenarios in the feature file pass} | {e.g., `npx vitest run` exit 0} |
+| D2 | {e.g., build succeeds with no type errors} | {e.g., `npm run build` exit 0} |
 
 ---
 
-## 3. Requirements (EARS Format)
+## 3. Scenarios
 
-### REQ-001: {Requirement Title}
+> Mirrored to `.vibe/features/{feature}.feature` (gherkin). Every scenario maps to a Done criterion.
 
-**WHEN** {Specific condition}
-**THEN** {System behavior} (SHALL | SHOULD | MAY)
-
-#### Acceptance Criteria
-
-- [ ] {Testable criterion 1}
-- [ ] {Testable criterion 2}
-
-#### Example
-
-```text
-Input: {...}
-Output: {...}
+```gherkin
+Scenario: {Happy path title}          # → D1
+  Given {precondition}
+  When {action}
+  Then {expected result}
+
+Scenario: {Edge case title}           # → D1
+  Given {precondition}
+  When {action}
+  Then {expected result}
 ```
 
 ---
 
-## 4. Non-Functional Requirements
-
-### Performance
-
-- Response time: {Target}
-- Throughput: {Target}
-
-### Security
-
-- Authentication: {Method}
-- Authorization: {Rules}
-
-### Scalability
-
-- Expected growth rate: {Value}
-
----
-
-## 5. Data Model (Draft)
-
-### Entity: {Name}
+## 4. Out of Scope
 
-```json
-{
-  "field1": "type",
-  "field2": "type"
-}
-```
+- {Explicitly not doing this time — must not be empty}
 
 ---
 
-## 6. API Contract (Draft)
+## 5. API Contract (only if the feature exposes an API)
 
-### Endpoint: {Name}
+> Presence of this section enables `/vibe.contract` drift detection.
 
 ```text
-POST /api/v1/resource
+POST /api/v1/{resource}
 Request: {...}
-Response: {...}
-```
-
----
-
-## 7. Test Strategy
-
-### BDD Scenarios (Gherkin)
-
-**Generate Command**: `vibe feature "{feature name}"`
-
-```gherkin
-Scenario: {Scenario title}
-  Given {Precondition}
-  When {User action}
-  Then {Expected result}
-```
-
-**Mapping**:
-
-- REQ-001 → Scenario 1, 2
-- REQ-002 → Scenario 3
-
-### Contract Tests (API Schema)
-
-**Generate Command**: `vibe contract "{feature name}"`
-
-**Backend Contract**:
-
-```json
-{
-  "request": {
-    "method": "POST",
-    "path": "/api/v1/{resource}",
-    "schema": {JSON Schema}
-  },
-  "response": {
-    "status": 201,
-    "schema": {JSON Schema}
-  }
-}
+Response: 201 {...}
 ```
 
-**Frontend Contract**:
-
-- Independent testing with mock server
-- Response schema validation (Zod, JSON Schema)
-
-### Test Coverage Goals
-
-- [ ] BDD: Cover all Acceptance Criteria
-- [ ] Contract: Cover all API endpoints
-- [ ] Unit: 70%+ coverage
-- [ ] Integration: Cover critical paths
-
----
-
-## 8. Out of Scope
-
-- ❌ {Excluded item 1}
-- ❌ {Excluded item 2}
-
 ---
 
-## 9. Verification Checklist
-
-### Requirements
-
-- [ ] Are all requirements testable?
-- [ ] Is SHALL/SHOULD/MAY clear?
-- [ ] Are Acceptance Criteria specific?
-- [ ] Are performance goals measurable?
-
-### Testing
-
-- [ ] BDD Feature file generation complete?
-- [ ] Contract tests defined?
-- [ ] Step Definitions written?
-- [ ] Test coverage goal achieved?
-
----
-
-## 10. Approval
-
-- [ ] User approval
-- [ ] Technical review complete
-- [ ] Test plan approved
+## 6. Verification
 
-Approval Date: ____________
-Approver: ____________
+- `/vibe.run "{feature}"` implements scenario-by-scenario, verifying each immediately.
+- `/vibe.verify "{feature}"` judges the Done Criteria and sets `verifyPassed` in the run-ledger.
+- Gate = all Done Criteria pass (exit codes / observed behavior) — loop continues until gates pass, stuck, or max iterations.

package/agents/architect-low.md

@@ -1,41 +0,0 @@
-# Architect Agent - Low Tier (Haiku)
-
-Quick architecture queries and pattern matching.
-
-## Role
-
-- Architecture pattern lookup
-- Quick structure analysis
-- Simple design questions
-
-## Model
-
-**Haiku** - Fast pattern matching
-
-## When to Use
-
-- "What pattern does this use?"
-- "Where is X defined?"
-- Simple structural questions
-
-## Usage
-
-```
-Task(model: "haiku", subagent_type: "general-purpose", prompt: "What architecture pattern does this service use?")
-```
-
-## Process
-
-1. Quick codebase scan
-2. Pattern identification
-3. Return finding
-
-## Output
-
-```markdown
-## Architecture Query Result
-
-Pattern: Repository Pattern
-Location: src/repositories/
-Evidence: UserRepository, ProductRepository classes
-```

package/agents/architect-medium.md

@@ -1,59 +0,0 @@
-# Architect Agent - Medium Tier (Sonnet)
-
-Module-level architecture and design.
-
-## Role
-
-- Module architecture
-- Component design
-- API design
-- Local optimization
-
-## Model
-
-**Sonnet** - Balanced for module-level decisions
-
-## When to Use
-
-- Single module design
-- API endpoint design
-- Component hierarchy
-- Local refactoring decisions
-
-## Usage
-
-```
-Task(model: "sonnet", subagent_type: "general-purpose", prompt: "Design the user service module")
-```
-
-## Process
-
-1. Understand module requirements
-2. Review existing patterns
-3. Design component structure
-4. Define interfaces
-5. Document decision
-
-## Output
-
-```markdown
-## Module Design
-
-### Structure
-```
-src/user/
-├── index.ts (exports)
-├── service.ts (business logic)
-├── repository.ts (data access)
-├── types.ts (type definitions)
-└── __tests__/
-```
-
-### Interfaces
-- UserService: create, read, update, delete
-- UserRepository: find, save, remove
-
-### Dependencies
-- Depends on: auth, database
-- Used by: profile, settings
-```