@su-record/vibe 3.2.6 → 3.2.8

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
 
@@ -30,7 +31,9 @@ user-invocable: true
 > CODEX_AVAILABLE=$(node "{{VIBE_PATH}}/hooks/scripts/codex-detect.js" 2>/dev/null || echo "unavailable")
 > ```
 >
-> `available`이면 `/codex:review`, `/codex:rescue` 자동 호출. `unavailable`이면 기존 GPT+Antigravity Race 모드로 동작.
+> `available`이면 Codex 플러그인의 review/rescue 명령을 사용하고, `unavailable`이면 GPT+Antigravity Race 모드로 동작한다.
+>
+> ⚠️ **명령 이름을 가정하지 않는다.** 과거 본문은 `/codex:review`·`/codex:rescue` 를 고정 호출했으나, 이는 특정 플러그인 설치본에만 존재하는 표면이다. 실제 사용 가능한 명령을 확인한 뒤 쓰고, 없으면 Race 모드로 폴백한다 — 존재하지 않는 슬래시 명령을 실행하려 시도하지 않는다.
 
 ## Race Mode (v2.6.9)
 
@@ -40,9 +43,11 @@ user-invocable: true
 
 ## File Reading Policy (Mandatory)
 
-- **소스코드 파일**: 리뷰 대상 파일은 반드시 `Read` 도구로 전체 파일을 읽은 후 리뷰할 것 (Grep으로 훑어보기 금지)
-- **Grep 사용 제한**: 파일 위치 탐색(어떤 파일에 있는지 찾기)에만 사용. 파일 내용 파악 및 리뷰에는 반드시 Read 사용
-- **에이전트 spawn 시**: 프롬프트에 "대상 파일을 Read 도구로 전체 읽은 후 분석하라"를 반드시 포함할 것
+> 규칙은 **전체 읽기**이지 특정 도구 이름이 아니다. 하네스가 제공하는 파일 읽기 수단을 쓴다 — Claude Code 는 `Read` 도구, Codex 는 셸(`cat`/`sed -n`) 등. 도구 이름이 없다고 규칙을 건너뛰지 않는다.
+
+- **소스코드 파일**: 리뷰 대상 파일은 전체를 읽은 후 리뷰한다 (검색 결과만 훑어보고 판단 금지)
+- **검색 도구 사용 제한**: grep/ripgrep 류는 **파일 위치 탐색**에만 쓴다. 내용 파악과 리뷰는 전체 읽기로 한다
+- **에이전트 실행 시**: 프롬프트에 "대상 파일을 전체 읽은 후 분석하라"를 포함한다
 - **부분 읽기 금지**: Grep 결과의 주변 몇 줄만 보고 판단하지 말 것. 전체 맥락을 파악해야 정확한 리뷰 가능
 
 ## Priority System
@@ -81,7 +86,7 @@ user-invocable: true
 - "All items must be verified" → Only P1 is mandatory, P2/P3 are best-effort
 - "Found one more issue" (repeated) → Only report P1s not mentioned in previous review
 - Forcing code changes for P3 issues → P3 goes to TODO files only, never force code changes
-- Infinite retries on auto-fix failure → max 1 retry then move to TODO
+- Infinite retries on auto-fix failure → **escalation ladder**: 최초 시도 → 재시도 1회 → (Codex 플러그인 있으면) Codex Rescue 1회 → TODO. 같은 방식으로 계속 재시도하지 않는다
 
 ## Process
 
@@ -113,16 +118,25 @@ Detect project tech stack FIRST before launching reviewers.
 | demo / prototype | >5 또는 prototype | correctness + security + data-integrity **3종** |
 | production | 무관 | 아래 Core Reviewers 전체 (기존 기본 동작 — 불변) |
 
-**Spawn the reviewers as concurrent native subagents in ONE message** — one `code-reviewer` instance per focus plus `security-reviewer`, each scoped to the changed files:
+**Spawn one reviewer per focus, as concurrently as the harness allows** — a `code-reviewer` instance per focus plus `security-reviewer`, each scoped to the changed files.
+
+호출 계약(하네스 무관): "에이전트 `{agent}` 를 인자 `Review {FILES} — focus: {focus}` 로 실행한다"
 
 ```
-Task (code-reviewer): "Review [FILES] — focus: correctness"      (concurrent)
-Task (code-reviewer): "Review [FILES] — focus: data-integrity"   (concurrent)
-Task (code-reviewer): "Review [FILES] — focus: performance"      (concurrent)
-Task (code-reviewer): "Review [FILES] — focus: architecture"     (concurrent)
-Task (security-reviewer): "Review [FILES] for vulnerabilities"   (concurrent)
+run agent code-reviewer      args: "Review {FILES} — focus: correctness"
+run agent code-reviewer      args: "Review {FILES} — focus: data-integrity"
+run agent code-reviewer      args: "Review {FILES} — focus: performance"
+run agent code-reviewer      args: "Review {FILES} — focus: architecture"
+run agent security-reviewer  args: "Review {FILES} for vulnerabilities"
 ```
 
+| 하네스 | 실행 방식 |
+|---|---|
+| Claude Code | 네이티브 서브에이전트를 **한 메시지에 모두** 스폰 (동시 실행) |
+| Codex | 동시 슬롯 한도 내에서 스폰하고, 남는 focus 는 **순차 실행**한다 |
+
+> **동시 슬롯이 focus 수보다 적으면 focus 를 버리지 말고 순차로 돌린다.** 커버리지가 동시성보다 우선이다 — 리뷰 축을 조용히 빠뜨리면 P1 을 놓친다. 스킵한 focus 가 있으면 최종 보고에 명시한다.
+
 Stack-specific focus (`idioms`) is added when the diff touches that stack's files. Collect all results, then dedupe/merge findings before Phase 3.
 
 **Core Reviewers (Always Run — parallel `code-reviewer` instances, one per focus, plus `security-reviewer`):**
@@ -142,45 +156,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` 설정
-
-**기존 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
+> **비활성화**: `.vibe/config.json` 에 `"uiUxAnalysis": false`
 
-- 프로젝트 루트에 `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)
 
@@ -241,7 +223,7 @@ After agent results:
 
 ### Auto-Fix 실패 시 Codex Rescue (Codex 플러그인 활성화 시)
 
-P1/P2 auto-fix **3회 실패** 시, Codex에 위임:
+P1/P2 auto-fix 가 **재시도 1회까지 실패**하면(= 시도 2회), TODO 로 내리기 전에 Codex 에 **1회** 위임한다 — escalation ladder SSOT: 위 Anti-Patterns:
 
 ```
 /codex:rescue "Fix {priority} issue: {issue-description}. File: {file-path}"
@@ -266,8 +248,8 @@ Save **remaining** findings to `.vibe/todos/`:
 > Read `references/output-template.md` for the full Fix Workflow prompt template.
 
 - Wait for user's choice before proceeding
-- If user chooses VIBE → wait for `/vibe.spec` command
-- If user chooses Plan Mode → proceed with EnterPlanMode
+- If user chooses VIBE → wait for the user to invoke the `vibe.spec` skill
+- If user chooses Plan Mode → enter the harness's plan/read-only mode if it has one (Claude Code: plan mode). **하네스에 등가 모드가 없으면**(Codex 등) 모드 전환 대신 "계획만 제시하고 사용자 승인 전까지 파일을 수정하지 않는다"를 그대로 지킨다 — 없는 모드를 호출하려 시도하지 않는다.
 
 ## Core Tools (Code Analysis)
 
@@ -297,6 +279,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)에 자동 포함