@su-record/vibe 3.2.6 → 3.2.7

package/skills/vibe.llm/SKILL.md

@@ -1,12 +1,19 @@
 ---
 name: vibe.llm
-description: Refresh available models for claude/openai(api+oauth)/gemini/zai as of now and update the vibe model SSOT
+description: provider별 사용 가능 모델이 바뀌었거나 현재 claude/openai/gemini/zai 모델 목록과 vibe model SSOT를 갱신할 때 사용한다.
 argument-hint: "list | refresh"
 user-invocable: true
 ---
 
 # /vibe.llm
 
+## 완료 기준
+
+- [ ] 각 provider의 모델 조회가 성공 또는 명시적 실패로 기록되어 있다.
+- [ ] model SSOT가 조회 결과와 일치한다.
+- [ ] 중복 model ID가 없다.
+- [ ] SSOT 검증 명령이 통과한다.
+
 현재 시점 기준으로 각 LLM provider(claude, openai API+oauth, gemini, zai)의
 **사용 가능한 모델을 최신화**하고, vibe 가 쓰는 **모델 SSOT(`~/.vibe/config.json` models)**를 갱신한다.
 

package/skills/vibe.loop/SKILL.md

@@ -1,12 +1,19 @@
 ---
 name: vibe.loop
-description: Loop engineering — design, install, and run autonomous goal loops whose completion is judged by deterministic gates, not self-report
+description: 반복 작업을 자율 goal loop로 설계·설치·실행하고 결정론적 gate로 완료를 판정해야 할 때 사용한다.
 argument-hint: "design | install | run | status | list [loop-name]"
 user-invocable: true
 ---
 
 # /vibe.loop
 
+## 완료 기준
+
+- [ ] loop 정의에 ANCHOR, ACT, JUDGE, RECORD가 모두 있다.
+- [ ] JUDGE가 exit code, 파일 상태 또는 ledger 값으로 판정된다.
+- [ ] stuck 조건과 max_iterations가 명시되어 있다.
+- [ ] 실행 결과가 pass, stuck, max_iterations 중 하나로 기록된다.
+
 **Loop Engineering** — 사람이 프롬프트하는 대신, 에이전트에게 프롬프트하는 루프를 설계한다.
 
 > 루프의 완료 판정은 모델의 자기 보고가 아니라 **결정론적 게이트**(run-ledger `verifyPassed`, 테스트 exit code)가 내린다.
@@ -55,16 +62,7 @@ node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index
 
 ## install — 스케줄 연결
 
-루프 정의는 하네스 중립이다. 현재 환경을 감지해 정확한 설치 명령을 **사용자에게 제시**한다 (직접 등록하지 않는다 — 스케줄 등록은 사용자 결정):
-
-| 환경 | 명령 |
-|------|------|
-| Claude Code (세션 루프) | `/loop <interval> "/vibe.loop run <name>"` |
-| Claude Code (클라우드 루틴) | `/schedule` 로 cron `<schedule>` + 프롬프트 `/vibe.loop run <name>` 등록 |
-| OS cron 폴백 | `<schedule> cd <project> && claude -p "/vibe.loop run <name>" --permission-mode acceptEdits` |
-| Codex | Automations 탭에 `<schedule>` + `$vibe.loop run <name>` 등록 |
-
-`trigger: manual` 루프는 install 불필요 — run만 안내한다.
+`install` 호출에서만 `references/install-adapters.md`를 읽어 현재 하네스의 명령을 제시한다. `design`, `run`, `status`, `list` 호출은 읽지 않는다. `trigger: manual` 루프는 install 없이 run만 안내한다.
 
 ## run — 1회 반복 실행 (핵심)
 

package/skills/vibe.loop/references/install-adapters.md

@@ -0,0 +1,10 @@
+# Loop Install Adapters
+
+Load only for `vibe.loop install`. Never register a schedule without the user's decision.
+
+| 환경 | 명령 |
+|------|------|
+| Claude Code (세션 루프) | `/loop <interval> "/vibe.loop run <name>"` |
+| Claude Code (클라우드 루틴) | `/schedule`로 cron `<schedule>` + prompt `/vibe.loop run <name>` 등록 |
+| OS cron fallback | `<schedule> cd <project> && claude -p "/vibe.loop run <name>" --permission-mode acceptEdits` |
+| Codex | Automations에 `<schedule>` + `$vibe.loop run <name>` 등록 |

package/skills/vibe.presentation/SKILL.md

@@ -10,6 +10,13 @@ user-invocable: true
 
 # Presentation Builder
 
+## 완료 기준
+
+- [ ] 요청된 16:9 HTML slide deck이 존재한다.
+- [ ] 모든 slide가 1920×1080 viewport에서 overflow 없이 렌더링된다.
+- [ ] 인용한 사실에 source가 연결되어 있다.
+- [ ] PDF 요청 시 PDF 파일이 생성되어 있다.
+
 소스 데이터 → 디자인 시스템 적용 LLM → HTML 슬라이드덱 → 1920×1080 PDF.
 
 ## 핵심 원칙

package/skills/vibe.prioritization/SKILL.md

@@ -10,6 +10,13 @@ chain-next: [vibe.create-prd]
 
 # Prioritization Frameworks Reference
 
+## Done Criteria
+
+- [ ] 선택한 framework와 선택 근거가 기록되어 있다.
+- [ ] 모든 평가 대상에 framework의 필수 입력값이 있다.
+- [ ] 정의된 산식으로 점수가 계산되어 있다.
+- [ ] 최종 정렬 순서와 동점 처리 기준이 명시되어 있다.
+
 > Based on the Product Frameworks Compendium from [Product Compass](https://www.productcompass.pm/p/the-product-frameworks-compendium) by Pawel Huryn (MIT License).
 
 A reference guide to help you select and apply the right prioritization framework for your context.

package/skills/vibe.priority-todos/SKILL.md

@@ -1,66 +1,11 @@
 ---
 name: vibe.priority-todos
+description: Use when TODOs or review findings must be organized by P1/P2/P3; compatibility alias for vibe.review priority-todos mode.
 user-invocable: false
 invocation: [auto]
 tier: standard
-description: "Priority-based TODO management (P1/P2/P3). Auto-activates when managing tasks, reviewing issues, or organizing work by priority."
 triggers: [todo list, task management, P1, P2, P3, priority todos, organize tasks]
 priority: 60
 ---
 
-# Priority-Based Todo Management
-
-## Pre-check (K1)
-
-> Do you need structured priority tracking? For 1-2 item task lists, use inline TODOs. This system is for multi-issue tracking across reviews and sessions.
-
-## Priority Definitions
-
-| Priority | Meaning | Action | Examples |
-|----------|---------|--------|----------|
-| P1 | **Blocks merge** | Fix immediately | Security vulnerability, data loss risk, production incident |
-| P2 | **Should fix** | Fix before PR | Performance issue, missing tests, architecture violation |
-| P3 | **Backlog** | Fix when time permits | Code style, refactoring suggestion, documentation |
-
-## Directory Structure
-
-```
-.vibe/todos/
-├── P1-security-sql-injection.md
-├── P2-perf-n1-query.md
-├── P3-style-extract-helper.md
-├── index.md                      # Summary table with counts/status
-└── done/                         # Archived completed items
-```
-
-## Workflow
-
-```
-vibe.review (skill) → Creates P1/P2/P3 todo files + updates index.md
-     ↓
-Fix P1 first (blocks merge)
-     ↓
-Fix P2 before PR (warning only)
-     ↓
-P3 → backlog (weekly review)
-     ↓
-Mark done → moves to done/ with date prefix
-```
-
-## Todo File Format
-
-Each file follows: `# [P1] Title` → Summary → Priority Justification → Location (file:line) → Suggested Fix → Checklist (fix, test, review, merge).
-
-## Rules
-
-- P1 exists → merge is **blocked**
-- P2 → warning only, recommended to resolve
-- P3 → no blocking, backlog
-- Weekly cleanup: review and archive completed items
-
-## Done Criteria (K4)
-
-- [ ] All P1 items resolved before merge
-- [ ] P2 items reviewed and either resolved or documented
-- [ ] index.md reflects current state
-- [ ] Completed items archived to `done/` directory
+Load `vibe.review` in priority-todos mode and preserve all arguments.

package/skills/vibe.react-best-practices/SKILL.md

@@ -2,7 +2,7 @@
 name: vibe.react-best-practices
 invocation: [auto]
 tier: core
-description: "React/Next.js performance gotchas from Vercel engineering. Non-intuitive pitfalls that LLMs commonly miss."
+description: "Use when implementing or reviewing React/Next.js code where Vercel performance pitfalls, rendering behavior, or bundle efficiency must be checked."
 triggers: [react, next.js, vercel, react performance, re-render, rendering waterfall]
 priority: 60
 ---

package/skills/vibe.reason/SKILL.md

@@ -1,12 +1,19 @@
 ---
 name: vibe.reason
-description: Apply systematic reasoning framework to complex problems
+description: 복잡한 문제에서 가설·근거·트레이드오프를 구조화해 결론을 내려야 할 때 체계적 reasoning framework를 적용한다.
 argument-hint: "problem description"
 user-invocable: true
 ---
 
 # /vibe.reason
 
+## 완료 기준
+
+- [ ] 문제, 제약, 판단 기준이 명시되어 있다.
+- [ ] 각 핵심 주장에 근거 또는 명시된 가정이 연결되어 있다.
+- [ ] 검토한 대안과 탈락 이유가 기록되어 있다.
+- [ ] 결론이 판단 기준에 따라 재현 가능하게 도출되어 있다.
+
 Apply 9-step reasoning framework to complex problems.
 
 ## Usage
@@ -15,7 +22,7 @@ Apply 9-step reasoning framework to complex problems.
 /vibe.reason "problem description"
 ```
 
-> **⏱️ Timer**: Call `getCurrentTime` tool at the START. Record the result as `{start_time}`.
+> **⏱️ Timer**: Query the system clock at START and record the result as `{start_time}`.
 
 ## When to Use
 

package/skills/vibe.regress/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vibe.regress
-description: Regression test auto-evolution — register bugs, generate preventive tests, cluster patterns
+description: Use when a reproduced bug must be registered, turned into a preventive test, or clustered into a recurring root-cause pattern.
 argument-hint: "register | generate | list | import | cluster [args]"
 user-invocable: true
 ---
@@ -48,31 +48,8 @@ The `regress` skill performs registration, generation, and clustering.
 
 ## Storage Format
 
-```markdown
----
-slug: login-jwt-expiry-off-by-one
-symptom: "JWT expiry cuts off one second early"
-root-cause-tag: timezone
-fix-commit: abc1234
-test-path: src/auth/__tests__/login.regression.test.ts
-status: open | test-generated | resolved
-registered: 2026-04-14
-feature: login
----
-
-## Reproduction
-1. ...
-
-## Root cause
-...
-
-## Fix
-...
-```
-
----
-
-ARGUMENTS: $ARGUMENTS
+회귀 항목의 저장 위치와 frontmatter 스키마는 아래 **Storage Contract** 절이 SSOT다.
+`root-cause-tag` 허용값 목록도 그쪽에만 둔다 — 두 곳에 두면 한쪽이 조용히 낡는다.
 
 ## Bundled implementation
 
@@ -142,7 +119,7 @@ Clustering depends on this, so use **only the predefined set**:
 Most calls are automatic; manual use is rare (bugs found outside `/vibe.verify`, or production incidents).
 
 **Steps**:
-1. `getCurrentTime` for today's date
+1. Query the system clock for today's date
 2. `git log -1 --format=%H` for current commit hash (fix-commit candidate)
 3. Conversation extracts:
    - Reproduction steps (Given/When/Then)
@@ -163,7 +140,8 @@ Most calls are automatic; manual use is rare (bugs found outside `/vibe.verify`,
    - Sibling `__tests__/` next to the implementation file, OR
    - The project's existing test dir (vitest config `test.include`)
 4. File name: `<original-file>.regression.test.ts`
-5. Body: render `templates/test-vitest.md` or `templates/test-jest.md`
+5. Body: render `templates/test-template.md`; set `{{TEST_RUNNER_IMPORT}}` to the Vitest import below or an empty string for Jest globals:
+   - Vitest: `import { describe, it, expect{{EXTRA_IMPORTS}} } from 'vitest';`
 6. Update bug frontmatter: `test-path`, `status: test-generated`
 7. **Run the test immediately** — should fail (if not yet fixed) or pass (if fixed). Record outcome in frontmatter.
 

package/skills/vibe.regress/templates/{test-jest.md → test-template.md}

@@ -11,6 +11,7 @@
  * in the source record change.
  */
 
+{{TEST_RUNNER_IMPORT}}
 {{IMPORTS_FROM_SUT}}
 
 describe('regression: {{SYMPTOM_SHORT}}', () => {

package/skills/vibe.review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vibe.review
-description: Multi-agent parallel code review with priority-based findings
+description: Use when changed code or a SPEC needs a pre-merge review for defects, security risks, boundary mismatches, and zero remaining P1 findings.
 argument-hint: "PR number, branch name, or file path"
 user-invocable: true
 ---
@@ -18,9 +18,10 @@ user-invocable: true
 /vibe.review src/api/                # Review specific path
 /vibe.review --race                  # Multi-LLM race mode (GPT + Antigravity)
 /vibe.review --race security         # Race mode for specific review type
+/vibe.review priority-todos          # Organize findings/tasks as P1/P2/P3 TODOs
 ```
 
-> **⏱️ Timer**: Call `getCurrentTime` tool at the START. Record the result as `{start_time}`.
+> **⏱️ Timer**: Query the system clock at START and record the result as `{start_time}`.
 
 ## Codex Plugin Integration
 
@@ -142,45 +143,13 @@ Stack-specific focus (`idioms`) is added when the diff touches that stack's file
 |-------|-----------|
 | code-reviewer (focus: idioms) | Language/framework files in diff (.py / .ts / .tsx / Gemfile rails / package.json react) — prompt states the detected stack |
 
-### Phase 2.5: UI/UX Review Agents (Auto-triggered)
+### Phase 2.5: UI/UX Review Agents (조건부)
 
 > **활성화 조건**: 변경된 파일 중 UI 파일 존재 (`.tsx`, `.jsx`, `.vue`, `.svelte`, `.html`, `.css`, `.scss`)
-> **비활성화**: `.vibe/config.json`에 `"uiUxAnalysis": false` 설정
+> **비활성화**: `.vibe/config.json` 에 `"uiUxAnalysis": false`
 
-**기존 Phase 2 리뷰 에이전트와 병렬 실행 — `design-reviewer` 인스턴스 3개 (관점별):**
-
-| Agent (관점) | Role | Output |
-|-------|------|--------|
-| ⑥ design-reviewer (UX 준수) | UX 가이드라인 준수 검증 | P1/P2/P3 findings |
-| ⑦ design-reviewer (접근성) | WCAG 2.1 AA 접근성 감사 | P1/P2/P3 findings |
-| ⑧ design-reviewer (안티패턴) | UI 안티패턴 + 디자인 시스템 일관성 | P1/P2/P3 findings |
-
-**실행 방법 — 기존 Phase 2 에이전트와 병렬 실행:**
-
-```text
-# ⑥ UX 준수 검증 (Haiku)
-Task(subagent_type="design-reviewer",
-  prompt="Review UI files for UX guideline compliance: {changed_ui_files}. Use core_ui_search against ux-guidelines and web-interface domains.")
-
-# ⑦ 접근성 감사 (Haiku)
-Task(subagent_type="design-reviewer",
-  prompt="Audit UI files for WCAG 2.1 AA compliance: {changed_ui_files}.")
-
-# ⑧ 안티패턴 검출 (Haiku)
-Task(subagent_type="design-reviewer",
-  prompt="Detect UI anti-patterns in: {changed_ui_files}. Check against MASTER.md if exists at .vibe/design-system/{project}/MASTER.md.")
-```
-
-#### Visual P1 Baseline
-
-- 프로젝트 루트에 `DESIGN.md` 가 존재하면 **시각 P1 의 1 차 baseline** 으로 사용한다 (§2 Color Palette / §7 Do's & Don'ts).
-- `DESIGN.md` 부재 시 기존 폴백을 사용 (WCAG 2.1 AA + `MASTER.md` + design-review(audit 모드) 기본 5 차원).
-- v1 범위: hex 컬러 드리프트만 P1 후보. spacing / font 드리프트는 Phase 2+ 에서 추가.
-- 안티패턴 검출(⑧) 은 `DESIGN.md §7` 의 "DON'T" 항목을 우선 규칙으로 사용한다.
-
-**findings 통합**: ⑥⑦⑧ findings를 기존 findings[]와 병합 → P1/P2/P3 통합 정렬
-
-**⑦ Critical finding 에스컬레이션**: design-reviewer(접근성)의 P1 finding은 Review Debate(Phase 4.5)에 자동 포함
+조건에 걸리면 `references/ui-ux-review.md` 를 읽어 `design-reviewer` 3개 관점을 Phase 2 와 병렬 실행한다.
+UI 파일이 없으면 이 Phase 전체를 건너뛴다 — reference 도 읽지 않는다.
 
 ### Phase 2.7: Boundary Mismatch Detection (Integration Coherence)
 
@@ -297,6 +266,34 @@ Before completing review, check P1-critical items (P2/P3 are best-effort). Score
 
 > Read `references/quality-gate.md` for the full weighted checklist, score grades, merge decision matrix, auto-fix capability matrix, forbidden-patterns table, and output requirements.
 
+## Priority TODO Mode
+
+For `priority-todos` mode, or when review findings must be persisted as a
+P1/P2/P3 board, read `references/priority-todos.md`. Preserve its priority
+definitions, index/update behavior, output paths, and completion criteria.
+
 ---
 
 ARGUMENTS: $ARGUMENTS
+
+## 리뷰어 스케일링
+
+Stakes SSOT는 `vibe/rules/loop-contract.md` Stakes 표다.
+
+| stakes | 변경 파일 | reviewer set |
+|---|---|---|
+| demo | ≤5 | correctness + security 2종 |
+| demo / prototype | >5 또는 prototype | correctness + security + data-integrity 3종 |
+| production | any | Core Reviewers 전체 |
+
+Production Core Reviewers는 `security-reviewer`와 `code-reviewer`의 다음 focus를 모두 유지한다: `focus: correctness`, `focus: data-integrity`, `focus: performance`, `focus: architecture`, `focus: complexity`, `focus: git-history`, `focus: test-coverage`.
+
+## Done Criteria
+
+- [ ] Every finding has P1/P2/P3 severity and `file:line` evidence.
+- [ ] Duplicate findings are merged into one canonical item.
+- [ ] Relevant tests and static checks pass for modified files.
+- [ ] A MERGE READY result has zero P1 findings.
+- [ ] Manual items are persisted in the specified TODO artifact.
+
+ARGUMENTS: $ARGUMENTS

package/skills/vibe.review/references/priority-todos.md

@@ -0,0 +1,66 @@
+---
+name: priority-todos-reference
+user-invocable: false
+invocation: [auto]
+tier: standard
+description: "Priority-based TODO management (P1/P2/P3). Auto-activates when managing tasks, reviewing issues, or organizing work by priority."
+triggers: [todo list, task management, P1, P2, P3, priority todos, organize tasks]
+priority: 60
+---
+
+# Priority-Based Todo Management
+
+## Pre-check (K1)
+
+> Do you need structured priority tracking? For 1-2 item task lists, use inline TODOs. This system is for multi-issue tracking across reviews and sessions.
+
+## Priority Definitions
+
+| Priority | Meaning | Action | Examples |
+|----------|---------|--------|----------|
+| P1 | **Blocks merge** | Fix immediately | Security vulnerability, data loss risk, production incident |
+| P2 | **Should fix** | Fix before PR | Performance issue, missing tests, architecture violation |
+| P3 | **Backlog** | Fix when time permits | Code style, refactoring suggestion, documentation |
+
+## Directory Structure
+
+```
+.vibe/todos/
+├── P1-security-sql-injection.md
+├── P2-perf-n1-query.md
+├── P3-style-extract-helper.md
+├── index.md                      # Summary table with counts/status
+└── done/                         # Archived completed items
+```
+
+## Workflow
+
+```
+vibe.review (skill) → Creates P1/P2/P3 todo files + updates index.md
+     ↓
+Fix P1 first (blocks merge)
+     ↓
+Fix P2 before PR (warning only)
+     ↓
+P3 → backlog (weekly review)
+     ↓
+Mark done → moves to done/ with date prefix
+```
+
+## Todo File Format
+
+Each file follows: `# [P1] Title` → Summary → Priority Justification → Location (file:line) → Suggested Fix → Checklist (fix, test, review, merge).
+
+## Rules
+
+- P1 exists → merge is **blocked**
+- P2 → warning only, recommended to resolve
+- P3 → no blocking, backlog
+- Weekly cleanup: review and archive completed items
+
+## Done Criteria (K4)
+
+- [ ] All P1 items resolved before merge
+- [ ] P2 items reviewed and either resolved or documented
+- [ ] index.md reflects current state
+- [ ] Completed items archived to `done/` directory

package/skills/vibe.review/references/ui-ux-review.md

@@ -0,0 +1,39 @@
+# Phase 2.5 — UI/UX Review Agents
+
+> vibe.review SKILL.md Phase 2.5 에서 **변경 파일에 UI 파일이 있을 때만** 로드한다.
+> UI 변경이 없는 리뷰(백엔드·CLI·설정만 변경)는 이 파일을 읽지 않는다.
+
+### Phase 2.5: UI/UX Review Agents (Auto-triggered)
+
+> **활성화 조건**: 변경된 파일 중 UI 파일 존재 (`.tsx`, `.jsx`, `.vue`, `.svelte`, `.html`, `.css`, `.scss`)
+> **비활성화**: `.vibe/config.json`에 `"uiUxAnalysis": false` 설정
+
+**기존 Phase 2 리뷰 에이전트와 병렬 실행 — `design-reviewer` 인스턴스 3개 (관점별):**
+
+| Agent (관점) | Role | Output |
+|-------|------|--------|
+| ⑥ design-reviewer (UX 준수) | UX 가이드라인 준수 검증 | P1/P2/P3 findings |
+| ⑦ design-reviewer (접근성) | WCAG 2.1 AA 접근성 감사 | P1/P2/P3 findings |
+| ⑧ design-reviewer (안티패턴) | UI 안티패턴 + 디자인 시스템 일관성 | P1/P2/P3 findings |
+
+**실행 방법 — 기존 Phase 2 에이전트와 병렬 실행:**
+
+Use the harness's native collaboration capability for these independent
+`design-reviewer` workers. Claude Code maps them to Task/Agent; Codex maps them
+to native collaboration. Inherit the session model by default and run them
+concurrently when capacity permits:
+
+- UX compliance: review `{changed_ui_files}` against UX and web-interface guidance.
+- Accessibility: audit `{changed_ui_files}` for WCAG 2.1 AA compliance.
+- Anti-patterns: inspect `{changed_ui_files}` and compare with `.vibe/design-system/{project}/MASTER.md` when present.
+
+#### Visual P1 Baseline
+
+- 프로젝트 루트에 `DESIGN.md` 가 존재하면 **시각 P1 의 1 차 baseline** 으로 사용한다 (§2 Color Palette / §7 Do's & Don'ts).
+- `DESIGN.md` 부재 시 기존 폴백을 사용 (WCAG 2.1 AA + `MASTER.md` + design-review(audit 모드) 기본 5 차원).
+- v1 범위: hex 컬러 드리프트만 P1 후보. spacing / font 드리프트는 Phase 2+ 에서 추가.
+- 안티패턴 검출(⑧) 은 `DESIGN.md §7` 의 "DON'T" 항목을 우선 규칙으로 사용한다.
+
+**findings 통합**: ⑥⑦⑧ findings를 기존 findings[]와 병합 → P1/P2/P3 통합 정렬
+
+**⑦ Critical finding 에스컬레이션**: design-reviewer(접근성)의 P1 finding은 Review Debate(Phase 4.5)에 자동 포함