@su-record/vibe 3.2.64 → 4.0.1

package/skills/vibe.review/SKILL.md

@@ -1,321 +0,0 @@
----
-name: vibe.review
-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
----
-
-# /vibe.review
-
-**Parallel Agent Code Review** — focus 별 전문 리뷰어를 **가능한 범위에서 병렬로, 나머지는 순차로** 실행 (production 기본 셋 8종 + 조건부)
-
-## Usage
-
-```
-/vibe.review                         # Review current branch
-/vibe.review PR#123                  # Review specific PR
-/vibe.review feature/login           # Review specific branch
-/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**: Query the system clock at START and record the result as `{start_time}`.
-
-## Codex Plugin Integration
-
-> **Codex 플러그인 감지**: 워크플로우 시작 시 아래 명령으로 자동 감지.
->
-> ```bash
-> CODEX_AVAILABLE=$(node "{{VIBE_PATH}}/hooks/scripts/codex-detect.js" 2>/dev/null || echo "unavailable")
-> ```
->
-> `available`이면 Codex 플러그인의 review/rescue 명령을 사용하고, `unavailable`이면 GPT+Antigravity Race 모드로 동작한다.
->
-> ⚠️ **명령 이름을 가정하지 않는다.** 과거 본문은 `/codex:review`·`/codex:rescue` 를 고정 호출했으나, 이는 특정 플러그인 설치본에만 존재하는 표면이다. 실제 사용 가능한 명령을 확인한 뒤 쓰고, 없으면 Race 모드로 폴백한다 — 존재하지 않는 슬래시 명령을 실행하려 시도하지 않는다.
-
-## Race Mode (v2.6.9)
-
-**Multi-LLM competitive review** - Same review task runs on GPT + Antigravity in parallel, results are cross-validated.
-
-> Read `references/race-mode.md` for the full workflow diagram, confidence-based priority table, race mode options/output templates, Codex 3-way cross-validation, and tool invocation details.
-
-## File Reading Policy (Mandatory)
-
-> 규칙은 **전체 읽기**이지 특정 도구 이름이 아니다. 하네스가 제공하는 파일 읽기 수단을 쓴다 — Claude Code 는 `Read` 도구, Codex 는 셸(`cat`/`sed -n`) 등. 도구 이름이 없다고 규칙을 건너뛰지 않는다.
-
-- **소스코드 파일**: 리뷰 대상 파일은 전체를 읽은 후 리뷰한다 (검색 결과만 훑어보고 판단 금지)
-- **검색 도구 사용 제한**: grep/ripgrep 류는 **파일 위치 탐색**에만 쓴다. 내용 파악과 리뷰는 전체 읽기로 한다
-- **에이전트 실행 시**: 프롬프트에 "대상 파일을 전체 읽은 후 분석하라"를 포함한다
-- **부분 읽기 금지**: Grep 결과의 주변 몇 줄만 보고 판단하지 말 것. 전체 맥락을 파악해야 정확한 리뷰 가능
-
-## Priority System
-
-| Priority | Criteria | Action |
-|----------|----------|--------|
-| P1 | Security vulnerabilities, data loss, crashes | Block merge, fix immediately |
-| P2 | Performance issues, architecture violations, missing tests | Fix before merge |
-| P3 | Style, refactoring suggestions, documentation | Add to backlog |
-
-## Convergence Rules (Over-Diagnosis Prevention)
-
-> **Principle**: Reviews must converge. A review that always finds more issues is broken, not thorough.
-
-### Scope Limiting
-
-- **Review ONLY changed files** — based on `git diff --name-only`. Never scan the entire project
-- **If no git diff** (first review) — review only files in the target path
-
-### Severity Filtering by Round
-
-| Round | What to Report |
-|-------|---------------|
-| 1st review | P1 + P2 + P3 (all) |
-| 2nd review (same code) | P1 + P2 only (skip P3) |
-| 3rd+ review | P1 only (report only new P1s) |
-
-### Stop Conditions
-
-- **P1 = 0 means MERGE READY** — mergeable even with remaining P2/P3
-- **P1 = 0 after auto-fix means DONE** — record P2 auto-fix failures as TODO and stop
-- **P1 = 0 AND final P1 list unchanged after Review Debate → DONE** — converged
-- **P1 > 0 AND final P1 list unchanged → STUCK, not DONE** — 같은 발견이 2회 연속이면
-  루프는 종료하되 **완료로 기록하지 않는다**. `confirm` 이면 사용자에게 묻고, `autonomous`
-  이면 TODO 로 남긴다 (SSOT: `vibe/rules/loop-contract.md` stuck 절). "목록이 안 바뀌었으니
-  수렴했다" 는 남은 P1 을 완료로 포장하는 것이다
-
-### Anti-Patterns (FORBIDDEN)
-
-- "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 → **escalation ladder**: 최초 시도 → 재시도 1회 → (Codex 플러그인 있으면) Codex Rescue 1회 → TODO. 같은 방식으로 계속 재시도하지 않는다
-
-## Process
-
-### Phase 1: Tech Stack Detection
-
-Detect project tech stack FIRST before launching reviewers.
-
-> Read `references/worked-examples.md` for the full file-to-stack detection list (package.json, pyproject.toml, Gemfile, pubspec.yaml, go.mod, CLAUDE.md).
-
-### Phase 1.5: SPEC ↔ Code Alignment Check
-
-> When SPEC files exist, verify that code changes align with the SPEC
-
-```
-1. Search .vibe/specs/ for related SPEC files (based on git diff filenames)
-2. Compare SPEC REQ-* list against functionality in changed code
-3. If functionality added that's not in SPEC → P2 finding: "Feature added without SPEC"
-4. If implementation differs from SPEC → P1 finding: "SPEC ↔ code mismatch"
-5. If no SPEC files exist → Skip (reviews work without SPEC too)
-```
-
-### Phase 2: Parallel Agent Review (STACK-AWARE)
-
-**리뷰어 스케일링 (stakes × 변경 파일 수)** — stakes 정의 SSOT: `vibe/rules/loop-contract.md` Stakes 표. 위임(서브에이전트)마다 컨텍스트 재주입 비용이 발생하므로, 리뷰어 수는 태스크 무게에 비례시킨다:
-
-| stakes | 변경 파일 | 리뷰어 셋 |
-|---|---|---|
-| demo | ≤5 | correctness + security **2종만** |
-| demo / prototype | >5 또는 prototype | correctness + security + data-integrity **3종** |
-| production | 무관 | 아래 Core Reviewers 전체 (기존 기본 동작 — 불변) |
-
-**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.
-
-**스폰 직전 비용 게이트** (SSOT: `vibe/rules/loop-contract.md` 비용 게이트 절). 위 표대로 정한 리뷰어 수를 그대로 넣는다:
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/dispatch/index.js').then(t => { const op={kind:'agent-fanout',agentCount:{N},label:'리뷰어 {N}종 병렬'}; console.log(t.formatCostGate(op, t.evaluateCostGate(op))); })"
-```
-
-기본 임계값(12)에서 demo 2종·prototype 3종·production 8종은 전부 **통과**한다 — 평상시 규모는 멈추지 않는다. `ask` 가 나오면 스폰 전에 사용자에게 확인하고, `record` (autonomous) 면 묻지 않고 인박스에 남긴 뒤 진행한다.
-
-호출 계약(하네스 무관): "에이전트 `{agent}` 를 인자 `Review {FILES} — focus: {focus}` 로 실행한다"
-
-```
-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 (production stakes 의 기본 셋 — `code-reviewer` 를 focus 별로 하나씩 + `security-reviewer`):**
-
-> demo/prototype 에서는 위 리뷰어 스케일링 표의 축소 셋만 실행한다. 이 표는 **production 의 전체 셋**이며 "무조건 8개 전부"라는 뜻이 아니다 — stakes 판정이 셋 크기를 결정한다 (SSOT: `vibe/rules/loop-contract.md` Stakes 표).
-| Agent (focus) | Focus |
-|-------|-------|
-| security-reviewer | OWASP Top 10, vulnerabilities |
-| code-reviewer (focus: correctness) | Logic errors, edge cases |
-| code-reviewer (focus: data-integrity) | Data validation, constraints |
-| code-reviewer (focus: performance) | N+1 queries, memory leaks |
-| code-reviewer (focus: architecture) | Layer violations, cycles |
-| code-reviewer (focus: complexity) | Cyclomatic complexity, length, over-abstraction, dead code |
-| code-reviewer (focus: git-history) | Churn files, risk patterns |
-| code-reviewer (focus: test-coverage) | Missing tests, edge cases |
-
-**Stack-Specific Review (Conditional — one extra `code-reviewer` instance):**
-| Agent (focus) | Condition |
-|-------|-----------|
-| 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 (조건부)
-
-> **활성화 조건**: 변경된 파일 중 UI 파일 존재 (`.tsx`, `.jsx`, `.vue`, `.svelte`, `.html`, `.css`, `.scss`)
-> **비활성화**: `.vibe/config.json` 에 `"uiUxAnalysis": false`
-
-조건에 걸리면 `references/ui-ux-review.md` 를 읽어 `design-reviewer` 3개 관점을 Phase 2 와 병렬 실행한다.
-UI 파일이 없으면 이 Phase 전체를 건너뛴다 — reference 도 읽지 않는다.
-
-### Phase 2.7: Boundary Mismatch Detection (Integration Coherence)
-
-> **활성화 조건**: 변경된 파일 중 API route + 프론트엔드 훅/컴포넌트가 함께 존재
-> 경계면 불일치는 개별 파일 리뷰로는 발견 불가 — **양쪽을 동시에 읽어야** 잡힘
-
-**검증 방법: "양쪽 동시 읽기"**
-
-생산자와 소비자 코드를 **같은 판단 안에서 함께** 읽어 교차 비교한다 (한쪽만 읽고 판단 금지). 두 파일을 동시에 열 도구가 없어도 규칙은 유효하다 — 순서대로 전체를 읽은 뒤 비교하면 된다.
-
-> Read `references/boundary-check.md` for the full verification-area table and checklist.
-
-**실행 방식 — 변경 파일 기반 자동 판별:**
-
-```text
-1. git diff에서 API route 파일과 대응 프론트 파일을 짝으로 매칭
-2. 짝이 있는 경우 → 아래 4개 검증 실행
-3. 짝이 없는 경우 (API만 또는 프론트만 변경) → "대응 파일 미변경" 경고 후 스킵
-```
-
-**Findings 분류:**
-- 경계면 불일치 → **P1** (런타임 에러의 주요 원인)
-- 대응 파일 미존재 (API 있으나 훅 없음) → **P2**
-- case 변환 비일관성 → **P2**
-
-### Phase 3: Deep Analysis
-
-After agent results:
-
-1. **System Context**: Component interactions, data flow, external dependencies
-2. **Stakeholder Perspectives**: Developers, Ops, Security, Business
-3. **Edge Cases**: Race conditions, resource exhaustion, network failures
-4. **Multiple Angles**: Technical excellence, business value, risk management
-
-### Phase 4: Findings Synthesis
-
-> Read `references/output-template.md` for the full findings synthesis format.
-
-### Phase 4.5: Review Debate (parallel native subagents)
-
-> P1/P2 findings 를 검증하기 위해 네이티브 서브에이전트를 병렬로 스폰한다 —
-> `security-reviewer` + `code-reviewer` 인스턴스(서로 다른 focus)가 각 finding 을 교차 검증(validate / upgrade / downgrade / remove)한다.
->
-> **검증자에게 실행자의 컨텍스트를 넘기지 않는다.** 새 서브에이전트로 스폰하는 것 자체가
-> 이 규정이다 — finding 과 대상 파일만 주고, 리뷰 과정의 대화는 주지 않는다.
-> 같은 컨텍스트를 물려받은 검증자는 검증하지 않고 **자기 자신에게 동의한다**.
-> 그러면 교차 검증은 이름만 남고 단일 리뷰와 같아진다 — 더 비싸고, 통과 신호만 늘어난 채로.
-
-> Read `references/worked-examples.md` for the full Review Debate example output.
-
-### Phase 5: Auto-Fix (P1/P2)
-
-**Auto-fixable issues are resolved immediately:**
-
-> Read `references/worked-examples.md` for the full Auto-Fix example output.
-
-**Cases that cannot be auto-fixed:**
-- Requires large-scale architecture changes
-- Requires business logic decisions
-- Requires user confirmation
-
-→ Manual handling instructions in Phase 6
-
-### Auto-Fix 실패 시 Codex Rescue (Codex 플러그인 활성화 시)
-
-P1/P2 auto-fix 가 **재시도 1회까지 실패**하면(= 시도 2회), TODO 로 내리기 전에 Codex 에 **1회** 위임한다 — escalation ladder SSOT: 위 Anti-Patterns.
-
-위임 요청 내용(호출 표면 무관):
-
-```
-Fix {priority} issue: {issue-description}. File: {file-path}
-```
-
-이 요청을 Codex 플러그인이 **실제로 제공하는** rescue/review 명령으로 전달한다. 제공 명령을 확인할 수 없으면 위임을 건너뛰고 바로 TODO 로 내린다 — 존재하지 않는 슬래시 명령을 실행하려 시도하지 않는다 (위 "명령 이름을 가정하지 않는다").
-
-Codex 수정 완료 후 해당 리뷰 에이전트가 재검증.
-
-### Phase 6: Todo File Creation (Items Requiring Manual Handling)
-
-Save **remaining** findings to `.vibe/todos/`:
-
-> Read `references/worked-examples.md` for the Todo file naming example.
-
-## Output
-
-> Read `references/output-template.md` for the full review summary output format.
-
-### Phase 7: Guide to Fix Workflow (Manual Handling Items)
-
-**Choose workflow when handling remaining issues:**
-
-> 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 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)
-
-### Tool Invocation
-
-All tools are called via:
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => t.TOOL_NAME({...args}).then(r => console.log(r.content[0].text)))"
-```
-
-### Recommended Tools for Review
-
-| Tool | Purpose | When to Use |
-|------|---------|-------------|
-| `validateCodeQuality` | Code quality check | Overall code quality scan |
-| `analyzeComplexity` | Complexity metrics | Check function complexity |
-| `saveMemory` | Save findings | Store important review findings |
-
-> Read `references/worked-examples.md` for example tool usage in review (validateCodeQuality, analyzeComplexity, saveMemory).
-
----
-
-## Quality Gate (Mandatory)
-
-Before completing review, check P1-critical items (P2/P3 are best-effort). Score = 100 - (P1 × 20) - (P2 × 5) - (P3 × 1). **P1 = 0 required for MERGE READY.**
-
-> 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.
-
----
-
-## 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/boundary-check.md

@@ -1,25 +0,0 @@
-# Boundary Mismatch Detection — Full Reference
-
-> Loaded by vibe.review SKILL.md Phase 2.7 for the full verification-area table and checklist.
-
-**검증 방법: "양쪽 동시 읽기"**
-
-반드시 **생산자와 소비자 코드를 동시에** Read하여 교차 비교한다.
-
-| 검증 영역 | 생산자 (왼쪽) | 소비자 (오른쪽) | 검증 내용 |
-|----------|-------------|---------------|----------|
-| API ↔ 훅 타입 | route의 Response.json() shape | hooks의 fetch\<T\> 타입 | shape 일치, 래핑 unwrap, case 변환 |
-| 라우팅 정합성 | src/app/ page 파일 경로 | href, router.push 값 | 경로 매칭, route group 처리, 동적 세그먼트 |
-| 상태 전이 | STATE_TRANSITIONS 맵 | .update({ status }) 코드 | 죽은 전이, 무단 전이, 중간→최종 누락 |
-| 데이터 흐름 | DB 스키마 필드명 | API 응답 → 프론트 타입 | 필드명 일치, optional 처리 일관성 |
-
-**검증 체크리스트:**
-
-- [ ] API 응답 shape과 대응 훅의 제네릭 타입이 일치
-- [ ] 래핑된 응답(`{ items: [...] }`)은 훅에서 unwrap하는지 확인
-- [ ] snake_case ↔ camelCase 변환이 일관되게 적용
-- [ ] 모든 API 엔드포인트에 대응하는 프론트 훅이 존재하고 실제 호출됨
-- [ ] 코드 내 모든 href/router.push 값이 실제 page 파일 경로와 매칭
-- [ ] 정의된 모든 상태 전이가 코드에서 실행됨 (죽은 전이 없음)
-- [ ] 프론트에서 상태 기반 분기의 값이 실제 도달 가능한 상태
-- [ ] DB 필드명 → API 응답 필드명 → 프론트 타입 정의 간 매핑 일관

package/skills/vibe.review/references/output-template.md

@@ -1,74 +0,0 @@
-# Review Output Template — Full Reference
-
-> Loaded by vibe.review SKILL.md for the Phase 4 findings synthesis format and the final review summary format (Phase 6 Output).
-
-## Phase 4: Findings Synthesis
-
-```
-REVIEW FINDINGS
-
-P1 CRITICAL (Blocks Merge) - N issues
-1. [SECURITY] SQL Injection in user query
-   Location: src/api/users.py:42
-   Fix: Use parameterized queries
-
-P2 IMPORTANT (Should Fix) - N issues
-2. [PERF] N+1 query in user list
-3. [ARCH] Circular dependency detected
-
-P3 NICE-TO-HAVE (Enhancement) - N issues
-4. [STYLE] Consider extracting helper function
-```
-
-## Output
-
-```
-CODE REVIEW SUMMARY
-PR #123: Add user authentication
-
-Reviewers: security-reviewer + 8 code-reviewer instances (per-focus) + 3 design-reviewer instances (UI)
-⏱️ Started: {start_time}
-⏱️ Completed: {getCurrentTime 결과}
-
-Score: 92/100 (Good) ← Score after auto-fix
-
-Issues Found:
-- P1 Critical: 2 → 0 (✅ Auto-fixed)
-- P2 Important: 5 → 1 (✅ 4 auto-fixed)
-- P3 Nice-to-have: 3 (Backlog)
-
-Auto-Fixed: 6 issues
-- [SECURITY] SQL Injection ✅
-- [DATA] Transaction rollback ✅
-- [PERF] N+1 query ✅
-- [ARCH] Circular dependency ✅
-- [PERF] Unnecessary loop ✅
-- [TEST] Missing edge case ✅
-
-Remaining (Manual handling required):
-- P2-arch-large-refactor.md (Architecture decision required)
-- P3-style-extract-helper.md (Backlog)
-- P3-docs-add-readme.md (Backlog)
-
-✅ MERGE READY (P1/P2 resolved)
-```
-
-## Phase 7: Guide to Fix Workflow (Manual Handling Items) — Prompt Template
-
-**Choose workflow when handling remaining issues:**
-
-```
-## Fix Workflow
-
-Choose a workflow to fix the discovered issues:
-
-| Task Scale | Recommended Approach |
-|------------|---------------------|
-| Simple fix (1-2 files) | Plan Mode |
-| Complex fix (3+ files, validation needed) | /vibe.spec |
-
-1. `/vibe.spec "fix: issue-name"` - VIBE workflow (SPEC validation + re-review)
-2. Plan Mode - Quick fix (for simple tasks)
-
-Which approach would you like to proceed with?
-```

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

@@ -1,66 +0,0 @@
----
-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/quality-gate.md

@@ -1,84 +0,0 @@
-# Review Quality Gate — Full Reference
-
-> Loaded by vibe.review SKILL.md for the mandatory quality-gate checklist, score calculation, merge decision matrix, auto-fix capability matrix, and forbidden-patterns table.
-
-### Review Quality Checklist
-
-Before completing review, check P1-critical items. P2/P3 items are best-effort:
-
-| Category | Check Item | Weight |
-|----------|------------|--------|
-| **Security** | OWASP Top 10 vulnerabilities scanned | 20% |
-| **Security** | Authentication/authorization verified | 10% |
-| **Security** | Sensitive data exposure checked | 10% |
-| **Performance** | N+1 queries detected and flagged | 10% |
-| **Performance** | Memory leaks checked | 5% |
-| **Architecture** | Layer violations detected | 10% |
-| **Architecture** | Circular dependencies checked | 5% |
-| **Code Quality** | Complexity limits enforced | 10% |
-| **Code Quality** | Forbidden patterns detected | 10% |
-| **Testing** | Test coverage gaps identified | 5% |
-| **Documentation** | Public API documentation checked | 5% |
-
-### Review Score Calculation
-
-```
-Score = 100 - (P1 × 20) - (P2 × 5) - (P3 × 1)
-
-Grades:
-- 95-100: ✅ EXCELLENT - Merge ready
-- 90-94:  ⚠️ GOOD - Minor fixes required before merge
-- 80-89:  ⚠️ FAIR - Must fix P2 issues
-- 0-79:   ❌ POOR - Block merge, fix P1/P2
-```
-
-### Merge Decision Matrix
-
-| P1 Count | P2 Count | Decision |
-|----------|----------|----------|
-| 0 | 0-2 | ✅ MERGE READY |
-| 0 | 3+ | ⚠️ FIX P2 FIRST |
-| 1+ | Any | ❌ BLOCKED |
-
-### Auto-Fix Capability Matrix
-
-| Issue Type | Auto-Fixable | Method |
-|------------|--------------|--------|
-| SQL Injection | ✅ Yes | Parameterized query |
-| Missing transaction | ✅ Yes | Add try-finally |
-| N+1 query | ✅ Yes | Add eager loading |
-| Circular dependency | ⚠️ Partial | Suggest restructure |
-| Missing tests | ✅ Yes | Generate test skeleton |
-| Hardcoded secrets | ❌ No | Flag for manual review |
-| Architecture violation | ❌ No | Suggest refactoring plan |
-
-### Forbidden Patterns (P1 Critical)
-
-| Pattern | Risk Level | Detection Method |
-|---------|------------|------------------|
-| Hardcoded credentials | Critical | Regex + entropy scan |
-| SQL string concatenation | Critical | AST analysis |
-| `eval()` or `exec()` | Critical | AST analysis |
-| Disabled CSRF protection | Critical | Config scan |
-| Debug mode in production | Critical | Config scan |
-| Unvalidated redirects | High | URL pattern scan |
-
-### Review Output Requirements
-
-Every review MUST produce:
-
-1. **Summary Statistics**
-   - Total issues by priority (P1/P2/P3)
-   - Auto-fixed count
-   - Remaining manual fixes
-
-2. **Detailed Findings**
-   - File path and line number
-   - Issue description
-   - Recommended fix
-   - Auto-fix status (applied/pending/manual)
-
-3. **Quality Score**
-   - Numerical score (0-100)
-   - Grade (EXCELLENT/GOOD/FAIR/POOR)
-   - Merge recommendation

package/skills/vibe.review/references/race-mode.md

@@ -1,117 +0,0 @@
-# Race Mode — Full Reference
-
-> Loaded by vibe.review SKILL.md when Race Mode (`--race`, Multi-LLM competitive review) is invoked.
-
-### How It Works
-
-```
-/vibe.review --race
-
-security-review:
-├─ GPT Codex  → [SQL injection, XSS]
-└─ Antigravity     → [SQL injection, CSRF]
-         ↓
-   Cross-validation:
-   - SQL injection (2/2) → 🔴 P1 (100% confidence)
-   - XSS (1/2) → 🟡 P2 (50% confidence)
-   - CSRF (1/2) → 🟡 P2 (50% confidence)
-```
-
-### Confidence-Based Priority
-
-| Confidence | Priority | Meaning |
-|------------|----------|---------|
-| 100% (2/2) | P1 | Both models agree - high confidence |
-| 50% (1/2) | P2 | One model found - needs verification |
-
-### Race Mode Options
-
-```
-/vibe.review --race                  # All review types
-/vibe.review --race security         # Security only
-/vibe.review --race performance      # Performance only
-/vibe.review --race architecture     # Architecture only
-```
-
-### Race Mode Output
-
-```
-## SECURITY Review (Race Mode)
-
-**Duration**: 3420ms
-**Models**: GPT Codex, Antigravity
-
-### Model Results
-
-| Model | Issues Found | Duration | Status |
-|-------|--------------|----------|--------|
-| gpt | 3 | 1823ms | OK |
-| antigravity | 2 | 2156ms | OK |
-
-### Cross-Validated Issues
-
-**Summary**: 3 issues (P1: 1, P2: 2)
-**Consensus Rate**: 67%
-
-#### 🔴 P1 - SQL Injection in user query
-
-- **Confidence**: 100% (gpt, antigravity)
-- **Severity**: critical
-- **Location**: `src/api/users.ts:42`
-- **Suggestion**: Use parameterized queries
-
-#### 🟡 P2 - XSS vulnerability in render
-
-- **Confidence**: 50% (gpt)
-- **Severity**: high
-- **Location**: `src/components/Comment.tsx:15`
-```
-
-### Codex Review (Codex 플러그인 활성화 시)
-
-Race Mode에서 GPT+Antigravity와 **동시에** Codex review 실행하여 3중 교차 검증:
-
-```
-/codex:review
-```
-
-교차 검증 테이블:
-
-```markdown
-| Issue | GPT | Antigravity | Codex | Confidence |
-|-------|-----|--------|-------|------------|
-| {이슈} | ✅/❌ | ✅/❌ | ✅/❌ | {%} |
-```
-
-- 3개 모델 중 2개 이상 동의 → **High Confidence** (P1 자동 수정)
-- Codex만 발견 → **Medium Confidence** (P2 수동 검토)
-
-### When to Use Race Mode
-
-| Scenario | Recommended |
-|----------|-------------|
-| Critical security review | ✅ `--race security` |
-| Pre-production audit | ✅ `--race` |
-| Quick iteration | ❌ Standard review |
-| API cost concerns | ❌ Standard review |
-
-### Tool Invocation (Race Mode - GPT + Antigravity in parallel via Bash)
-
-**🚨 Use --input file to avoid CLI argument length limits and Windows pipe issues.**
-
-1. Save code to review into `[SCRATCHPAD]/review-code.txt` (using Write tool)
-2. Write JSON input file `[SCRATCHPAD]/review-input.json` (using Write tool):
-   - `{"prompt": "Review this code for [REVIEW_TYPE]. Return JSON: {issues: [{id, title, description, severity, suggestion}]}. Code: [CODE_CONTENT]"}`
-   - Where `[CODE_CONTENT]` is the code text (properly JSON-escaped inside the prompt string)
-3. Script path: `[LLM_SCRIPT]` = `{{VIBE_PATH}}/hooks/scripts/llm-orchestrate.js`
-4. Run GPT + Antigravity in PARALLEL (two Bash tool calls at once):
-
-```bash
-# GPT review (Bash tool call 1)
-node "[LLM_SCRIPT]" gpt orchestrate-json --input "[SCRATCHPAD]/review-input.json"
-```
-
-```bash
-# Antigravity review (Bash tool call 2 - run in parallel)
-node "[LLM_SCRIPT]" antigravity orchestrate-json --input "[SCRATCHPAD]/review-input.json"
-```