solmate-skills 1.0.1 → 2.0.0

package/docs-dev/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: docs-dev
+description: Create and manage development documents for Layer 3 (Technical_Specs), Layer 4 (Logic_Progress), and Layer 5 (QA_Validation). Use when writing DB schema docs, API specs, development principles, roadmaps, backlogs, business logic designs, or test scenarios. Always read existing files before editing. Include Related Documents sections.
+---
+
+# Development Documentation Skill
+
+This skill manages **Layer 3 (Technical_Specs)**, **Layer 4 (Logic_Progress)**, and **Layer 5 (QA_Validation)** — the "How" of the project.
+
+> Shared conventions (metadata format, naming rules, 365 Principle overview, link format) are defined in `rules-docs`.
+
+## 1. Rules
+
+1. 이모지 금지. 전문적이고 명확한 텍스트로만 소통한다.
+2. Ask before Write: 초안 작성 전 핵심 질문을 던지고 답변을 바탕으로 작성한다.
+3. 기존 문서가 있으면 반드시 먼저 읽고 컨텍스트와 스타일을 유지하며 업데이트한다. 덮어쓰지 않는다.
+
+## 2. Layer 정의
+
+| Layer | Directory | Purpose |
+|:---|:---|:---|
+| Technical_Specs | `docs/03_Technical_Specs/` | 기술 명세, DB 스키마, API 설계, 개발 원칙 |
+| Logic_Progress | `docs/04_Logic_Progress/` | 로드맵, 백로그, 비즈니스 로직, 상태 관리, 알고리즘 |
+| QA_Validation | `docs/05_QA_Validation/` | 테스트 시나리오, QA 체크리스트, 검증 보고서 |
+
+**Context Flow**:
+- Technical_Specs ← Concept_Design (기능 명세 기반), ← UI_Screens (UI 요구사항 반영)
+- Logic_Progress ← Technical_Specs (데이터 모델/API 명세 참조)
+- QA_Validation ← 모든 상위 레이어 참조
+
+### Required Documents
+
+**Layer 3 — Technical_Specs**
+- `00_DEVELOPMENT_PRINCIPLES.md` — 아키텍처, 패턴, 스탠다드, 도구, gitignore 대상
+- `01_DB_SCHEMA.md` — 데이터 모델 설계
+- `02_API_SPECS.md` — API 엔드포인트 명세
+
+**Layer 4 — Logic_Progress**
+- `00_BACKLOG.md` — Kanban 보드 (ToDo / In Progress / Done 구분 및 **모든 항목 체크박스 필수**)
+- `00_ROADMAP.md` — Phase별 마일스톤 및 일정 전략 (Layer 3 기술 명세 링크 필수)
+- `01_EXECUTION_PLAN.md` — 구체적인 작업 구현 일정 및 실행 전략 (**원자적 단위로 분할된 체크리스트 필수**)
+- `02_ROADMAP_BACKLOG_SYNC.md` — Roadmap과 Backlog 동기화 규칙
+
+**Layer 5 — QA_Validation**
+- `01_TEST_SCENARIOS.md` — 테스트 케이스
+- `02_QA_CHECKLIST.md` — 릴리스 기준 체크리스트
+
+## 3. Interactive Process (Ask Before Write)
+
+### Specs Phase (DB_SCHEMA, API_SPECS 작성 전 필수)
+
+1. **Tech Stack & Architecture**: 프레임워크? DB? ORM? 인증 방식? (Open-source/Composability Check)
+2. **Data Models & Relationships**: 핵심 엔티티는? 주요 관계는? 미디어 저장 방식(DB vs Storage)?
+3. **API Strategy & Edge Cases**: REST or GraphQL? 실패/재시도/Rate limit 처리? 다국어/다통화 로직?
+4. **Performance & UX Goals**: 목표 지연 시간(예: 400ms)? 캐싱 전략? 사용자 여정 단순화 방법?
+
+### Logic Phase (BACKLOG, 코딩 시작 전 필수)
+
+**중요 규칙**: 실무 문서(`00_BACKLOG.md`, `00_ROADMAP.md`, `01_EXECUTION_PLAN.md`) 작성 시, 모든 작업은 반드시 체크박스`[ ]`를 사용하여 원자적 단위(Atomic Task)로 최대한 상세히 나누어 기록해야 한다. "추상적인 작업" 대신 "실제로 실행 및 검증 가능한 단계"로 분할한다.
+
+1. **Project Initialization**: CLI 프리셋 vs 수동 설정?
+2. **UI Theme Strategy**: 사전 정의된 테마 vs 커스텀 브랜드 색상? 폰트 선택?
+3. **Folder Structure**: Feature 기반 vs Type 기반?
+
+### Dev Phase (DEVELOPMENT_PRINCIPLES 작성/갱신 시 필수)
+
+코드베이스를 분석하고 아래 4개 영역을 사용자와 확인한다.
+
+1. **Architecture**: 현재 폴더 구조는? import 규칙(path alias vs relative)은? server/client 경계 분리 방식은?
+2. **Patterns**: 상태 관리 전략은? 에러 처리 패턴(throw Response vs return error)은? 컴포넌트 구성 규칙은?
+3. **Standards**: TypeScript strict 유지 여부? 스타일링 규칙(디자인 토큰 vs 임의 값)? 인증/인가 패턴? 커밋 컨벤션?
+   - 데이터 검증: Zod 사용 여부 및 적용 범위는? (API 요청/응답, env 파싱, 폼 데이터)
+   - 날짜/시간: Luxon 사용 여부? 네이티브 Date 허용 범위는?
+   - 에러 처리: throw Response vs return error 패턴? ErrorBoundary 전략은?
+   - 피드백 UI: toast 라이브러리 선택은? (sonner, react-hot-toast 등) 사용 범위는?
+4. **Tooling**: 린터/포매터 설정? 테스트 프레임워크? 환경변수 검증 방식? CI/CD?
+
+**비일관성 처리**: 코드베이스에서 비일관성 발견 시 하나의 기준을 선택하고 원칙으로 명시. 기존 코드는 점진적 리팩토링 대상으로 표기.
+
+**[TODO] 항목**: 미구현이나 향후 적용할 원칙은 `[TODO]` 태그와 우선순위(High/Medium/Low)를 명시.
+
+### QA Phase (필수 포함 항목)
+
+1. **Global Rubric Scorecard**: 6가지 기준 평가. (목표: 4개 이상 커버)
+2. **Originality & Ethics Check**: 독창성 및 파생물 복사 여부 확인.
+
+## 4. Global Rubric (6 Core Criteria) — QA 체크 기준
+
+| Criterion | Status (Pass/Fail) | Evidence |
+|:---|:---:|:---|
+| **Functionality** | | MVP 기능 작동 여부 및 코드 품질 |
+| **Potential Impact** | | TAM 크기, 생태계 기여도 |
+| **Novelty** | | 차별적 가치 증명 |
+| **UX** | | 400ms 반응성, 체감 성능 |
+| **Open-source** | | Composability, 재사용 가능성 |
+| **Business Plan** | | 수익 모델 지속 가능성 |
+
+## 5. Templates
+
+### Template C — Technical_Specs
+
+```
+# [Feature Name] Specification
+> Created: YYYY-MM-DD HH:mm
+> Last Updated: YYYY-MM-DD HH:mm
+
+[Document content...]
+
+## X. Related Documents
+- **Concept_Design**: [Product Specs](../01_Concept_Design/03_PRODUCT_SPECS.md) - 기능 명세 및 사이트맵
+- **UI_Screens**: [Related UI Review](../02_UI_Screens/XX_REVIEW.md) - 관련 UI 프로토타입
+- **Technical_Specs**: [DB Schema](./01_DB_SCHEMA.md) - 데이터 모델 설계
+- **Logic_Progress**: [Related Logic](../04_Logic_Progress/XX_LOGIC.md) - 비즈니스 로직 설계
+```
+
+### Template D — Logic_Progress
+
+```
+# [Logic Name] Design
+> Created: YYYY-MM-DD HH:mm
+> Last Updated: YYYY-MM-DD HH:mm
+
+## 1. Context
+(이 로직이 필요한 이유? 어떤 UI와 상호작용하는가?)
+
+**관련 UI**: [Component A] -> [Component B] -> [Final Component]
+
+## 2. Business Rules
+- [ ] Rule 1:
+- [ ] Rule 2:
+
+## 3. Data Flow & State
+(데이터가 어떻게 이동하는가? 필요 시 상태 머신 다이어그램)
+
+## 4. Algorithm / Pseudo-code
+(단계별 로직 설명)
+
+## 5. Related Documents
+- **Concept_Design**: [Product Specs](../01_Concept_Design/03_PRODUCT_SPECS.md) - 관련 기능 명세
+- **UI_Screens**: [Related UI Review](../02_UI_Screens/XX_REVIEW.md) - 관련 UI 프로토타입
+- **Technical_Specs**: [DB Schema](../03_Technical_Specs/01_DB_SCHEMA.md) - 데이터 모델 참조
+- **Technical_Specs**: [API Specs](../03_Technical_Specs/02_API_SPECS.md) - API 엔드포인트 참조
+- **QA_Validation**: [Test Scenarios](../05_QA_Validation/01_TEST_SCENARIOS.md) - 관련 테스트 케이스
+```
+
+### Template E — QA_Validation
+
+```
+# Test Report: [Feature Name]
+> Created: YYYY-MM-DD HH:mm
+> Last Updated: YYYY-MM-DD HH:mm
+
+## 1. Rubric Validation (Mandatory)
+
+| Criterion | Status (Pass/Fail) | Evidence |
+|:---|:---:|:---|
+| Functionality | | MVP 기능 작동 여부 및 린트/타입 에러 부재 |
+| Potential Impact | | 생태계 기여 및 데이터 확장성 확인 |
+| Novelty | | 기존 기능 대비 차별적 가치 증명 |
+| UX | | 응답 속도(400ms) 및 인터랙션 매끄러움 |
+| Open-source | | 모듈 간 결합성 및 재사용 가능성 |
+| Business Plan | | 기능 구현이 수익 모델/지속성에 기여하는가 |
+
+## 2. Test Scenarios & Results
+(상세 테스트 케이스 및 결과)
+
+## 3. Related Documents
+- **Concept_Design**: [Product Specs](../01_Concept_Design/03_PRODUCT_SPECS.md) - 테스트 대상 기능 명세
+- **UI_Screens**: [Related UI Review](../02_UI_Screens/XX_REVIEW.md) - 테스트 대상 UI 프로토타입
+- **Technical_Specs**: [DB Schema](../03_Technical_Specs/01_DB_SCHEMA.md) - 데이터베이스 테스트 참조
+- **Technical_Specs**: [API Specs](../03_Technical_Specs/02_API_SPECS.md) - API 테스트 참조
+- **Logic_Progress**: [Related Logic](../04_Logic_Progress/XX_LOGIC.md) - 비즈니스 로직 테스트 참조
+- **QA_Validation**: [QA Checklist](./02_QA_CHECKLIST.md) - 릴리스 기준 및 체크리스트
+```
+
+## 6. Related Skills
+
+- **docs-plan**: Layer 1-2 기획/디자인 문서 작성
+- **rules-dev**: 코딩 컨벤션 및 개발 설정 규칙 적용 (문서화가 아닌 코드 작성 시)
+- **verify-docs**: 문서 구조/메타데이터 검증
+- **verify-db**: DB 스키마 검증 (Drizzle/Prisma)

package/docs-pitch/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: docs-pitch
+description: Create compelling pitch decks for investors, hackathons, and competitions. Supports two output modes — Markdown (content-first) or Reveal.js HTML (browser presentation). Applies the 3 Investor Lenses and 6 Global Rubrics. Use when preparing for investor meetings, competition submissions, or demo days. Integrates with docs-plan Layer 1 documents.
+---
+
+# Pitch Documentation Skill (Pitch Deck)
+
+This skill creates pitch decks optimized for investors, hackathon judges, and competition reviewers.
+**Output mode는 상황에 따라 선택한다** — Markdown, Reveal.js HTML 중 하나.
+
+> This skill reads from `docs-plan` Layer 1 documents (VISION_CORE, LEAN_CANVAS, PRODUCT_SPECS) as source material. Run `docs-plan` first if those documents don't exist yet.
+
+## 1. Rules
+
+1. 이모지 금지. 전문적이고 명확한 텍스트로만 소통한다.
+2. Ask before Write: 아래 Phase 질문을 먼저 던지고 답변을 바탕으로 작성한다.
+3. 기존 PITCH_DECK.md가 있으면 반드시 먼저 읽고 컨텍스트를 유지하며 업데이트한다.
+4. 모든 주장은 수치, 사례, 증거로 뒷받침한다. 추측 기반 문장 금지.
+
+## 2. 핵심 평가 프레임워크
+
+피치덱의 모든 내용은 두 가지 프레임워크를 통과해야 한다.
+
+### 2.1. 3 Investor Lenses
+
+| Lens | 질문 | 통과 기준 |
+|:---|:---|:---|
+| **Leverage** | 내가 커질 때 생태계도 함께 커지는가? | 네트워크 효과, 플랫폼 확장성 증명 가능 |
+| **Realistic Money Flow** | "어떻게 돈 버는가?"에 군더더기 없이 답할 수 있는가? | 수익 경로가 1-2문장으로 설명됨 |
+| **Defensibility** | 시간이 흐를수록 따라오기 힘든 해자(Moat)는 무엇인가? | 데이터, 네트워크, 특허, 브랜드 중 하나 이상 |
+
+### 2.2. 6 Global Rubrics (목표: 4개 이상 강점)
+
+| Criterion | 피치에서의 질문 |
+|:---|:---|
+| **Functionality** | 실제로 작동하는 MVP가 있는가? |
+| **Potential Impact** | TAM이 크고 생태계 기여도가 명확한가? |
+| **Novelty** | 기존에 없던 접근인가? 차별점이 한 문장으로 설명되는가? |
+| **UX** | 기술적 성능이 체감 가능한 UX로 전환되었는가? (400ms 등) |
+| **Open-source** | 다른 빌더가 위에서 만들 수 있는가? |
+| **Business Plan** | 지속 가능한 수익 모델이 있는가? |
+
+## 3. Interactive Process (Ask Before Write)
+
+### Phase 0 — 출력 모드 선택 (첫 번째 질문)
+
+시작 전 반드시 출력 모드를 확인한다.
+
+| 모드 | 언제 선택하는가 | 출력물 |
+|:---|:---|:---|
+| **A. Markdown** | 내용 작성이 목적, 노션/Slides.com 등 외부 도구로 옮길 예정 | `docs/01_Concept_Design/XX_PITCH_DECK.md` |
+| **B. Reveal.js HTML** | 브라우저에서 바로 발표, GitHub Pages 배포 예정 | `pitch/index.html` |
+
+> 모드를 명시하지 않으면 목적과 청중을 파악한 뒤 권장 모드를 제안한다.
+
+### Phase 1 — 기본 정보 수집
+
+1. **목적과 청중**: 이 피치덱의 목적은? (투자 유치 / 해커톤 / 데모데이 / 경쟁 제출) 청중은 누구인가?
+2. **시간 제약**: 발표 시간은? (3분 / 5분 / 10분) 슬라이드 수 제한이 있는가?
+3. **현재 단계**: 팀 구성은? 개발 진행 상태는? (아이디어 / 프로토타입 / MVP / 실제 사용자 보유)
+4. **보유 증거**: 수치로 증명할 수 있는 것은? (사용자 수, 전환율, 매출, 인터뷰 수 등)
+
+### Phase 2 — 스토리 구조 결정
+
+5. **문제의 긴박성**: 이 문제가 지금 당장 해결되어야 하는 이유는? 현재 대안의 한계는?
+6. **"Aha" 순간**: 우리 솔루션을 처음 본 사람이 "이거다"라고 느끼는 순간은 언제인가?
+7. **Moat 선택**: 우리의 핵심 해자는? (데이터 축적 / 네트워크 효과 / 기술 특허 / 브랜드 / 독점 파트너십)
+8. **Ask**: 무엇을 요청하는가? (투자금액 / 파트너십 / 멘토링 / 상금)
+
+## 4. 표준 피치덱 구조 (10 Slides)
+
+각 슬라이드의 핵심 메시지는 **1문장**으로 요약되어야 한다.
+
+### Slide 1 — Hook (첫인상)
+- **목적**: 3초 안에 청중의 주의를 잡는다.
+- **포함 내용**: 제품명, 한 줄 설명(tagline), 시각적으로 강렬한 문제 제시
+- **체크**: "이게 뭔지 바로 이해되는가?"
+
+### Slide 2 — Problem (문제)
+- **목적**: 청중이 문제의 심각성에 공감하게 한다.
+- **포함 내용**: 구체적인 Pain Point, 현재 대안의 한계, 문제의 규모(수치)
+- **체크**: "이 문제가 지금 당장 해결되어야 한다는 긴박감이 느껴지는가?"
+
+### Slide 3 — Solution (솔루션)
+- **목적**: "Aha" 순간을 만든다.
+- **포함 내용**: 핵심 기능 1-3가지, 작동 방식 간략 설명, 스크린샷 또는 데모 링크
+- **체크**: "문제와 솔루션이 직접 연결되는가?"
+
+### Slide 4 — Market Size (시장 규모)
+- **목적**: Leverage Lens 통과 — 충분히 큰 시장임을 증명한다.
+- **포함 내용**: TAM / SAM / SOM 수치, 출처 명시, 성장률 트렌드
+- **체크**: "TAM이 투자 가능한 규모(최소 $1B+)인가?"
+
+### Slide 5 — Product (제품 상세)
+- **목적**: Functionality Rubric 통과 — 실제로 작동함을 증명한다.
+- **포함 내용**: 핵심 유저 플로우(3단계 이내), 주요 기능 스크린샷, 기술적 차별점
+- **체크**: "MVP가 실제로 존재하는가?"
+
+### Slide 6 — Business Model (비즈니스 모델)
+- **목적**: Realistic Money Flow Lens 통과 — 수익 경로가 명확함을 증명한다.
+- **포함 내용**: 수익 모델(구독 / 거래 수수료 / 광고 / API 과금 등), 단위 경제(LTV, CAC), 가격 정책
+- **체크**: "어떻게 돈 버는지 1-2문장으로 설명 가능한가?"
+
+### Slide 7 — Traction (견인력)
+- **목적**: 시장 검증 증거를 제시한다.
+- **포함 내용**: 사용자 수 / 성장률 / 매출 / 파트너십 / 미디어 언급 / 사용자 인터뷰 인용
+- **체크**: "숫자가 있는가? 추측이 아닌 증거인가?"
+
+### Slide 8 — Competition (경쟁 분석)
+- **목적**: Defensibility Lens 통과 — 우리만의 해자를 증명한다.
+- **포함 내용**: 경쟁사 비교 매트릭스, 우리의 독점적 우위, Moat의 지속 가능성
+- **체크**: "왜 우리가 이기는지 명확한가? '더 빠르다'는 이유가 되지 않는다."
+
+### Slide 9 — Team (팀)
+- **목적**: "이 팀이 이 문제를 해결할 수 있는 유일한 팀인가?"를 납득시킨다.
+- **포함 내용**: 핵심 멤버 이름/역할/관련 경력, 이 문제를 해결하는 데 특별한 이유(Unfair Advantage)
+- **체크**: "팀이 이 문제와 필연적으로 연결되어 있는가?"
+
+### Slide 10 — Ask (요청)
+- **목적**: 청중이 다음에 무엇을 해야 하는지 명확하게 한다.
+- **포함 내용**: 요청 사항 (금액 / 파트너십 / 멘토링), 자금 사용 계획, 6-18개월 마일스톤
+- **체크**: "Call to Action이 구체적이고 실행 가능한가?"
+
+## 5. 3분 스토리텔링 스크립트 구조
+
+발표 시간이 3분일 경우 아래 시간 배분을 따른다.
+
+| 시간 | 내용 | 목적 |
+|:---|:---|:---|
+| 0:00-0:20 | Hook + Problem | 공감 형성 |
+| 0:20-0:50 | Solution + Demo | "Aha" 순간 |
+| 0:50-1:20 | Market + Traction | 규모와 증거 |
+| 1:20-1:50 | Business Model + Moat | 수익성과 지속성 |
+| 1:50-2:20 | Team | 신뢰 형성 |
+| 2:20-2:45 | Ask + Milestones | Call to Action |
+| 2:45-3:00 | Closing Hook | 기억에 남기기 |
+
+## 6. 출력 형식 (모드별)
+
+### Mode A — Markdown
+
+저장 경로: `docs/01_Concept_Design/XX_PITCH_DECK.md`
+
+```
+# Pitch Deck: [Product Name]
+> Created: YYYY-MM-DD HH:mm
+> Last Updated: YYYY-MM-DD HH:mm
+> Target: [투자자 / 해커톤명 / 데모데이명]
+> Format: [슬라이드 수] slides / [발표 시간]
+
+## Investor Lens Check
+- Leverage:
+- Realistic Money Flow:
+- Defensibility:
+
+## Rubric Score
+| Criterion | Score (1-5) | Evidence |
+...
+
+## Slide 1 — Hook
+**One-line message:**
+**Content:**
+
+## Slide 2 — Problem
+...
+
+## 3-Minute Script (Optional)
+...
+
+## Related Documents
+<!-- 아래 경로는 이 스킬을 사용하는 실제 프로젝트 기준입니다. solmate-skills 저장소에 존재하는 파일이 아닙니다. -->
+- **Concept_Design**: [Vision & Core Values] — ../01_Concept_Design/01_VISION_CORE.md
+- **Concept_Design**: [Lean Canvas] — ../01_Concept_Design/02_LEAN_CANVAS.md
+- **Concept_Design**: [Product Specs] — ../01_Concept_Design/03_PRODUCT_SPECS.md
+```
+
+---
+
+### Mode B — Reveal.js HTML
+
+저장 경로: `pitch/index.html`
+
+**실행 절차:**
+
+1. `pitch/` 디렉토리 생성
+2. CDN 방식으로 Reveal.js 로드 (별도 설치 불필요):
+   ```html
+   <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/reveal.js/dist/reveal.css">
+   <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/reveal.js/dist/theme/black.css">
+   <script src="https://cdn.jsdelivr.net/npm/reveal.js/dist/reveal.js"></script>
+   ```
+3. 각 슬라이드는 `<section>` 태그로 구성
+4. 발표 후 `npx serve pitch/` 또는 GitHub Pages로 공유
+
+**슬라이드 구조 템플릿:**
+```
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>[Product Name] Pitch</title>
+  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/reveal.js/dist/reveal.css">
+  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/reveal.js/dist/theme/black.css">
+  <style>
+    /* 브랜드 색상 오버라이드 */
+    :root { --r-background-color: #0f0f0f; --r-main-color: #ffffff; }
+    .highlight { color: #your-brand-color; }
+  </style>
+</head>
+<body>
+  <div class="reveal">
+    <div class="slides">
+      <section> <!-- Slide 1: Hook --> </section>
+      <section> <!-- Slide 2: Problem --> </section>
+      <!-- ... 10 slides total -->
+    </div>
+  </div>
+  <script src="https://cdn.jsdelivr.net/npm/reveal.js/dist/reveal.js"></script>
+  <script>Reveal.initialize({ hash: true, transition: 'fade' });</script>
+</body>
+</html>
+```
+
+**키보드 단축키**: 방향키로 슬라이드 이동, `F`로 전체화면, `S`로 발표자 노트
+
+---
+
+---
+
+## 7. Common Pitfalls
+
+| 피해야 할 것 | 이유 |
+|:---|:---|
+| "우리에겐 경쟁자가 없다" | 신뢰 붕괴. 모든 문제엔 현재 대안이 존재한다. |
+| 기술 스택 나열 | 투자자는 기술이 아닌 임팩트에 투자한다. |
+| 수치 없는 주장 | "빠르게 성장 중" 대신 "MoM 30% 성장" |
+| 10개 이상의 핵심 기능 | 집중력 분산. 핵심 1-3개만. |
+| Ask 없이 마무리 | 청중이 다음 행동을 모르면 연결이 끊긴다. |
+| 팀 슬라이드 생략 | 초기 스타트업은 팀이 곧 제품이다. |
+
+## 8. Related Skills
+
+- **docs-plan**: 피치덱의 원천 데이터 (VISION_CORE, LEAN_CANVAS, PRODUCT_SPECS)
+- **rules-docs**: 공통 문서 규칙 및 365 Principle 정의
+- **verify-docs**: 작성된 문서 구조/메타데이터 검증

package/docs-plan/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: docs-plan
+description: Create and manage planning documents for Layer 1 (Concept_Design) and Layer 2 (UI_Screens). Use when documenting product vision, lean canvas, product specs, UI design systems, screen flows, or prototype reviews. Ask before writing. Always include Related Documents sections.
+---
+
+# Planning Documentation Skill
+
+This skill manages **Layer 1 (Concept_Design)** and **Layer 2 (UI_Screens)** — the "Why, Who, What" of the project.
+
+> Shared conventions (metadata format, naming rules, 365 Principle overview, link format) are defined in `rules-docs`.
+
+## 1. Rules
+
+1. 이모지 금지. 전문적이고 명확한 텍스트로만 소통한다.
+2. Ask before Write: 초안 작성 전 핵심 질문을 던지고 답변을 바탕으로 작성한다.
+3. 기존 문서가 있으면 반드시 먼저 읽고 컨텍스트와 스타일을 유지하며 업데이트한다. 덮어쓰지 않는다.
+
+## 2. Layer 정의
+
+| Layer | Directory | Purpose |
+|:---|:---|:---|
+| Concept_Design | `docs/01_Concept_Design/` | 비전, 제품 기획, 비즈니스 전략, 디자인 원칙 정의 |
+| UI_Screens | `docs/02_UI_Screens/` | UI 디자인 시스템, 화면 흐름, 프로토타입 리뷰 |
+
+**Context Flow**:
+- Concept_Design → UI_Screens (디자인 가이드라인 제공)
+- Concept_Design → Technical_Specs (기능 명세 기반 제공)
+- UI_Screens → Technical_Specs (구현 명세 요구사항 도출)
+
+### Required Documents
+
+**Layer 1 — Concept_Design**
+- `00_COLLABORATION_GUIDE.md` — AI-Human 시너지 기준
+- `01_VISION_CORE.md` — 핵심 가치, 타겟 오디언스
+- `02_LEAN_CANVAS.md` — 문제, 솔루션, UVP, 지표
+- `03_PRODUCT_SPECS.md` — MVP 정의, NFR
+- `04_USER_RESEARCH.md` — 사용자 인터뷰, 페르소나, 행동 패턴 (선택, 권장)
+
+**Layer 2 — UI_Screens**
+- `00_SCREEN_FLOW.md` — 전체 사용자 여정
+- `01_UI_DESIGN.md` — 디자인 시스템 (색상, 타이포그래피, 레이아웃)
+- `XX_PROTOTYPE_REVIEW.md` — 페이지별 피드백
+
+## 3. Interactive Process (Ask Before Write)
+
+### Phase 1 — Project Definition (필수)
+
+1. **Why (Problem & Goal)**: 핵심 문제는? 성공 시 세상의 변화는? 단/장기 목표는?
+0. **User Research 보유 여부**: 실제 사용자 인터뷰나 관찰 데이터가 있는가? 있다면 `04_USER_RESEARCH.md`를 먼저 작성하고 이후 문서의 기반으로 활용한다.
+2. **Who (Target User)**: 핵심 고객은? Pain Point는? 현재 해결 방식은?
+3. **What (Value & Differentiation)**: UVP는? 경쟁 대비 차별점은? (Novelty Check)
+4. **How (Feasibility)**: MVP 필수 항목은? 플랫폼 제약은? 법적/보안 우려는? (Functionality Check)
+5. **Distribution Strategy**: 출력 형식(Responsive Web/PWA/App)? 호스팅 플랫폼? 도메인 전략? (Impact Check)
+6. **Global Layout & Brand**: 모든 페이지의 표준 Header/Footer 요소는? AI/어시스턴트 진입점 위치는?
+
+### Phase 2 — Business Model Deep-dive (Pitch Deck, 수익 모델 작성 시 필수)
+
+7. **User Spending Path**: 유저가 지갑을 여는 결정적 순간(Moment of Truth)은? 프라이버시와 결제 레일이 이 경로를 어떻게 보호하는가? (Business Plan Check)
+8. **Privacy as TAM Expander**: 유저가 안심하고 '진실'을 말하게 하는 장치는? 이것이 어떻게 TAM을 확장하는가?
+9. **Company-like Infrastructure**: 다른 빌더/AI 에이전트가 위에서 활동하거나 결제할 수 있는 구조(예: x402, MCP)가 설계되어 있는가? (Scalability Check)
+10. **Action-to-Transaction Flow**: 유저의 자연스러운 '행동'이 어떻게 즉각적인 '거래'로 연결되는가? (Consumer UX Check)
+11. **Technical Necessity**: 선택한 기술 스택이 '필연적'인가? 핵심 기능은 이 기술의 특정 속성 없이는 작동하지 않는다는 것을 증명할 수 있는가?
+
+### Phase 3 — Pitch & Strategy (투자자 대면, 경쟁 제출 준비 시 필수)
+
+12. **Long-term Vision vs. Incremental Execution**: 2주짜리 프로젝트인가, 2년짜리 비즈니스인가? 단계별 실행 전략과 각 단계별 기술 명세 문서 링크가 기록되어 있는가?
+13. **Aesthetics & First Impression**: 프리미엄 UI로 첫 인상에서 유저를 압도할 수 있는 시각적 디테일과 UX 완성도를 갖추었는가?
+14. **Pitch Readiness**: 3분 안에 팀/문제/타겟/비전/검증을 전달할 수 있는가? 6개 루브릭 중 4개 이상이 승리 전략으로 포함되었는가?
+15. **The 3 Investor Lenses**: Leverage / Realistic Money Flow / Defensibility — 세 가지를 증명했는가?
+16. **The Future Weapon**: 6~18개월 뒤 시장에서 싸울 강력한 무기는 무엇인가?
+
+## 4. Templates
+
+### Template 0 — User Research (`04_USER_RESEARCH.md`)
+
+```
+# User Research
+> Created: YYYY-MM-DD HH:mm
+> Last Updated: YYYY-MM-DD HH:mm
+
+## 1. 리서치 개요
+- 목적:
+- 방법: (인터뷰 / 설문 / 관찰 / 사용성 테스트)
+- 대상: N명, [직군/연령/특성]
+- 기간:
+
+## 2. 페르소나
+
+### Persona A — [이름/유형]
+- 배경:
+- 주요 목표:
+- Pain Point:
+- 현재 해결 방식:
+- 우리 제품에 기대하는 것:
+
+## 3. 핵심 인사이트
+(인터뷰/관찰에서 반복적으로 나온 패턴 3-5가지)
+- Insight 1:
+- Insight 2:
+- Insight 3:
+
+## 4. 검증된 가정 / 반증된 가정
+| 가정 | 결과 | 근거 |
+|:---|:---:|:---|
+| | 검증됨 / 반증됨 | |
+
+## 5. Related Documents
+- **Concept_Design**: [Vision & Core Values](./01_VISION_CORE.md) - 타겟 오디언스 정의
+- **Concept_Design**: [Lean Canvas](./02_LEAN_CANVAS.md) - Pain Point 및 솔루션 기반
+- **Concept_Design**: [Product Specs](./03_PRODUCT_SPECS.md) - MVP 기능 우선순위 기반
+```
+
+### Template A — Concept_Design
+
+```
+# [Document Title]
+> Created: YYYY-MM-DD HH:mm
+> Last Updated: YYYY-MM-DD HH:mm
+
+[Document content...]
+
+## X. Related Documents
+- **Concept_Design**: [Vision & Core Values](./01_VISION_CORE.md) - 프로젝트 비전 및 타겟 오디언스
+- **Concept_Design**: [Lean Canvas](./02_LEAN_CANVAS.md) - 비즈니스 모델 및 수익 구조
+- **UI_Screens**: [Screen Flow](../02_UI_Screens/00_SCREEN_FLOW.md) - 사용자 흐름
+- **Technical_Specs**: [Product Specs](../03_Technical_Specs/00_DEVELOPMENT_PRINCIPLES.md) - 기술 명세 기반
+```
+
+### Template B — UI_Screens
+
+```
+# [Prototype Name] Review
+> Created: YYYY-MM-DD HH:mm
+> Last Updated: YYYY-MM-DD HH:mm
+
+## 1. Prototype Link/Screenshot
+(이미지 또는 작동 프로토타입 링크 첨부)
+
+## 2. Key User Flows
+(이 프로토타입에서 시연된 흐름 설명)
+
+## 3. Feedback & Improvements
+(구현 전 변경이 필요한 사항)
+
+## 4. Related Documents
+- **Concept_Design**: [Product Specs](../01_Concept_Design/03_PRODUCT_SPECS.md) - 사이트맵 및 사용자 플로우
+- **UI_Screens**: [UI Design](./01_UI_DESIGN.md) - 디자인 시스템 및 컴포넌트 가이드라인
+- **Technical_Specs**: [Related Spec](../03_Technical_Specs/XX_SPEC.md) - 구현 명세 요구사항
+```
+
+## 5. Related Skills
+
+- **docs-dev**: Layer 3-5 기술 명세/로직/QA 문서 작성
+- **verify-docs**: 작성된 문서의 구조/메타데이터 검증

package/ext-awesome-design/.github/FUNDING.yml

@@ -0,0 +1,4 @@
+# These are supported funding model platforms
+
+github: voltagent
+

package/ext-awesome-design/.github/ISSUE_TEMPLATE/design-md-request.yml

@@ -0,0 +1,46 @@
+name: Design MD Request
+description: Request a DESIGN.md generated from a website
+title: "DESIGN.md for <your website>"
+labels: ["design-md"]
+
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Fill out the form below to request a DESIGN.md generation for your website.
+  - type: input
+    id: website
+    attributes:
+      label: Website URL
+      description: The website you want us to generate DESIGN.md for
+      placeholder: https://example.com
+    validations:
+      required: true
+
+  - type: input
+    id: email
+    attributes:
+      label: Delivery Email
+      description: Email address where we should send the generated DESIGN.md
+      placeholder: you@example.com
+    validations:
+      required: true
+
+  - type: dropdown
+    id: sponsor
+    attributes:
+      label: Do you want to prioritize your DESIGN.md generation request?
+      description: We receive many requests to generate DESIGN.md. As we maintain multiple open-source projects with limited bandwidth, sponsor-backed requests are prioritized. Select the "Priority DESIGN.md generation (awesome-design-md)" tier on [GitHub Sponsors](https://github.com/sponsors/VoltAgent).
+      options:
+        - "Yes, I am a GitHub Sponsor"
+        - "No, I am not a sponsor"
+    validations:
+      required: true
+
+  - type: textarea
+    id: details
+    attributes:
+      label: Additional Details (optional)
+      description: Anything else you'd like us to know about this request
+    validations:
+      required: false

package/ext-awesome-design/CONTRIBUTING.md

@@ -0,0 +1,28 @@
+# Contributing to Awesome Design MD
+
+Thanks for contributing.
+
+This repository is a curated collection of DESIGN.md files extracted from popular websites. Each file captures a site's complete visual language in a format any AI agent can read.
+
+## How to Contribute
+
+### Request a New Site
+
+To request a DESIGN.md for a website, [open an issue](https://github.com/VoltAgent/awesome-design-md/issues/new?template=design-md-request.yml) with the website URL.
+
+We receive many requests, and maintainer bandwidth is limited. Sponsor-backed requests are prioritized, consider supporting the project via [GitHub Sponsors](https://github.com/sponsors/VoltAgent) if you'd like faster turnaround.
+
+### Improve an Existing DESIGN.md
+
+If you notice issues with an existing file:
+
+1. **Open an issue first** to describe what you'd like to change and get feedback from maintainers
+2. Open the site's `DESIGN.md`
+3. Compare against the live site
+4. Fix incorrect hex values, missing tokens, or weak descriptions
+5. Update the `preview.html` and `preview-dark.html` if your changes affect displayed tokens
+6. Open a PR with before/after rationale
+
+## License
+
+By contributing, you agree your contributions are provided under the repository license terms.