@su-record/vibe 3.2.62 → 4.0.0

package/skills/vibe.create-prd/frameworks/rice-scoring.md

@@ -1,97 +0,0 @@
----
-name: rice-scoring
-type: framework
-applies-to: [create-prd]
----
-
-# RICE Scoring — Reference Card
-
-## Formula
-
-```
-RICE Score = (Reach × Impact × Confidence) / Effort
-```
-
-## Factor Definitions
-
-### Reach
-How many users affected per time period (e.g., per quarter)?
-
-| Scale | Example |
-|-------|---------|
-| 1,000 | Affects ~1,000 users/quarter |
-| 5,000 | Affects ~5,000 users/quarter |
-| 50,000 | Affects most of the user base |
-
-Use actual user counts when available. Use relative estimates otherwise.
-
-### Impact
-How much does this move the needle for each user?
-
-| Score | Meaning |
-|-------|---------|
-| 3 | Massive — core workflow improvement |
-| 2 | High — significant UX enhancement |
-| 1 | Medium — noticeable improvement |
-| 0.5 | Low — minor convenience |
-| 0.25 | Minimal — rarely noticed |
-
-### Confidence
-How confident are you in the Reach and Impact estimates?
-
-| Score | Meaning |
-|-------|---------|
-| 100% | Data-backed (user research, analytics) |
-| 80% | Some evidence (interviews, comparable features) |
-| 50% | Gut feeling, limited data |
-| 20% | Pure hypothesis, no data |
-
-### Effort
-Total person-weeks to design, build, and ship.
-
-| Score | Meaning |
-|-------|---------|
-| 0.5 | Half a week or less |
-| 1 | About 1 week |
-| 2 | ~2 weeks |
-| 5 | ~1 month |
-| 10 | Multi-month project |
-
-## Calculation Examples
-
-| Feature | Reach | Impact | Confidence | Effort | RICE Score |
-|---------|-------|--------|------------|--------|------------|
-| One-click checkout | 8,000 | 3 | 80% | 3 | **6,400** |
-| Dark mode toggle | 5,000 | 0.5 | 50% | 1 | **1,250** |
-| Export to CSV | 2,000 | 2 | 100% | 0.5 | **8,000** |
-| AI search | 10,000 | 2 | 50% | 10 | **1,000** |
-
-Higher score = higher priority.
-
-## Prioritization Tiers
-
-| RICE Score | Tier | Action |
-|------------|------|--------|
-| >5,000 | P0 — Must Ship | Schedule immediately |
-| 1,000–5,000 | P1 — High Priority | Include in next cycle |
-| 200–999 | P2 — Medium Priority | Backlog, revisit quarterly |
-| <200 | P3 — Low Priority | Won't do / nice to have |
-
-## When Data is Unavailable
-
-Use relative RICE (rank order, not absolute scores):
-- Assign all factors on 1–10 scale relative to each other
-- Note confidence as Low/Medium/High instead of percentages
-- Mark scores as estimates in PRD: `~2,400 (estimated)`
-
-## PRD Integration
-
-In the PRD, present RICE scores in the requirements table:
-
-```markdown
-| Story | Reach | Impact | Confidence | Effort | Score | Priority |
-|-------|-------|--------|------------|--------|-------|----------|
-| ...   | 5,000 | 2      | 80%        | 2      | 4,000 | P1       |
-```
-
-Always document assumptions used in scoring under the table.

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

@@ -1,72 +0,0 @@
----
-name: create-prd-orchestrator
-type: orchestrator
-agents: [researcher, edge-case-finder, requirements-writer, prioritizer, reviewer]
----
-
-# Create-PRD Orchestrator
-
-> 구조·섹션·네이밍은 vibe/rules/orchestrator-contract.md (SSOT) 를 따른다.
-
-## Workflow
-
-### Phase 1: Gather Context
-- **Agent**: researcher, edge-case-finder
-- **Input**: Feature idea or problem statement + codebase context
-- **Output**: researcher → existing patterns, prior art, constraints; edge-case-finder → edge cases, failure modes, user scenarios
-- **Parallel**: yes — researcher and edge-case-finder run simultaneously
-
-### Phase 2: Draft User Stories
-- **Agent**: requirements-writer
-- **Input**: Context and edge cases from Phase 1
-- **Output**: User stories in `As a / I want / So that` format with acceptance criteria
-- **Parallel**: no — sequential synthesis of Phase 1 outputs
-
-### Phase 3: Prioritize
-- **Agent**: prioritizer
-- **Input**: User stories from Phase 2
-- **Output**: RICE-scored stories with recommended MoSCoW classification (Must/Should/Could/Won't)
-- **Parallel**: no — requires full story set for relative scoring
-
-### Phase 4: Review
-- **Agent**: reviewer
-- **Input**: Prioritized stories + RICE scores from Phase 3
-- **Output**: Completeness verdict — missing sections, ambiguous requirements, scope concerns
-- **Parallel**: no
-
-### Phase 5: Output PRD
-- **Agent**: orchestrator (self)
-- **Input**: All phase outputs
-- **Output**: Structured PRD document using `templates/prd.md` format
-- **Parallel**: no
-
-## DAG (Dependency Graph)
-
-```mermaid
-graph TD
-    A[Phase 1a: Researcher] --> C[Phase 2: Requirements-Writer]
-    B[Phase 1b: Edge-Case-Finder] --> C
-    C --> D[Phase 3: Prioritizer]
-    D --> E[Phase 4: Reviewer]
-    E --> F[Phase 5: PRD Output]
-```
-
-## Error Handling
-
-| Phase | Failure Mode | Strategy |
-|-------|-------------|----------|
-| Phase 1 | researcher returns no prior art | Proceed — note "greenfield feature" in PRD |
-| Phase 1 | edge-case-finder times out | Continue with researcher output only, flag limited edge-case coverage |
-| Phase 2 | Problem statement too vague | Pause, prompt user with clarifying questions before continuing |
-| Phase 3 | RICE data unavailable (no metrics) | Use relative scoring (High/Medium/Low), note data gaps |
-| Phase 4 | Reviewer finds critical gaps | Return to Phase 2 with gap list (max 1 retry) |
-| Phase 4 | Retry still incomplete after 1 pass | Flag gaps as `needs-clarification`, output partial PRD |
-| Phase 5 | PRD template missing | Output raw structured markdown without template |
-
-## Scalability Modes
-
-| Mode | When | Agents Used |
-|------|------|-------------|
-| Full | Normal operation | All 5 agents |
-| Reduced | Time pressure | researcher + requirements-writer + reviewer only |
-| Single | Quick story draft | requirements-writer only — draft without research or scoring |

package/skills/vibe.create-prd/rubrics/completeness.md

@@ -1,58 +0,0 @@
-# PRD Completeness Checklist
-
-## Section 1 — Summary
-
-- [ ] Describes what the document is about in 2-3 sentences
-- [ ] Readable by a non-technical stakeholder
-- [ ] Status clearly marked (Draft / Review / Approved)
-
-## Section 2 — Contacts
-
-- [ ] Product Manager named as owner
-- [ ] Engineering Lead included
-- [ ] Designer included (if UI/UX involved)
-- [ ] Key decision-maker or sponsor listed
-
-## Section 3 — Background
-
-- [ ] "Why this?" answered — clear context given
-- [ ] "Why now?" answered — trigger or change identified
-- [ ] No assumed knowledge — first-time reader can understand
-
-## Section 4 — Objective
-
-- [ ] Goal statement is outcome-oriented (not feature-oriented)
-- [ ] At least one measurable Key Result with baseline, target, and timeframe
-- [ ] Linked to company strategy or OKR (even briefly)
-
-## Section 5 — Market Segments
-
-- [ ] Primary audience defined by problem or job-to-be-done (not just demographics)
-- [ ] Constraints explicitly stated (who this is NOT for)
-
-## Section 6 — Value Propositions
-
-- [ ] Customer jobs listed (what users are trying to accomplish)
-- [ ] Gains (benefits) distinguished from pains (problems removed)
-- [ ] Competitive differentiation stated — why us, why better
-
-## Section 7 — Solution
-
-- [ ] 7.1: Prototype link or key screen descriptions included
-- [ ] 7.2: Features table includes priority (Must / Should / Could)
-- [ ] 7.4: At least 2 assumptions listed with validation method
-- [ ] No feature described without a corresponding user job or pain from Section 6
-
-## Section 8 — Release
-
-- [ ] MVP scope defined — what is in V1 vs. later
-- [ ] Out-of-scope items explicitly listed (prevents scope creep)
-- [ ] Relative timeframes used — no hard dates in V1 unless confirmed
-
-## Overall Quality
-
-- [ ] Jargon-free — a new team member can understand without asking
-- [ ] No sections left as placeholder ("TBD" without owner + due date)
-- [ ] Assumptions are flagged, not buried as facts
-- [ ] Document length proportional to initiative size (not bloated)
-- [ ] Open questions have owners and due dates

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

@@ -1,139 +0,0 @@
-# PRD: {{PRODUCT_OR_FEATURE_NAME}}
-
-> Version: {{VERSION}} | Status: {{STATUS}} (Draft / Review / Approved)
-> Last updated: {{DATE}}
-
----
-
-## 1. Summary
-
-{{2-3 SENTENCES DESCRIBING WHAT THIS DOCUMENT COVERS AND WHY IT EXISTS}}
-
----
-
-## 2. Contacts
-
-| Name | Role | Responsibility |
-|------|------|----------------|
-| {{PM_NAME}} | Product Manager | Owner, final decisions |
-| {{LEAD_ENG_NAME}} | Engineering Lead | Technical feasibility |
-| {{DESIGN_NAME}} | Designer | UX/UI |
-| {{STAKEHOLDER_NAME}} | {{STAKEHOLDER_ROLE}} | {{COMMENT}} |
-
----
-
-## 3. Background
-
-**Context**
-{{WHAT IS THIS INITIATIVE ABOUT? WHAT LED TO IT?}}
-
-**Why now?**
-{{HAS SOMETHING CHANGED? NEW DATA, MARKET SHIFT, REGULATORY REQUIREMENT?}}
-
-**Is this newly possible?**
-{{HAS NEW TECHNOLOGY OR CAPABILITY MADE THIS FEASIBLE NOW?}}
-
----
-
-## 4. Objective
-
-**Goal**
-{{WHAT ARE WE TRYING TO ACHIEVE AND WHY DOES IT MATTER?}}
-
-**Strategic alignment**
-{{HOW DOES THIS ALIGN WITH COMPANY VISION AND CURRENT STRATEGY?}}
-
-**Key Results (SMART OKRs)**
-
-| Metric | Baseline | Target | Timeframe |
-|--------|----------|--------|-----------|
-| {{METRIC_1}} | {{BASELINE}} | {{TARGET}} | {{TIMEFRAME}} |
-| {{METRIC_2}} | {{BASELINE}} | {{TARGET}} | {{TIMEFRAME}} |
-
----
-
-## 5. Market Segments
-
-**Primary segment**
-{{WHO ARE WE BUILDING THIS FOR? DESCRIBE BY PROBLEM/JOB, NOT DEMOGRAPHICS.}}
-
-**Secondary segment (if any)**
-{{OPTIONAL}}
-
-**Constraints**
-- {{CONSTRAINT_1}} (e.g., "Users must be logged in")
-- {{CONSTRAINT_2}}
-
----
-
-## 6. Value Propositions
-
-**Customer jobs we address**
-- {{JOB_1}}: {{CONTEXT}}
-- {{JOB_2}}: {{CONTEXT}}
-
-**Gains (what customers get)**
-- {{GAIN_1}}
-- {{GAIN_2}}
-
-**Pains we eliminate**
-- {{PAIN_1}}
-- {{PAIN_2}}
-
-**Competitive advantage**
-{{HOW DO WE SOLVE THIS BETTER THAN ALTERNATIVES? WHAT IS OUR UNIQUE EDGE?}}
-
----
-
-## 7. Solution
-
-### 7.1 UX / Prototypes
-
-{{LINK TO FIGMA OR WIREFRAMES, OR DESCRIBE KEY SCREENS/FLOWS}}
-
-Key user flows:
-1. {{FLOW_1_NAME}}: {{BRIEF DESCRIPTION}}
-2. {{FLOW_2_NAME}}: {{BRIEF DESCRIPTION}}
-
-### 7.2 Key Features
-
-| Feature | Description | Priority |
-|---------|-------------|----------|
-| {{FEATURE_1}} | {{DESCRIPTION}} | Must |
-| {{FEATURE_2}} | {{DESCRIPTION}} | Should |
-| {{FEATURE_3}} | {{DESCRIPTION}} | Could |
-
-### 7.3 Technology (optional)
-
-{{ONLY INCLUDE IF TECH CHOICES HAVE PRODUCT IMPLICATIONS — e.g., real-time, offline support}}
-
-### 7.4 Assumptions
-
-| # | Assumption | How to Validate | Risk if Wrong |
-|---|-----------|-----------------|---------------|
-| 1 | {{ASSUMPTION_1}} | {{VALIDATION_METHOD}} | {{RISK}} |
-| 2 | {{ASSUMPTION_2}} | {{VALIDATION_METHOD}} | {{RISK}} |
-
----
-
-## 8. Release Plan
-
-**Scope approach**: {{PHASED / BIG BANG / GRADUAL ROLLOUT}}
-
-| Phase | What's Included | Estimated Timeline |
-|-------|----------------|-------------------|
-| V1 (MVP) | {{MVP_SCOPE}} | {{RELATIVE_TIME}} |
-| V2 | {{V2_SCOPE}} | {{RELATIVE_TIME}} |
-| Future | {{FUTURE_ITEMS}} | TBD |
-
-**Out of scope (V1)**
-- {{OUT_OF_SCOPE_1}}
-- {{OUT_OF_SCOPE_2}}
-
----
-
-## Open Questions
-
-| # | Question | Owner | Due |
-|---|----------|-------|-----|
-| 1 | {{QUESTION_1}} | {{OWNER}} | {{DATE}} |

package/skills/vibe.design/SKILL.md

@@ -1,236 +0,0 @@
----
-name: vibe.design
-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 가지 입력 소스 중 하나.
-
-## Usage
-
-```
-/vibe.design init                       # 인터뷰 (디폴트)
-/vibe.design init --from=interview      # 대화형 9 섹션 작성
-/vibe.design init --from=code           # 기존 코드 토큰 역추출
-/vibe.design init --from=reference --reference=linear   # awesome-design-md 시드 선택
-/vibe.design init --from=figma --file=<key>             # /vibe.figma 위임 (옵션)
-/vibe.design lint                       # Stitch 9 섹션 완전성 검증
-/vibe.design verify [--files=<glob>]    # 구현 ↔ DESIGN.md hex 드리프트 (v1)
-/vibe.design sync                       # Figma 연결 시 양방향 동기화 (Should, Phase 2)
-/vibe.design preview "description"      # UI 프리뷰 (Antigravity 목업 또는 ASCII 폴백)
-```
-
-## Philosophy
-
-- **Figma 독립**: 모든 서브커맨드는 Figma 없이 동작. Figma 연결 시에만 sync 활성.
-- **권유 > 강제**: DESIGN.md 부재 = 안내 메시지 1 회. `/vibe.run` · `/vibe.verify` 는 막지 않는다.
-- **Stitch 9 섹션 표준**: 외부 에이전트 호환 (Google Stitch, awesome-design-md 생태계).
-- **버전 frontmatter**: `<!-- design-md-version: 1 -->` 로 미래 호환.
-- **루트 배치**: `CLAUDE.md` · `AGENTS.md` 와 동일하게 프로젝트 루트.
-
-## Process
-
-> **⏱️ Timer**: 시작 시 시스템 시각을 조회해 `{start_time}` 으로 기록.
-
-### Subcommand: `init`
-
-**진입 조건**: 프로젝트 루트에 `DESIGN.md` 없음 (있으면 덮어쓰기 확인).
-
-**경로 결정**:
-
-| `--from` | 동작 |
-|---------|------|
-| 미지정 / `interview` | 대화형 9 섹션 인터뷰 (디폴트) |
-| `code` | 기존 코드에서 토큰 역추출 → 인터뷰 보강 |
-| `reference` | `--reference=<slug>` 로 시드 카탈로그 선택 → §1·§2·§3 시드 + §4–§9 단축 인터뷰 |
-| `figma` | `/vibe.figma --emit-design-md` 위임 (Figma MCP 필요) |
-
-**공통 출력**:
-- 위치: `<프로젝트 루트>/DESIGN.md`
-- 첫 줄: `<!-- design-md-version: 1 -->`
-- 9 H2 섹션 (Visual Theme / Color Palette / Typography / Components / Layout / Depth / Do's & Don'ts / Responsive / Agent Prompt Guide)
-- 템플릿: `templates/DESIGN.md.template`
-
-#### `--from=interview` 흐름
-
-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` 흐름
-
-1. `.vibe/config.json` 의 `stacks[].type` 으로 추출기 결정 (`heuristics/code-extract.md`)
-2. v1 필수 패턴: **Tailwind config / CSS custom properties / styled-components theme**
-3. 추출된 토큰을 §2·§3·§4 시드로 사용
-4. 나머지 6 섹션은 단축 인터뷰 (≤3 질문) 또는 템플릿 기본값
-
-#### `--from=reference` 흐름
-
-1. `references/README.md` 시드 카탈로그에서 `--reference=<slug>` 매칭 (`linear`, `vercel`, `stripe` …)
-2. 시드의 `style-preset` 한 줄 (예: `"minimal, neutral grays + electric purple accent, Inter Display"`) 로 §1·§2·§3 기본값 채움
-3. §4–§9 는 단축 인터뷰 (≤3 질문)
-4. 네트워크 차단 환경에서도 동작 (시드는 로컬 시드)
-
-#### `--from=figma` 흐름
-
-1. `/vibe.figma --emit-design-md --file=<key>` 호출 (위임)
-2. 산출물(`DESIGN.md`) 받아서 lint 통과 확인
-
-### Subcommand: `lint`
-
-**입력**: 프로젝트 루트 `DESIGN.md`
-
-**체크**:
-- 9 섹션 모두 존재 (`lintMissingSections` from `design-md-parser.ts`)
-- frontmatter 버전 주석 존재
-- §2 (Color Palette) 에 최소 1 개 hex 토큰
-- §9 (Agent Prompt Guide) 비어있지 않음
-
-**출력**:
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-✅ DESIGN.md lint PASS
-   9 sections, 12 color tokens, version 1
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-또는:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-❌ DESIGN.md lint FAIL (P1: 2)
-   Missing: Typography, Responsive
-   → Run /vibe.design init to regenerate, or edit DESIGN.md
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-**성능 목표**: <200ms (100 줄 DESIGN.md 기준).
-
-### Subcommand: `verify`
-
-**입력**:
-- 프로젝트 루트 `DESIGN.md` (없으면 안내 후 종료)
-- `--files=<glob>` (기본: 최근 변경 파일 — `/vibe.verify` 의 changed-files 정책 따름)
-
-**체크 (v1 범위)**:
-- `extractHexTokens(DESIGN.md)` → 허용 토큰 셋
-- `findHardcodedColors(files, allowed)` → 허용 셋 밖 hex = P1 후보
-
-**v1 비범위** (Phase 2+):
-- spacing / font-family 드리프트
-- HSL/RGB/named color
-- Tailwind arbitrary value `bg-[#xxxxxx]`
-
-**출력**:
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-✅ DESIGN.md verify PASS (32 files scanned)
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-또는:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-❌ DESIGN.md verify FAIL (P1: 3 hex drifts)
-   src/Button.tsx:42  #FF5733 not in DESIGN.md tokens
-   src/Card.tsx:18    #123456 not in DESIGN.md tokens
-   src/Nav.tsx:7      #ABCDEF not in DESIGN.md tokens
-   → Add to DESIGN.md §2 Color Palette, or replace with token
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-**성능 목표**: <1s / 100 파일.
-
-### Subcommand: `sync` (Should, Phase 2)
-
-**진입 조건**: `~/.vibe/config.json#figma.token` 존재 + `--file=<key>` 또는 프로젝트에 figma 연결 메타.
-
-**v1 동작**: "Phase 2 에서 활성됩니다. 현재는 `/vibe.figma --emit-design-md` 를 사용하세요." 메시지 후 종료.
-
-### Subcommand: `preview`
-
-Generate the UI preview directly in the main session (native capability — no dedicated agent). DESIGN.md 와 독립적으로 동작 — 임시 프리뷰용.
-
-Generate UI preview from a text description, a design folder, or a single file.
-
-- **Antigravity enabled**: UI mockup image + component code generation
-- **Antigravity disabled**: ASCII art fallback
-
-**Input types:**
-
-| Input | Example |
-| ----- | ------- |
-| Text description | `"Login form with email, password"` |
-| Design folder | `./design/` |
-| Single file | `./mockups/login.html` |
-
-> Read `references/ui-preview.md` for the full supported file-format list and example invocations.
-
-## Integration
-
-| Skill | 통합 지점 |
-|------|---------|
-| `/vibe.run` | UI 스택 진입 시 `DESIGN.md` 없으면 `### DESIGN.md Gate` 에서 권유 (ultrawork 시 silent skip) |
-| `/vibe.verify` | `### 3.2 Visual Drift Detection` 에서 `vibe.design verify` 호출 — P1 → fail |
-| `/vibe.review` | `### Phase 2.5 Visual P1 Baseline` 에서 DESIGN.md 우선, 없으면 WCAG AA 폴백 |
-| `/vibe.figma` | WRITE 는 DESIGN.md 읽어 톤·팔레트 우선, READ 는 `--emit-design-md` 플래그로 출력 |
-
-### 생태계 스킬 — 권유만 하고 설치하지 않는다
-
-사용자가 "AI 티 나는 UI", "밋밋하다", "레퍼런스 보드가 필요하다" 를 말하면 아래를
-**한 번 언급**한다. `DESIGN.md` 가 규범(팔레트·타이포·간격 SSOT)을 잡는다면, 이쪽은
-그 규범 안에서의 **취향**을 다룬다 — 겹치지 않고 보완한다.
-
-```bash
-npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"
-```
-
-**자동 설치하지 않는 이유**: 스킬은 하나하나가 매 세션 상시 컨텍스트다
-(`vibe status` 의 Skills 행이 그 총량을 보고한다). 저 저장소는 스킬을 여러 개
-담고 있어 통째로 받으면 컨텍스트가 눈에 띄게 늘어난다 — 그래서 `--skill` 로
-하나만 집는 형태로 안내한다. 3rd-party 스킬을 사용자 머신에 말없이 얹는 것은
-신뢰 결정이라 사람이 한다.
-
-권유는 **1회로 끝낸다.** 거절했거나 이미 설치돼 있으면 다시 꺼내지 않는다.
-
-## Figma Credential Handling (init/sync only)
-
-- 토큰 출처: `~/.vibe/config.json#figma.token` (chmod 0o600)
-- 메모리 외 노출 금지. 로그에는 마지막 4 자만 노출 (`****abc1`)
-- `--from=figma` · `sync` 외 서브커맨드는 토큰 읽지 않음
-
-## Output
-
-| 파일 | 생성/수정 |
-|-----|---------|
-| `<root>/DESIGN.md` | `init` / `sync` |
-| 콘솔 리포트 | `lint` / `verify` |
-| ASCII 프리뷰 또는 목업 이미지 | `preview` |
-
-## Heuristics & References
-
-- 코드 역추출 패턴: `heuristics/code-extract.md`
-- 시드 카탈로그: `references/README.md`
-- UI 프리뷰 포맷·예시: `references/ui-preview.md`
-- 템플릿: `templates/DESIGN.md.template`
-
-ARGUMENTS: $ARGUMENTS