@su-record/vibe 3.2.6 → 3.2.7

package/skills/vibe.clone/references/verification-loops.md

@@ -0,0 +1,64 @@
+# Clone — Phase 4 Compile Gate & Phase 5 Pixel Verification
+
+> Loaded by vibe.clone SKILL.md Phases 4–5. Both loops follow `vibe/rules/loop-contract.md`
+> (ANCHOR→ACT→JUDGE→RECORD); exit = gates pass │ stuck │ max-iter.
+
+## Phase 4: Compile Gate
+
+```
+No round cap. Loop until compile succeeds (or stuck → ask user).
+
+0. Capture baseline (before Phase 3): record existing tsc + build errors
+   → Phase 4 only fixes NEW errors
+
+1. TypeScript: vue-tsc / svelte-check / tsc --noEmit
+2. Build: npm run build (120s timeout)
+3. Dev server: npm run dev → detect port → polling
+
+On error: parse → auto-fix → re-check
+Termination:
+  ✅ Success: all checks pass → enter Phase 5
+  ⚠️ Stuck: same errors as previous round → ask user
+     1. Direct fix instructions → retry
+     2. "proceed" — record remaining errors as TODO, proceed to Phase 5
+     3. "abort" — halt
+  automationLevel: autonomous → on stuck, record TODO without prompting and proceed
+
+⛔ Must enter Phase 5 after Phase 4 passes. Do NOT output a "completion summary".
+```
+
+## Phase 5: Pixel Verification Loop — MANDATORY
+
+**⛔ Phase 5 is mandatory, not optional. Enter automatically after Phase 4.**
+**⛔ Skipping Phase 5 makes the entire clone "incomplete".**
+
+```
+No round cap. Loop until P1=0 (or stuck → ask user).
+Infrastructure: src/infra/lib/browser/ (Puppeteer + CDP) — same as figma Phase 6.
+
+1. Render scaffolded page in dev server at matching viewport
+2. Capture screenshot → pixelmatch comparison against /tmp/{feature}/{bp}/screenshot.png
+   diffRatio > 0.05 (clone target is tighter than figma) → P1
+3. CSS comparison: live computed CSS vs /tmp/{feature}/{bp}/computed.json
+   delta > 2px → P1, ≤ 2px → P2
+4. Asset audit: every <img>/background-image resolves to local public/images/ path → else P1
+5. Fix P1 first (refer to computed.json, no guessing) → revalidate compile → reload
+
+Narrowing scope:
+  Round 1: P1+P2+P3
+  Round 2: P1+P2
+  Round 3+: P1 only
+
+Termination:
+  ✅ P1=0 AND no new findings → complete
+  ⚠️ Stuck: same findings → ask user (resolve / proceed / abort)
+  automationLevel: autonomous → on stuck, record TODO without prompting and complete
+
+Responsive: after MO verification → change viewport → repeat against PC screenshot
+Post-merge (Phase 3C): re-run at BOTH viewports (375×812 vs mo/screenshot.png,
+  1440×900 vs pc/screenshot.png) — either failing means the merge regressed; fix the
+  merged SCSS (evidence: the per-BP sections.json), never by re-guessing values
+Cleanup: shut down browser + dev server
+
+⛔ "Completion summary" output only allowed after Phase 5 completes.
+```

package/skills/vibe.commit-push-pr/SKILL.md

@@ -2,7 +2,7 @@
 name: vibe.commit-push-pr
 invocation: [auto]
 tier: optional
-description: "Commit, push, and create PR in one go. Auto-activates on commit, PR, push keywords."
+description: "Use when the user asks to commit completed changes, push the branch, and open a pull request in one workflow."
 triggers: [commit, push, PR, pull request, merge]
 priority: 70
 ---
@@ -49,9 +49,15 @@ git diff --cached --name-only | grep -E '\.(env|pem|key)$|credentials|secret'
 
 ## Branch Protection
 
-- **No direct commits/pushes to main/master**
-- If on main: create a new branch first
-- **Never** `--force` push to main/master
+**보호 브랜치 규칙 (항상 적용 — 조건부 로드 금지):**
+
+- **`main`/`master` 에 직접 커밋·푸시하지 않는다.**
+- 현재 브랜치가 `main`/`master` 면 **먼저 새 브랜치를 만든다.**
+- `main`/`master` 에 **force-push 는 절대 하지 않는다.**
+
+> 이 규칙은 reference 로 내리지 않는다. "브랜치가 보호돼 있을 때만 읽어라" 는 순환이다 —
+> 무엇이 보호 브랜치인지 판단하려면 이미 이 규칙을 알고 있어야 한다.
+> 안전·정확성 규칙은 조건부 로드 대상이 아니다.
 
 ## PR Format
 

package/skills/vibe.context7-usage/SKILL.md

@@ -1,107 +1,11 @@
 ---
 name: vibe.context7-usage
+description: Compatibility alias for Context7-based current library documentation lookup. Use when callers invoke vibe.context7-usage directly.
 invocation: [auto]
 tier: optional
-description: "Context7 plugin for latest library documentation. Auto-activates when docs, documentation, latest version, official docs, API reference, or library help is needed."
 triggers: [latest version, official docs, API reference, library help, context7]
 priority: 60
+user-invocable: true
 ---
 
-# Context7 Usage
-
-Guide for searching latest library/framework documentation using Context7 plugin with subagent isolation.
-
-## Why Subagent Approach?
-
-| Approach | Problem |
-|----------|---------|
-| Direct plugin call | Docs content fills main context, causing bloat |
-| Subagent isolation | Docs queried in separate context, only results returned |
-
-**Benefits:**
-
-- Prevents context bloat during long coding sessions
-- Solves knowledge cutoff problem with latest docs
-- Main context stays focused on implementation
-
-## When to Use
-
-| Situation | Example |
-|-----------|---------|
-| Latest API check | "React 19 use() hook usage" |
-| Version differences | "Next.js 15 changes" |
-| Official docs needed | "Prisma schema syntax" |
-| Migration guide | "Vue 2 → Vue 3 migration" |
-
-## How It Works
-
-```
-User asks library question
-    ↓
-Skill detects docs need
-    ↓
-Spawn docs-researcher subagent (haiku)
-    ↓
-Subagent calls context7 in isolated context
-    ↓
-Returns only relevant info to main context
-```
-
-## Usage
-
-### Automatic (Recommended)
-
-Just ask library/API questions naturally:
-
-```
-"How do I use React 19 use() hook?"
-"What's new in Next.js 15?"
-"Prisma many-to-many relation syntax"
-```
-
-The skill auto-detects and spawns a docs-researcher subagent.
-
-### Manual Command
-
-```
-/context7:docs <library> [query]
-```
-
-Examples:
-
-```
-/context7:docs react hooks
-/context7:docs next.js app router
-/context7:docs prisma relations
-```
-
-## Implementation Pattern
-
-When you detect a library/API documentation need, spawn a subagent:
-
-```
-Task tool call:
-- subagent_type: Explore
-- model: haiku
-- prompt: "Use context7 to find [library] documentation about [topic]. Return only the relevant API usage examples and key points."
-```
-
-The subagent handles the context7 calls and returns a summary, keeping main context clean.
-
-## Fallback Chain
-
-```
-context7 plugin not installed
-    ↓
-Prompt user: /plugin install context7
-    ↓
-If still unavailable: Web Search for official docs
-```
-
-## Installation
-
-If context7 is not installed, guide user:
-
-```bash
-/plugin install context7
-```
+Load `vibe.documentation-provider` and force the Context7 provider while preserving all arguments.

package/skills/vibe.continue/SKILL.md

@@ -1,31 +1,41 @@
 ---
 name: vibe.continue
-description: Restore previous session context for continuity — memory load, context restore, resume from last checkpoint.
-argument-hint: (no arguments)
+description: 세션을 넘기거나 이전 작업을 계속해야 할 때 — reset 전 HANDOFF.md를 만들거나 최신 handoff/checkpoint에서 상태를 복원한다.
+argument-hint: "[handoff]"
 user-invocable: true
 ---
 
 # /vibe.continue
 
+## Done Criteria
+
+- [ ] handoff mode에서는 HANDOFF.md가 지정 경로에 존재한다.
+- [ ] restore mode에서는 복원한 checkpoint 또는 handoff 경로가 보고된다.
+- [ ] 현재 목표, 변경 파일, 검증 상태, 다음 작업이 결과에 포함된다.
+
 Restore previous session context for continuity.
 
 ## Usage
 
 ```
 /vibe.continue
+/vibe.continue handoff
 ```
 
 ## Process
 
-1. Calls `core_start_session` to load project memories
-2. Restores previous conversation context
-3. Resumes work from last checkpoint
+- **Restore mode** (default): locate the newest project checkpoint,
+  `HANDOFF.md`, and `.vibe/memories/` record; read them in full, reconstruct
+  completed work and the next step, verify against `git status`, then resume.
+- **Handoff mode**: read `references/handoff.md`, generate `HANDOFF.md`, read it
+  back, and verify its tasks, decisions, changed files, branch, and test status
+  against repository state.
 
 ## When to Use
 
 - At new session start, to pick up exactly where the previous session left off
-- At 85%+ context usage: `save_memory` → `/new` → `/vibe.continue` (컨텍스트 리셋 후 즉시 복원)
-- Combine with the `handoff` skill for detailed handover: Handoff writes a manual `HANDOFF.md` (work progress + notes + file list) before a session ends; `/vibe.continue` automatically restores memory + session state at the start of the next one.
+- At 85%+ context usage: persist a checkpoint/handoff → start a fresh session using the harness's session reset → `/vibe.continue`
+- Invoke the `vibe.handoff` compatibility name when an existing workflow expects it; it delegates to handoff mode.
 
 ---
 

package/skills/{vibe.handoff → vibe.continue}/agents/context-summarizer.md

@@ -1,7 +1,7 @@
 ---
 name: context-summarizer
 role: Summarizes decisions made during the session and their rationale
-tools: [Read, Bash]
+capabilities: [full-file-reading, shell-command-execution]
 ---
 
 # Context Summarizer

package/skills/{vibe.handoff → vibe.continue}/agents/document-writer.md

@@ -1,7 +1,7 @@
 ---
 name: document-writer
 role: Writes HANDOFF.md from collected state data and session summary
-tools: [Write, Read, Bash]
+capabilities: [file-editing, full-file-reading, shell-command-execution]
 ---
 
 # Document Writer

package/skills/{vibe.handoff → vibe.continue}/agents/state-collector.md

@@ -1,7 +1,7 @@
 ---
 name: state-collector
 role: Gathers current branch, commits, test status, and open TODOs for handoff
-tools: [Bash, Glob, Grep, Read]
+capabilities: [shell-command-execution, file-pattern-search, text-search, full-file-reading]
 ---
 
 # State Collector

package/skills/{vibe.handoff → vibe.continue}/agents/verifier.md

@@ -1,7 +1,7 @@
 ---
 name: verifier
 role: Checks handoff completeness against the HANDOFF.md rubric
-tools: [Read, Bash]
+capabilities: [full-file-reading, shell-command-execution]
 ---
 
 # Verifier

package/skills/{vibe.handoff/rubrics/completeness.md → vibe.continue/references/handoff-completeness.md}

@@ -43,7 +43,7 @@ A HANDOFF.md is complete only when all required items are present and accurate.
 
 - Known issues / workarounds (if any discovered this session)
 - "Do not touch" warnings (if any fragile areas identified)
-- Memory keys saved via `core_save_memory`
+- Optional harness memory references, when the active harness provides durable memory
 
 ## Quality Bar
 

package/skills/{vibe.handoff/templates → vibe.continue/references}/handoff.md

@@ -1,3 +1,38 @@
+# Handoff Workflow and Canonical HANDOFF.md Template
+
+Use this document before a session ends or a long pause when detailed work state must survive context reset. `vibe.continue` restores state; handoff mode first records progress, decisions, changed files, verification status, and the exact next step in `HANDOFF.md`.
+
+## When to Generate
+
+- Context reaches roughly 80–100k tokens.
+- The session has already been compacted three times.
+- Work will pause for an extended period.
+- Complex progress needs a durable record for a teammate or future session.
+
+Automatic continue restores available session state at the start of a new session; HANDOFF.md is the manual, repository-verifiable record created before the old session ends. They complement rather than replace each other.
+
+## Generation Procedure
+
+1. Inspect `git status` and the five most recent commits.
+2. Separate completed, in-progress, and remaining work.
+3. Fill every applicable template field below from conversation and repository evidence.
+4. Write `HANDOFF.md`, then read it back and verify it against repository state.
+5. Durable harness memory may mirror the document, but is optional and never the correctness source.
+
+## Restore Procedure
+
+Run `vibe.continue`, read `HANDOFF.md`, and verify its branch, changed files, and test status before resuming from `Next immediate step`.
+
+## Done Criteria
+
+- [ ] HANDOFF.md exists with all applicable sections filled.
+- [ ] Completed, in-progress, and remaining tasks match repository state.
+- [ ] All modified files and the last commit are recorded.
+- [ ] Session decisions, cautions, blockers, and exact next step are present.
+- [ ] The written document was read back and checked against Git and test evidence.
+
+---
+
 # Work Handover: {{FEATURE_OR_TASK_NAME}}
 
 **Date**: {{DATE}}
@@ -99,9 +134,9 @@ npm run build && npx vitest run
 
 ---
 
-## Session Memory Keys
+## Optional Session Memory References
 
-The following keys were saved with `core_save_memory`:
+When the active harness provides durable memory, record its references here:
 
 - `{{MEMORY_KEY_1}}` — {{MEMORY_KEY_1_DESCRIPTION}}
 - `{{MEMORY_KEY_2}}` — {{MEMORY_KEY_2_DESCRIPTION}}

package/skills/vibe.contract/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vibe.contract
-description: API contract drift detection — extract contracts from SPEC, compare to implementation, fail on drift
+description: Use when a SPEC API contract may differ from implementation or endpoint and schema drift must be detected.
 argument-hint: "extract | check | diff [feature-name]"
 user-invocable: true
 ---
@@ -54,32 +54,9 @@ Execute the bundled implementation below with subcommand: `$ARGUMENTS`
 
 ## Storage Format
 
-```
-.vibe/contracts/
-  <feature>.md           # extracted contract (SSOT)
-  <feature>.snapshot.md  # implementation snapshot at last check (for diff)
-```
-
-### Contract schema (frontmatter)
-
-```yaml
----
-feature: string
-extracted-from: path/to/spec.md
-extracted-at: ISO timestamp
-endpoints:
-  - method: GET | POST | PUT | DELETE | PATCH
-    path: /users/:id
-    request:
-      params: { id: string }
-      body: null
-    response:
-      200: { id: string, email: string, ... }
-      404: { error: string }
-      required: [id, email]
-  - ...
----
-```
+계약 파일의 저장 위치와 frontmatter 스키마는 아래 **Storage Contract** 절이 SSOT다.
+이 문서 안에서 스키마를 두 번 정의하지 않는다 — 과거 이 자리에 있던 축약본은 `id`·`kind`·
+`source-spec-hash` 가 빠진 손실 버전이었다.
 
 ## Integration with /vibe.verify
 

package/skills/vibe.create-prd/SKILL.md

@@ -2,7 +2,7 @@
 name: vibe.create-prd
 invocation: [auto, chain]
 tier: standard
-description: "Create a Product Requirements Document using a comprehensive 8-section template covering problem, objectives, segments, value propositions, solution, and release planning."
+description: "Use when a product idea or research input must become an implementation-ready PRD covering the problem, objectives, segments, value propositions, solution, and release plan."
 triggers: [prd, product requirements, feature spec, requirements document]
 priority: 60
 chain-next: [vibe.user-personas, vibe.prioritization]
@@ -10,6 +10,13 @@ chain-next: [vibe.user-personas, vibe.prioritization]
 
 # Create a Product Requirements Document
 
+## Done Criteria
+
+- [ ] PRD 파일이 요청된 출력 경로에 존재한다.
+- [ ] 8개 필수 섹션이 모두 비어 있지 않다.
+- [ ] 목표마다 측정 가능한 성공 지표가 있다.
+- [ ] release 범위와 제외 범위가 명시되어 있다.
+
 > Based on the PRD template from [Product Compass](https://www.productcompass.pm/p/prd-template) by Pawel Huryn (MIT License).
 
 ## Purpose

package/skills/vibe.design/SKILL.md

@@ -1,12 +1,19 @@
 ---
 name: vibe.design
-description: DESIGN.md(시각 품질 SSOT) 생성·검증·드리프트 검사·동기화. Figma 독립.
+description: UI 작업 전에 시각 품질 SSOT가 필요하거나 DESIGN.md를 생성·검증·동기화할 때 사용한다. Figma와 독립적으로 동작한다.
 argument-hint: "init [--from=interview|code|reference|figma] | lint | verify | sync | preview"
 user-invocable: true
 ---
 
 # /vibe.design
 
+## 완료 기준
+
+- [ ] DESIGN.md가 프로젝트 루트에 존재한다.
+- [ ] 선택한 subcommand의 lint 또는 drift 검사가 통과한다.
+- [ ] 색상·타이포그래피·간격 token에 placeholder가 없다.
+- [ ] `init --from=interview`이면 `.vibe/design-context.json`이 존재한다.
+
 **vibe 의 세 번째 SSOT — 시각 품질 계약 문서(`DESIGN.md`)** 의 라이프사이클을 전담한다.
 
 > `CLAUDE.md`(코드) · `AGENTS.md`(빌드) 에 이은 시각 규약. **Figma 에 종속되지 않는다** — Figma 는 4 가지 입력 소스 중 하나.
@@ -35,7 +42,7 @@ user-invocable: true
 
 ## Process
 
-> **⏱️ Timer**: 시작 시 `getCurrentTime` 호출, `{start_time}` 으로 기록.
+> **⏱️ Timer**: 시작 시 시스템 시각을 조회해 `{start_time}` 으로 기록.
 
 ### Subcommand: `init`
 
@@ -58,9 +65,15 @@ user-invocable: true
 
 #### `--from=interview` 흐름
 
-1. 사용자가 9 섹션을 순차 답변 (브랜드 톤, 컬러, 폰트, 컴포넌트 스타일, 그리드, 그림자/뎁스, 금기, 브레이크포인트, 에이전트 가이드)
-2. 빈 섹션은 템플릿 기본값(주석) 으로 채움
-3. `DESIGN.md` 저장 + `lint` 자동 실행 → P1 없으면 성공
+Read `references/design-context.md` for codebase signal collection, audience,
+brand, aesthetic, constraint questions, `.vibe/design-context.json` schema,
+and update semantics.
+
+1. 기존 코드 신호와 `.vibe/design-context.json`을 먼저 수집한다.
+2. 사용자가 9 섹션을 순차 답변 (브랜드 톤, 컬러, 폰트, 컴포넌트 스타일, 그리드, 그림자/뎁스, 금기, 브레이크포인트, 에이전트 가이드).
+3. design-context의 audience/brand/aesthetic/constraints를 같은 인터뷰에서 수집해 `.vibe/design-context.json`에 저장한다. 기존 파일은 field-level replacement, `createdAt` 보존, `updatedAt` 갱신 규칙을 따른다.
+4. 빈 DESIGN.md 섹션은 템플릿 기본값(주석)으로 채운다.
+5. `DESIGN.md` 저장 + `lint` 자동 실행 → P1 없으면 성공.
 
 #### `--from=code` 흐름
 

package/skills/vibe.design/references/design-context.md

@@ -0,0 +1,184 @@
+---
+name: design-context-reference
+user-invocable: false
+invocation: [auto]
+tier: standard
+description: "Gather and store project design context — target audience, brand personality, aesthetic direction, constraints. Used by other design-* skills. Use when design-teach, design-setup, design-context."
+triggers: [design-teach, design-setup, design-context]
+priority: 50
+---
+
+# Design Teach — Project Design Context Gathering
+
+Collect project-specific design context so all design-* skills produce tailored, brand-aware results. Saves to `.vibe/design-context.json`.
+
+## Usage
+
+```
+/design-teach                  # Interactive context gathering
+/design-teach --update         # Update existing context
+```
+
+## Process
+
+### Step 1: Auto-Explore Codebase
+
+Before asking questions, automatically gather existing signals:
+
+| Signal | Where to Look |
+|--------|---------------|
+| CSS variables / tokens | `*.css`, `tailwind.config.*`, `theme.*` |
+| Color palette | Existing color definitions, brand assets |
+| Typography | Font imports, font-family declarations |
+| Component library | `package.json` dependencies (MUI, Chakra, shadcn, etc.) |
+| Design system | `.vibe/design-system/*/MASTER.md` |
+| Existing context | `.vibe/design-context.json` (if updating) |
+
+### Step 2: Ask Clarifying Questions
+
+Present findings from Step 1, then ask what's missing:
+
+**1. Target Audience**
+- Who are the primary users? (developers, consumers, enterprise, internal)
+- Technical sophistication? (tech-savvy, general public, mixed)
+- Usage context? (desktop office, mobile on-the-go, both)
+
+**2. Brand Personality**
+- How should the product feel? (professional, playful, minimal, bold, warm)
+- Reference products with similar feel? (e.g., "Linear-like", "Notion-like")
+- Any brand guidelines or style guide URL?
+
+**3. Aesthetic Direction**
+- Visual density preference? (spacious, balanced, dense)
+- Color mood? (warm, cool, neutral, vibrant)
+- Typography mood? (modern sans, classic serif, monospace-technical)
+
+**4. Constraints**
+- Accessibility requirements? (WCAG AA, AAA, specific needs)
+- Supported devices? (desktop-only, mobile-first, responsive)
+- Dark mode required?
+- Performance budget? (target LCP, bundle size limits)
+
+### Step 3: Save Context
+
+Persist the gathered context to `.vibe/design-context.json` with the harness's file-editing capability.
+
+**Schema (v1):**
+
+```json
+{
+  "$schema": "design-context-v1",
+  "createdAt": "ISO-8601",
+  "updatedAt": "ISO-8601",
+  "audience": {
+    "primary": "Description of target users",
+    "context": "Usage environment (desktop/mobile/mixed)",
+    "expertise": "Technical level (beginner/intermediate/expert)"
+  },
+  "brand": {
+    "personality": ["3-5 adjectives"],
+    "tone": "formal | casual | playful | professional (guideline, free text allowed)",
+    "existingAssets": "Path to existing brand guidelines (optional)"
+  },
+  "aesthetic": {
+    "style": "minimal | bold | elegant | playful | corporate (guideline, free text allowed)",
+    "colorMood": "warm | cool | neutral | vibrant | muted (guideline, free text allowed)",
+    "typographyMood": "modern | classic | geometric | humanist (guideline, free text allowed)",
+    "references": ["Reference site/app URLs"]
+  },
+  "constraints": {
+    "accessibility": "AA | AAA",
+    "performance": "core-web-vitals | balanced | unlimited",
+    "browsers": ["chrome", "safari", "firefox", "edge"],
+    "devices": ["mobile", "tablet", "desktop"]
+  },
+  "detectedStack": {
+    "framework": "Detected framework",
+    "componentLibrary": "Detected component library",
+    "styling": "Detected styling approach",
+    "fonts": ["Detected fonts"]
+  }
+}
+```
+
+> **Note**: `tone`, `style`, `colorMood`, `typographyMood` values are suggestions, not closed enums. Users can enter free text.
+
+> **Size limit**: design-context.json should not exceed 10KB. The `references` array is capped at 5 items.
+
+### Step 4: Rerun Semantics
+
+When `/design-teach` is run again and `design-context.json` already exists:
+
+1. Read the existing file in full with the harness's file-reading capability
+2. **Show existing values as defaults** for each question ("Current: professional, clean — do you want to change this?")
+3. User replies "keep" or leaves blank → that field is preserved
+4. New value entered → only that field is replaced (**field-level replacement, not merge**)
+5. `createdAt` is always preserved; only `updatedAt` is updated to the current time
+
+### Step 5: Other Skills Reference This Context
+
+Each design-* skill does the following when it runs:
+
+```
+1. Read `.vibe/design-context.json`
+2. File not found → print "Run /design-teach first for better results" → continue with defaults
+3. Parse failure (invalid JSON) → warn "design-context.json parse failed" + continue with defaults → recommend re-running /design-teach
+4. Success → apply context to analysis criteria
+```
+
+## Design Workflow Integration
+
+Design skills are integrated into 3 phases of the vibe workflow:
+
+```
+SPEC Phase:
+  ① Check design-context.json (recommend /design-teach if missing)
+  ② design-system-gen (industry analysis → design system → layout)
+
+REVIEW Phase:
+  ③ /design-review audit (technical quality check)
+  ④ /design-review critique (UX review)
+  ⑤ design-reviewer (AI slop + anti-pattern detection)
+
+PRE-SHIP Phase:
+  ⑥ /design-refine normalize (design system alignment)
+  ⑦ /design-refine polish (final pass)
+```
+
+## How Other Skills Use This
+
+| Skill | Context Usage |
+|-------|---------------|
+| `/design-review audit` | Weight findings by audience constraints (a11y level, devices) |
+| `/design-review critique` | Adjust persona priorities by target audience |
+| `/design-refine polish` | Apply brand-appropriate micro-interactions |
+| `/design-refine normalize` | Use detected token system for replacement mapping |
+| `/design-refine distill` | Preserve brand-expressive elements based on personality |
+
+## Output Format
+
+```markdown
+## Design Context: {project}
+
+### Auto-Detected
+- Framework: Next.js 15
+- Styling: Tailwind CSS + shadcn/ui
+- Fonts: Inter (heading), Inter (body)
+- Tokens: 24 CSS variables found
+
+### User Provided
+- Audience: B2B SaaS, mixed technical level
+- Brand: Professional, clean (like Linear)
+- Density: Balanced
+- A11y: WCAG AA
+- Dark mode: Required
+
+### Saved
+✅ .vibe/design-context.json updated
+```
+
+## Important
+
+- **Non-destructive**: Only creates/updates the context file. No code changes.
+- **Incremental**: Running `--update` preserves existing answers, only asks about gaps.
+- **Foundation**: Run this first before other design-* skills for best results.

package/skills/vibe.design-refine/SKILL.md

@@ -10,6 +10,13 @@ priority: 50
 
 # Design Refine — Distill / Normalize / Polish
 
+## Done Criteria
+
+- [ ] 요청된 distill·normalize·polish pass가 변경 파일에 적용되어 있다.
+- [ ] 새 hardcoded visual value가 추가되지 않았다.
+- [ ] 대상 프로젝트의 lint와 관련 UI 테스트가 통과한다.
+- [ ] 변경된 token 참조가 DESIGN.md와 일치한다.
+
 Modifying design-improvement passes. Mode selected by the first argument; default runs the full pipeline in order: **distill → normalize → polish**.
 
 ## Usage