solmate-skills 2.0.10 → 2.0.11

package/AGENTS.md

@@ -73,8 +73,14 @@
 - **사용자 커뮤니케이션 필수**: 구현 전 HTML Preview를 사용자에게 보여주고 피드백을 받아야 하며, 확인 결과와 보완 사항을 UI 문서 또는 `docs/04_Logic_Progress/00_BACKLOG.md`에 기록한다.
 - **구현 차단 조건**: HTML Preview가 없거나 문서에 링크되지 않았거나 사용자의 화면 확인 기록이 없으면 UI-First Gate를 통과할 수 없고, 구현을 시작할 수 없다.
 
+### 2.9. Component & Library Planning Gate (필수)
+- **컴포넌트·라이브러리 계획 필수화**: React 구현 전 사용할 shadcn/ui 컴포넌트, 직접 만들 커스텀 컴포넌트, 재사용할 기존 컴포넌트, 새로 설치할 라이브러리, 설치하지 않을 라이브러리를 정리한다.
+- **shadcn 적용 방식 기록**: 신규 Next.js 모노레포는 `init --preset`, 기존 프로젝트는 `apply --preset` 또는 `apply --only theme` 적용 여부를 기록한다. 해당 없으면 `N/A - 사유`를 적는다.
+- **저장 위치**: Component & Library Plan은 `docs/03_Technical_Specs/` 문서, `docs/04_Logic_Progress/00_BACKLOG.md`, 또는 Pre-Code Technical Brief에 기록한다.
+- **구현 차단 조건**: Component & Library Plan이 없으면 React 컴포넌트 구현을 시작할 수 없다.
+
 ## 3. 개발 표준 및 품질
-- **UI 중심 개발 전략 (UI-First)**: Concept_Design -> UI_Screens -> Technical_Specs -> Logic_Progress 순서를 따른다.
+- **UI 중심 개발 전략 (UI-First)**: Concept_Design -> UI_Screens -> HTML Preview -> Pre-Code Technical Brief -> Component & Library Plan -> React 구현 -> Technical_Specs/Logic_Progress 순서를 따른다.
 - **git commit 필수**: 중요 작업 전 반드시 git commit을 수행한다.
 - **커밋 메시지 형식**: `type(scope): subject` 포맷을 따른다.
   - **Type**: `feat`(기능), `fix`(버그), `docs`(문서), `style`(포맷), `refactor`(리팩토링), `test`(테스트), `chore`(기타)
@@ -110,7 +116,7 @@ AI 에이전트는 본 프로젝트에 설치된 다음 **26개 스킬**을 활
 | | `docs-pitch` | 피치덱 작성 (Markdown / Reveal.js HTML) |
 | | `docs-business` | 사업계획서 작성 (정부 지원, 투자 심사, 파트너십 목적별 구성) |
 | **품질 검증 (QA)** | `verify-implementation` | 모든 `verify-*` 스킬의 통합 순차 실행 및 YAGNI/KISS/DRY Gate 보고 |
-| | `verify-docs` | 문서 레이어 정합성 및 네이밍/메타데이터, UI-First Gate 검증 |
+| | `verify-docs` | 문서 레이어 정합성 및 네이밍/메타데이터, UI-First Gate, Component & Library Planning Gate 검증 |
 | | `verify-ui` | 구현 UI와 화면 문서·HTML Preview·사용자 동선·상태별 UI 정합성 검증 |
 | | `verify-code` | PR 전 코드 품질 종합 리뷰 (로직, 타입, 중복, 과잉 구현, 사이드 이펙트) |
 | | `verify-security` | OWASP Top 10 기준 보안 취약점 점검 (인증, 인젝션, 시크릿 노출 등) |
@@ -119,8 +125,8 @@ AI 에이전트는 본 프로젝트에 설치된 다음 **26개 스킬**을 활
 | | `verify-skills` | 스킬 패키지 메타데이터·CLI·README/AGENTS·패키징 검증 |
 | **개발 및 설계** | `rules-dev` | 코딩 표준, 프로젝트 컨벤션, YAGNI/KISS/DRY Gate 준수 여부 확인 |
 | | `rules-react` | UI 컴포넌트 설계 및 구현 표준 가이드 |
-| | `rules-product` | 기획→UI→React→개발문서 전체 파이프라인 오케스트레이션 |
-| **특수 도구(Tools)** | `tools-shadcn` | shadcn/ui 라이브러리 활용 및 커스텀 가이드 |
+| | `rules-product` | 기획→UI→컴포넌트·라이브러리 계획→React→개발문서 전체 파이프라인 오케스트레이션 |
+| **특수 도구(Tools)** | `tools-shadcn` | shadcn/ui 컴포넌트·프리셋·라이브러리 활용 및 커스텀 가이드 |
 | | `tools-obsidian` | 지식 베이스(Obsidian)와의 동기화 및 관리 |
 | **외부 확장(External)** | `ext-awesome-design` | 프리미엄 디자인 시스템 및 마크다운 템플릿 라이브러리 |
 | | `ext-k-skill` | 한국 특화 전문 스킬 모음 (법률, 배송, 교통 등) |

package/README.md

@@ -2,7 +2,7 @@
 
 Reusable AI-agent skills for disciplined product work.
 
-`solmate-skills` packages the Solmate workflow as installable skills: plan the product, create browser-viewable UI previews, lock backlog tasks to their source documents, implement with YAGNI/KISS/DRY approval gates, and verify the result before release.
+`solmate-skills` packages the Solmate workflow as installable skills: plan the product, create browser-viewable UI previews, lock backlog tasks to their source documents, plan components and libraries before coding, implement with YAGNI/KISS/DRY approval gates, and verify the result before release.
 
 Use it when you want an AI coding agent to follow a shared workflow instead of improvising project structure, documentation, implementation order, and QA.
 
@@ -32,10 +32,21 @@ The installer copies each selected skill folder into `.agent/skills/<skill-name>
 - **UI-first planning**: `/docs-plan` creates concept and screen documents before implementation starts.
 - **HTML UI Preview Gate**: major screens and flows must have browser-viewable HTML previews under `docs/02_UI_Screens/previews/`.
 - **Backlog Context Lock**: every backlog item must link the Concept, UI, HTML Preview, Technical Spec, and QA documents needed for implementation.
+- **Component & Library Planning Gate**: React work must name the shadcn/ui components, custom components, reused components, libraries to add, libraries to avoid, and preset action before coding.
 - **YAGNI/KISS/DRY Gate**: `rules-dev` is the canonical source for avoiding future-only features, preferring the simplest existing/native path, and removing only true duplicate knowledge.
 - **Implementation workflow**: `/rules-workflow` keeps coding work tied to approved documents, preconditions, and acceptance criteria.
 - **Release verification**: `/verify-implementation` runs the verification family for docs, UI, code, security, performance, DB schema, and skill package readiness.
 
+## What's New in 2.0.11
+
+`solmate-skills@2.0.11` adds a Component & Library Planning Gate so React implementation starts from approved UI context and an explicit component/library plan.
+
+- `/rules-product` and `/rules-workflow` now connect concept docs, HTML UI preview, component planning, and implementation in a clearer sequence.
+- `/rules-react` requires agents to name shadcn/ui components, custom components, reused components, libraries to add, libraries to avoid, and preset action before coding.
+- `/tools-shadcn` documents the default new-project preset command and existing-project apply command.
+- `/verify-docs` and `/verify-implementation` now check that UI docs, backlog references, and implementation plans preserve the UI-first flow.
+- `README.md` and `AGENTS.md` surface the planning gate as part of the recommended Solmate workflow.
+
 ## What's New in 2.0.10
 
 `solmate-skills@2.0.10` fixes Claude Code hook false positives so read-only tool use no longer triggers edit-oriented skill suggestions.
@@ -227,10 +238,11 @@ docs/
 3. HTML UI Preview Gate → Show browser-viewable HTML screens and capture user feedback
 4. UI-First Gate → Confirm screens, user paths, data flow, and UI states before coding
 5. Pre-Code Technical Brief → Confirm data sources, API shape, state strategy, and acceptance criteria
-6. /docs-dev     → Write DEVELOPMENT_PRINCIPLES.md, DB_SCHEMA.md, API_SPECS.md
-7. /docs-dev     → Write ROADMAP.md, BACKLOG.md with mandatory related document links
-8. /rules-workflow → Implement each backlog item only after reading linked docs and passing UI-First Gate
-9. /verify-implementation  → Audit docs, UI, code, security, performance, DB, and skill package changes
+6. Component & Library Planning Gate → Confirm shadcn components, custom components, reused components, and libraries
+7. /docs-dev     → Write DEVELOPMENT_PRINCIPLES.md, DB_SCHEMA.md, API_SPECS.md
+8. /docs-dev     → Write ROADMAP.md, BACKLOG.md with mandatory related document links
+9. /rules-workflow → Implement each backlog item only after reading linked docs and passing UI-First and Component & Library gates
+10. /verify-implementation  → Audit docs, UI, code, security, performance, DB, and skill package changes
 ```
 
 Backlog items are intentionally document-linked. Each task in `docs/04_Logic_Progress/00_BACKLOG.md` must include related Concept, UI, Technical Spec, and QA documents, plus implementation preconditions, acceptance criteria, and a document sync check. If a related document does not exist, the item must say `N/A - 사유`; implementation should pause when the missing document is required for a safe decision.
@@ -260,6 +272,10 @@ docs/02_UI_Screens/previews/02_dashboard_preview.html
 
 Each related UI document must link to the HTML file with a relative path. The preview must be shown to the user before implementation, and feedback must be captured in `XX_PROTOTYPE_REVIEW.md`, `00_SCREEN_FLOW.md`, `01_UI_DESIGN.md`, or the related backlog item.
 
+### Component & Library Planning Gate
+
+React implementation should not begin until the team has listed the UI building blocks and library choices. Record the shadcn/ui components to add, custom components to create, existing components to reuse, libraries to install, libraries intentionally not added, and whether the project needs `init --preset`, `apply --preset`, `apply --only theme`, or `N/A - reason`.
+
 Required fields for every backlog item:
 
 - `Related Concept Docs`
@@ -268,6 +284,7 @@ Required fields for every backlog item:
 - `Related Technical Docs`
 - `Related QA Docs`
 - `Implementation Preconditions`
+- `Component & Library Plan`
 - `Acceptance Criteria`
 - `Document Sync Check`
 
@@ -296,6 +313,13 @@ If a related document does not exist, write `N/A - 사유`. Do not leave the fie
   - [ ] Confirm user path and screen-by-screen data flow
   - [ ] Confirm loading, empty, and error states
   - [ ] Confirm implementation scope does not conflict with documented intent
+- Component & Library Plan:
+  - shadcn/ui components: button, card, form, or `N/A - reason`
+  - Custom components: feature-specific components or `N/A - reason`
+  - Reused components: existing paths or `N/A - reason`
+  - New libraries: package names and reasons or `N/A - reason`
+  - Libraries intentionally not added: rejected options and reasons or `N/A - reason`
+  - shadcn preset action: init --preset / apply --preset / apply --only theme / N/A - reason
 - Acceptance Criteria:
   - [ ] Feature follows the confirmed screen structure and user path
   - [ ] Feature behavior matches linked Concept/UI/Technical docs

package/docs-dev/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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. Enforces backlog links to Concept/UI/HTML Preview/Technical/QA docs before implementation. Always read existing files before editing.
+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, component/library plans, roadmaps, backlogs, business logic designs, or test scenarios. Enforces backlog links to Concept/UI/HTML Preview/Technical/QA docs before implementation. Always read existing files before editing.
 ---
 
 # Development Documentation Skill
@@ -64,11 +64,13 @@ This skill manages **Layer 3 (Technical_Specs)**, **Layer 4 (Logic_Progress)**,
 
 **Pre-Code Technical Brief 강제 규칙**: UI 확인 후에도 바로 구현하지 않는다. 데이터 소스, 최소 필드, mutation, 상태 관리 방식, acceptance criteria가 백로그나 기술 문서에 기록되어야 한다. 불명확하면 `docs/03_Technical_Specs/` 문서 또는 백로그 항목을 먼저 보완한다.
 
+**Component & Library Planning Gate 강제 규칙**: React 구현 전에 사용할 컴포넌트와 라이브러리를 정리한다. shadcn/ui 컴포넌트, 직접 만들 커스텀 컴포넌트, 재사용할 기존 컴포넌트, 새로 설치할 라이브러리, 설치하지 않을 라이브러리, shadcn `init`/`apply` 적용 여부가 백로그나 기술 문서에 기록되어야 한다. 불명확하면 `tools-shadcn`, `rules-react`, `docs/03_Technical_Specs/` 문서 또는 백로그 항목을 먼저 보완한다.
+
 Backlog 항목 작성 전 필수 확인 대상:
 - `docs/01_Concept_Design/`: 기능 목적, 사용자 가치, 제품 방향
 - `docs/02_UI_Screens/`: 화면 흐름, UI 상태, 인터랙션
 - `docs/02_UI_Screens/previews/`: 사용자에게 보여줄 HTML UI Preview
-- `docs/03_Technical_Specs/`: API, DB, 데이터 구조, 기술 제약
+- `docs/03_Technical_Specs/`: API, DB, 데이터 구조, 기술 제약, Component & Library Plan, shadcn 설정, UI 라이브러리 선택
 - `docs/05_QA_Validation/`: 테스트 기준, 수용 조건, 검증 시나리오
 
 각 Backlog 항목은 다음 필드를 반드시 포함한다:
@@ -78,6 +80,7 @@ Backlog 항목 작성 전 필수 확인 대상:
 - `Related Technical Docs`: 관련 기술 명세 문서
 - `Related QA Docs`: 관련 검증 문서
 - `Implementation Preconditions`: 구현 전 반드시 확인할 조건
+- `Component & Library Plan`: 사용할 컴포넌트·라이브러리·shadcn preset 적용 계획
 - `Acceptance Criteria`: 완료 판단 기준
 - `Document Sync Check`: 구현 후 문서와 코드의 일치 여부
 
@@ -91,14 +94,19 @@ Backlog 항목 작성 전 필수 확인 대상:
 - 화면별 입력·출력 데이터와 상태 변화를 확인했는가?
 - 로딩·빈 상태·오류 상태가 UI 문서나 백로그에 반영되어 있는가?
 - 데이터 소스, 최소 필드, mutation, 상태 관리 방식이 정리되었는가?
+- 사용할 shadcn/ui 컴포넌트, 커스텀 컴포넌트, 기존 재사용 컴포넌트가 정리되었는가?
+- 새 라이브러리와 설치하지 않을 라이브러리의 이유가 정리되었는가?
+- shadcn `init --preset`, `apply --preset`, 또는 `apply --only theme` 적용 여부가 정리되었는가?
 - acceptance criteria가 사용자 시나리오 기준으로 검증 가능한가?
 - 구현 범위가 관련 문서의 의도와 충돌하지 않는가?
 - 관련 QA 기준이 `Acceptance Criteria`에 반영되어 있는가?
 - 누락된 문서가 있다면 `N/A - 사유`가 타당한가?
 
-1. **Project Initialization**: CLI 프리셋 vs 수동 설정?
-2. **UI Theme Strategy**: 사전 정의된 테마 vs 커스텀 브랜드 색상? 폰트 선택?
-3. **Folder Structure**: Feature 기반 vs Type 기반?
+1. **Project Initialization**: CLI 프리셋 vs 수동 설정? 신규 프로젝트는 `init --preset`, 기존 프로젝트는 `apply --preset`인가?
+2. **UI Theme Strategy**: 사전 정의된 테마 vs 커스텀 브랜드 색상? 폰트 선택? 기존 프로젝트는 `--only theme`로 충분한가?
+3. **Component Plan**: shadcn/ui로 가져올 컴포넌트는? 직접 만들 커스텀 컴포넌트는? 기존 재사용 컴포넌트는?
+4. **Library Plan**: 새로 설치할 라이브러리와 설치하지 않을 라이브러리는? 상태/폼/검증/toast/table/date 선택은?
+5. **Folder Structure**: Feature 기반 vs Type 기반?
 
 ### Dev Phase (DEVELOPMENT_PRINCIPLES 작성/갱신 시 필수)
 
@@ -206,11 +214,20 @@ Backlog 항목 작성 전 필수 확인 대상:
   - [ ] 로딩·빈 상태·오류 상태 확인 완료
   - [ ] 데이터 소스와 최소 필드 확인 완료
   - [ ] mutation 및 상태 관리 방식 확인 완료
+  - [ ] Component & Library Planning Gate 확인 완료
   - [ ] 구현 범위와 문서 요구사항 충돌 없음
+- Component & Library Plan:
+  - shadcn/ui components: [button, card 등 / N/A - 사유]
+  - Custom components: [FeatureCard 등 / N/A - 사유]
+  - Reused components: [기존 경로 / N/A - 사유]
+  - New libraries: [패키지명 및 이유 / N/A - 사유]
+  - Libraries intentionally not added: [제외한 후보와 이유 / N/A - 사유]
+  - shadcn preset action: init --preset / apply --preset / apply --only theme / N/A - 사유
 - Acceptance Criteria:
   - [ ] 구현 결과가 확인된 화면 구조와 사용자 동선을 따른다
   - [ ] 구현 결과가 HTML UI Preview와 의도 없이 불일치하지 않는다
   - [ ] 데이터 흐름과 상태 변화가 Pre-Code Technical Brief와 일치한다
+  - [ ] 컴포넌트와 라이브러리 선택이 Component & Library Plan과 일치한다
   - [ ] QA 기준이 구현 완료 판단에 반영됨
   - [ ] 핵심 사용자 흐름이 검증됨
 - Document Sync Check:

package/manage-skills/SKILL.md

@@ -28,7 +28,7 @@ argument-hint: "[선택사항: 특정 스킬 이름 또는 집중할 영역]"
 
 | 스킬 | 설명 | 커버 파일 패턴 |
 |------|------|---------------|
-| `verify-docs` | 문서 구조, Backlog Context Lock, UI-First Gate | `docs/**/*.md`, `README.md`, `AGENTS.md` |
+| `verify-docs` | 문서 구조, Backlog Context Lock, UI-First Gate, Component & Library Planning Gate | `docs/**/*.md`, `README.md`, `AGENTS.md` |
 | `verify-ui` | 화면 구현과 UI 문서, 사용자 동선, 상태별 UI 정합성 | `src/**/*.tsx`, `src/**/*.jsx`, `docs/02_UI_Screens/**/*.md` |
 | `verify-code` | 코드 품질, 타입, 로직, 사이드 이펙트 | `src/**/*.{ts,tsx,js,jsx}` |
 | `verify-security` | 인증·인가·입력·시크릿·OWASP 보안 | `auth`, `api`, `route`, `middleware`, `.env`, `db` 관련 파일 |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "solmate-skills",
-  "version": "2.0.10",
+  "version": "2.0.11",
   "description": "AI workflow skills for UI-first planning, YAGNI/KISS/DRY gates, docs, QA, and Solmate projects",
   "main": "bin/cli.js",
   "bin": {

package/rules-product/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: rules-product
-description: Orchestrates the full product development pipeline from planning to development docs. Diagnoses current project phase, checks gate conditions including HTML UI Preview Gate and UI-First Gate, and delegates to the correct sub-skill at each step. Use this as the entry point for new projects or when resuming work mid-flow.
+description: Orchestrates the full product development pipeline from planning to development docs. Diagnoses current project phase, checks gate conditions including HTML UI Preview Gate, UI-First Gate, and Component & Library Planning Gate, and delegates to the correct sub-skill at each step. Use this as the entry point for new projects or when resuming work mid-flow.
 ---
 
 # Product Workflow Orchestrator
@@ -15,6 +15,7 @@ Phase 2: UI 설계 문서   → docs-plan (UI_Screens)
 HTML UI Preview Gate: 브라우저 확인용 화면 제작·링크·피드백
 UI-First Gate: 화면·동선·데이터 흐름 확인
 Pre-Code Technical Brief: 데이터·API·상태 최소 합의
+Component & Library Planning Gate: 컴포넌트·라이브러리·shadcn 적용 계획
 Phase 3: React 변환     → rules-react
 Phase 4: 개발문서       → docs-dev
 Phase 5: 품질 검증      → verify-implementation (verify-docs / verify-code / verify-security / verify-performance)
@@ -36,6 +37,7 @@ Run these checks in order:
 | HTML UI Preview 확인 여부 | 없으면 Phase 3 진입 보류 | 브라우저 확인용 화면 필요 |
 | UI-First Gate 확인 여부 | 없으면 Phase 3 진입 보류 | 화면·동선·데이터 흐름 확인 필요 |
 | Pre-Code Technical Brief 여부 | 없으면 Phase 3 진입 보류 | 최소 기술 합의 필요 |
+| Component & Library Plan 여부 | 없으면 Phase 3 진입 보류 | 컴포넌트·라이브러리 선택 필요 |
 | `src/components/` 또는 React 코드 존재 여부 | 없으면 Phase 3 미완 | React 개발 필요 |
 | `docs/03_Technical_Specs/` 존재 여부 | 없으면 Phase 4 미완 | 개발문서 필요 |
 | verify-* 스킬 실행 이력 또는 사용자 확인 여부 | 없으면 Phase 5 미완 | 품질 검증 필요 |
@@ -212,7 +214,36 @@ UI-First Gate 보고에는 `Flow Status Block`을 포함하고, 다음 위치가
 - [ ] 기술 문서가 아직 없으면 백로그의 `Implementation Preconditions` 또는 `Acceptance Criteria`에 최소 계약이 기록됨
 - [ ] 구현자가 mock data 구조와 실제 데이터 전환 방식을 설명할 수 있음
 
-Pre-Code Technical Brief 보고에는 `Flow Status Block`을 포함하고, 다음 위치가 `Phase 3 — React 변환`임을 명시한다.
+Pre-Code Technical Brief 보고에는 `Flow Status Block`을 포함하고, 다음 위치가 `Component & Library Planning Gate`임을 명시한다.
+
+---
+
+## Component & Library Planning Gate: 컴포넌트·라이브러리 적용 계획
+
+**목표**: React 구현 전에 사용할 컴포넌트와 라이브러리를 정리해, UI 구현자가 임의로 패키지를 설치하거나 중복 컴포넌트를 만들지 않도록 한다. 이 게이트를 통과하기 전에는 Phase 3 구현을 시작하지 않는다.
+
+**필수 확인 항목**:
+- [ ] 화면별 사용할 shadcn/ui 컴포넌트 목록
+- [ ] 직접 만들 커스텀 컴포넌트와 재사용할 기존 컴포넌트 목록
+- [ ] 새로 설치할 라이브러리와 설치하지 않을 라이브러리의 이유
+- [ ] 상태 관리, 폼, 검증, toast, table, date/time 등 UI 주변 라이브러리 선택
+- [ ] shadcn 초기화 상태: 신규 프로젝트는 `init --preset`, 기존 프로젝트는 `apply --preset` 또는 `--only theme` 적용 여부
+- [ ] 새 의존성이 `rules-dev`의 Minimal Implementation Gate를 통과하는 이유
+
+**Gate Out**:
+- [ ] `docs/03_Technical_Specs/` 문서, 백로그 항목, 또는 Pre-Code Technical Brief에 Component & Library Plan이 기록됨
+- [ ] `tools-shadcn`이 필요한 경우 적용 명령과 대상 범위가 기록됨
+- [ ] 구현자가 새 컴포넌트·새 라이브러리·shadcn preset 적용 여부를 설명할 수 있음
+
+**위임 지시**:
+
+```
+사용할 스킬: tools-shadcn + rules-react
+입력: docs/02_UI_Screens/ 화면 설계, Pre-Code Technical Brief, 기존 components.json 및 package.json
+출력: Component & Library Plan
+```
+
+Component & Library Planning Gate 보고에는 `Flow Status Block`을 포함하고, 다음 위치가 `Phase 3 — React 변환`임을 명시한다.
 
 ---
 
@@ -226,6 +257,7 @@ Pre-Code Technical Brief 보고에는 `Flow Status Block`을 포함하고, 다
 - UI-First Gate 통과
 - 화면·동선·데이터 흐름 확인 결과가 백로그 또는 UI 문서에 반영됨
 - Pre-Code Technical Brief 통과
+- Component & Library Planning Gate 통과
 
 **Gate Out** (다음 단계 진입 조건):
 - [ ] `src/components/` 에 주요 컴포넌트 존재
@@ -235,8 +267,8 @@ Pre-Code Technical Brief 보고에는 `Flow Status Block`을 포함하고, 다
 **위임 지시**:
 
 ```
-사용할 스킬: rules-react
-입력: docs/02_UI_Screens/ 의 화면 설계 및 디자인 가이드
+사용할 스킬: rules-react + tools-shadcn
+입력: docs/02_UI_Screens/ 의 화면 설계 및 디자인 가이드, Component & Library Plan
 순서: 화면 중요도 순으로 처리 (홈 → 주요 기능 화면 → 기타)
 ```
 
@@ -335,7 +367,7 @@ Phase 5 검증 보고에는 `Flow Status Block`을 포함하고, Fail이 있으
 [Flow]
 현재: Phase 6 — 최종 전달물 또는 Handoff
 Gate: 완료
-완료: Phase 1, Phase 2, UI-First Gate, Pre-Code Technical Brief, Phase 3, Phase 4, Phase 5
+완료: Phase 1, Phase 2, HTML UI Preview Gate, UI-First Gate, Pre-Code Technical Brief, Component & Library Planning Gate, Phase 3, Phase 4, Phase 5
 다음: 사용자 선택 후속 작업
 필요 확인: 남은 TODO 또는 없음
 권장 스킬: /docs-pitch 또는 /docs-business (선택)
@@ -343,6 +375,7 @@ Gate: 완료
 전체 워크플로우 완료
 - Phase 1: docs/01_Concept_Design/        기획문서
 - Phase 2: docs/02_UI_Screens/            UI 설계 문서
+- Gates: HTML UI Preview, UI-First, Pre-Code Technical Brief, Component & Library Planning 완료
 - Phase 3: src/components/               React 컴포넌트
 - Phase 4: docs/03~05_*/                 개발·진행·QA 문서
 - Phase 5: verify-implementation PASS    품질 검증 완료
@@ -355,7 +388,7 @@ Phase 6이 선택 사항이어도, 작업을 마무리할 때는 아래 항목
 
 - [ ] 현재 Phase와 완료된 Phase 목록
 - [ ] 구현 또는 문서 산출물 경로
-- [ ] UI-First Gate와 Pre-Code Technical Brief 충족 여부
+- [ ] HTML UI Preview, UI-First Gate, Pre-Code Technical Brief, Component & Library Planning Gate 충족 여부
 - [ ] 실행한 verify 스킬과 결과
 - [ ] 배포 URL 또는 로컬 실행 방법 (해당 시)
 - [ ] 남은 TODO, Known Issue, 문서-구현 불일치 여부

package/rules-react/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: rules-react
-description: Create modular, premium React components and pages based on UI design systems (docs-plan Layer 2). Applies best practices (Vercel) and ensures consistency with rules-dev. Use when implementing UI screens or refactoring existing components.
+description: Create modular, premium React components and pages based on UI design systems (docs-plan Layer 2) and Component & Library Plans. Applies best practices (Vercel) and ensures consistency with rules-dev. Use when implementing UI screens or refactoring existing components.
 ---
 
 # React Component Implementation Skill
@@ -10,6 +10,7 @@ You are a senior frontend engineer focused on transforming UI designs into clean
 ## 1. Input Sources
 - **docs-plan Layer 2**: Read `docs/02_UI_Screens/00_SCREEN_FLOW.md`, `01_UI_DESIGN.md`, and relevant `XX_PROTOTYPE_REVIEW.md` files before coding.
 - **UI-First Gate**: Confirm screen structure, user path, data flow, and loading/empty/error states before writing React code.
+- **Component & Library Planning Gate**: Read the backlog or technical spec entry that lists shadcn/ui components, custom components, reused components, new libraries, and libraries intentionally not added.
 - **rules-dev**: Follow coding standards, file naming, and state management rules.
 - **Vercel Best Practices**: Follow the provided skills for performance and composition patterns.
 
@@ -24,11 +25,12 @@ You are a senior frontend engineer focused on transforming UI designs into clean
 ## 3. Execution steps
 1. **Analyze Screens First**: Read the UI Screens documentation and confirm the target screens, user paths, CTA behavior, and responsive differences.
 2. **Map Data Flow**: Identify each screen's inputs, displayed data, mutations, and loading/empty/error states.
-3. **Confirm Before Code**: If screen flow or state coverage is missing, pause implementation and request `docs-plan` or `docs-dev` updates.
-4. **Draft Logic**: Decide on state management and hook structure.
-5. **Data layer**: Prepare mock data or data fetching logic.
-6. **Implement UI**: Build components starting from the most granular (atoms) to full pages.
-7. **Quality check**:
+3. **Confirm Component & Library Plan**: Decide which shadcn/ui components to add, which custom components to create, which existing components to reuse, and which libraries to avoid.
+4. **Confirm Before Code**: If screen flow, state coverage, or component/library planning is missing, pause implementation and request `docs-plan`, `docs-dev`, or `tools-shadcn` updates.
+5. **Draft Logic**: Decide on state management and hook structure.
+6. **Data layer**: Prepare mock data or data fetching logic.
+7. **Implement UI**: Build components starting from the most granular (atoms) to full pages.
+8. **Quality check**:
     - Verify against accessibility standards.
     - Check performance (avoid unnecessary re-renders).
     - Ensure responsive design works across all target devices.
@@ -38,5 +40,6 @@ You are a senior frontend engineer focused on transforming UI designs into clean
 - **docs-plan**: Source for UI design and screen flows.
 - **rules-dev**: Development standards and conventions.
 - **docs-dev**: Technical specs and backend integration details.
+- **tools-shadcn**: shadcn/ui component discovery, preset init/apply guidance, and component installation.
 - **vercel-react-best-practices**: Performance optimization.
 - **vercel-composition-patterns**: Reusable component architecture.

package/rules-workflow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: rules-workflow
-description: Guides the full implementation lifecycle from planning through PR. Use when implementing a new feature, planning implementation, before committing or creating a PR, avoiding overengineering, or following the 18-step workflow. Requires product phase preflight, HTML UI Preview Gate, UI-First Gate, Backlog Context Lock, YAGNI/KISS/DRY minimal implementation checks, implementation quality checks, and deployment readiness.
+description: Guides the full implementation lifecycle from planning through PR. Use when implementing a new feature, planning implementation, before committing or creating a PR, avoiding overengineering, or following the 18-step workflow. Requires product phase preflight, HTML UI Preview Gate, UI-First Gate, Component & Library Planning Gate, Backlog Context Lock, YAGNI/KISS/DRY minimal implementation checks, implementation quality checks, and deployment readiness.
 ---
 
 # Implementation & Execution Workflow (18 Steps)
@@ -11,9 +11,9 @@ Follow this workflow for feature implementation and significant code changes. Co
 
 ## Step 0: Product Phase Preflight
 
-기능 구현을 시작하기 전, 먼저 `rules-product` 기준으로 현재 프로젝트 Phase를 진단한다. Concept, UI, HTML UI Preview Gate, UI-First Gate, Pre-Code Technical Brief 중 하나라도 누락되어 구현 판단이 불안정하면 코딩을 시작하지 않고 해당 문서·백로그·계획 보완을 제안한다. YAGNI/KISS/DRY는 독립 게이트로 늘리지 않고 Step 4의 최소 구현 검토에서 확인한다.
+기능 구현을 시작하기 전, 먼저 `rules-product` 기준으로 현재 프로젝트 Phase를 진단한다. Concept, UI, HTML UI Preview Gate, UI-First Gate, Pre-Code Technical Brief, Component & Library Planning Gate 중 하나라도 누락되어 구현 판단이 불안정하면 코딩을 시작하지 않고 해당 문서·백로그·계획 보완을 제안한다. YAGNI/KISS/DRY는 독립 게이트로 늘리지 않고 Step 4의 최소 구현 검토에서 확인한다.
 
-- 체크: [ ] 현재 Phase를 진단했는가? [ ] HTML UI Preview Gate가 충족되었는가? [ ] UI-First Gate가 충족되었는가? [ ] 최소 기술 계약이 확인되었는가?
+- 체크: [ ] 현재 Phase를 진단했는가? [ ] HTML UI Preview Gate가 충족되었는가? [ ] UI-First Gate가 충족되었는가? [ ] 최소 기술 계약이 확인되었는가? [ ] Component & Library Plan이 확인되었는가?
 
 진단 결과는 `rules-product`의 `Flow Status Block` 형식으로 먼저 보고한다. 구현 단계 중 사용자가 "지금 어디야?", "다음 뭐야?", "현재 단계가 뭐야?"라고 묻거나 Phase 1-6 경계에 도달하면 같은 형식을 다시 출력한다.
 
@@ -27,9 +27,10 @@ Follow this workflow for feature implementation and significant code changes. Co
 - 코드 작성보다 먼저 HTML UI Preview Gate를 확인한다. `docs/02_UI_Screens/previews/`의 HTML Preview가 없거나 UI 문서에 링크되지 않았거나 사용자 확인 기록이 없으면 구현 계획을 보류하고 `docs-plan` 문서/HTML 보완을 제안한다.
 - 그 다음 UI-First Gate를 확인한다. 화면 구조, 사용자 동선, 데이터 흐름, 로딩·빈 상태·오류 상태가 문서화되지 않았으면 구현 계획을 보류하고 `docs-plan` 또는 `docs-dev` 문서 보완을 제안한다.
 - Pre-Code Technical Brief를 확인한다. 데이터 소스, 최소 필드, mutation, 상태 관리 방식, acceptance criteria가 불명확하면 구현 전에 사용자와 합의한다.
+- Component & Library Planning Gate를 확인한다. 사용할 shadcn/ui 컴포넌트, 커스텀 컴포넌트, 기존 재사용 컴포넌트, 새 라이브러리, 설치하지 않을 라이브러리, shadcn `init`/`apply` 적용 여부가 불명확하면 구현 전에 `tools-shadcn`, `rules-react`, `docs-dev` 보완을 제안한다.
 - Step 4에서 `rules-dev`의 Minimal Implementation Gate 정본을 기준으로 과잉 구현 후보를 확인한다.
 - 변경할 파일·추가할 컴포넌트·API·DB 영향 범위를 나열한다.
-- 체크: [ ] 목적이 명확한가? [ ] 관련 문서를 읽었는가? [ ] HTML UI Preview를 확인했는가? [ ] UI-First Gate가 확인되었는가? [ ] 최소 기술 계약이 확인되었는가? [ ] 영향 범위가 정리되었는가?
+- 체크: [ ] 목적이 명확한가? [ ] 관련 문서를 읽었는가? [ ] HTML UI Preview를 확인했는가? [ ] UI-First Gate가 확인되었는가? [ ] 최소 기술 계약이 확인되었는가? [ ] Component & Library Plan이 확인되었는가? [ ] 영향 범위가 정리되었는가?
 
 ### Step 2. 계획 검토
 - 계획이 요구사항과 일치하는지, 누락된 시나리오는 없는지 검토한다.
@@ -54,9 +55,10 @@ Follow this workflow for feature implementation and significant code changes. Co
 - 코드 작성 전 백로그 항목의 `Implementation Preconditions`와 `Acceptance Criteria`를 확인한다. 관련 문서 링크가 비어 있거나 `N/A - 사유`가 부실하면 구현을 보류하고 문서 보완 필요 여부를 사용자에게 확인한다.
 - HTML UI Preview Gate가 통과되지 않았거나 사용자가 HTML Preview를 확인하지 않았다면 구현을 시작하지 않는다.
 - UI-First Gate가 통과되지 않았거나 사용자가 화면/UI를 먼저 확인하지 않았다면 구현을 시작하지 않는다.
+- Component & Library Planning Gate가 통과되지 않았다면 구현을 시작하지 않는다. 새 컴포넌트·새 라이브러리·shadcn preset 적용이 필요하면 현재 화면과 acceptance criteria 기준의 근거를 먼저 설명한다.
 - 비프로토타입 작업에서 `rules-dev`의 Minimal Implementation Gate를 통과하지 못했다면 구현을 시작하지 않는다. 새 추상화·새 의존성·새 설정이 필요하면 현재 요구사항 근거를 먼저 설명한다.
 - 구현을 시작하기 직전에 `Flow Status Block`을 출력하고, 현재 위치가 `Phase 3 — React 변환` 또는 해당 기능 구현 단계인지 명시한다.
-- 체크: [ ] 계획 대비 변경 사항이 일치하는가? [ ] 백로그의 관련 문서 기준을 반영했는가? [ ] HTML Preview 확인 후 구현했는가? [ ] 화면·동선·데이터 흐름 확인 후 구현했는가? [ ] 최소 구현 원칙을 지켰는가?
+- 체크: [ ] 계획 대비 변경 사항이 일치하는가? [ ] 백로그의 관련 문서 기준을 반영했는가? [ ] HTML Preview 확인 후 구현했는가? [ ] 화면·동선·데이터 흐름 확인 후 구현했는가? [ ] Component & Library Plan을 반영했는가? [ ] 최소 구현 원칙을 지켰는가?
 
 ---
 
@@ -79,7 +81,7 @@ Follow this workflow for feature implementation and significant code changes. Co
 - 체크: [ ] 한 파일/함수가 과도하게 길지 않은가? [ ] 분할 시 재사용·테스트 용이성
 
 ### Step 10. 기존 코드 통합·재사용 검토
-- 새로 작성한 부분과 기존 코드의 통합 지점을 확인한다. 재사용 가능한 컴포넌트·유틸이 있으면 활용했는지 검토한다.
+- 새로 작성한 부분과 기존 코드의 통합 지점을 확인한다. Component & Library Plan 기준으로 재사용 가능한 컴포넌트·유틸·라이브러리를 활용했는지 검토한다.
 - DRY 기준은 `rules-dev`의 Minimal Implementation Gate 정본을 따른다.
 - 체크: [ ] 중복 구현 없음 [ ] 기존 패턴·API와 정합성 [ ] premature abstraction 없음
 

package/tools-shadcn/README.md

@@ -101,7 +101,7 @@ Your project should have:
 # Create Next.js project with shadcn/ui
 npx create-next-app@latest my-app
 cd my-app
-npx shadcn@latest init
+npx shadcn@latest init --preset b1Z5aAfsu --template next --monorepo --rtl --pointer
 
 # Add components
 npx shadcn@latest add button
@@ -111,10 +111,13 @@ npx shadcn@latest add card
 ### For Existing Projects
 
 ```bash
-# Initialize shadcn/ui
-npx shadcn@latest init
+# Initialize shadcn/ui for a Next.js monorepo
+npx shadcn@latest init --preset b1Z5aAfsu --template next --monorepo --rtl --pointer
 
-# Configure when prompted:
+# If components.json already exists, inspect the existing config before rerunning init.
+# For non-Next or non-monorepo projects, use: npx shadcn@latest init
+
+# If using the standard interactive init, configure when prompted:
 # - Choose style (default/new-york)
 # - Select base color
 # - Configure CSS variables

package/tools-shadcn/SKILL.md

@@ -70,7 +70,33 @@ For **new projects**, use the `create` command to customize everything (style, f
 npx shadcn@latest create
 ```
 
-For **existing projects**, initialize configuration:
+### Solmate Default Init Command
+
+For Next.js monorepo projects, use this command by default when shadcn/ui has not been initialized yet:
+
+```bash
+npx shadcn@latest init --preset b1Z5aAfsu --template next --monorepo --rtl --pointer
+```
+
+Before running it in an existing project, check whether `components.json` already exists. If it exists, do not rerun init blindly; inspect the existing aliases, style, Tailwind paths, RTL setting, and pointer behavior first.
+
+Use a framework-specific init only when the project is not Next.js, is not a monorepo, or the user explicitly opts out of RTL or pointer behavior.
+
+For existing projects that already have shadcn/ui initialized, prefer applying the preset instead of rerunning init:
+
+```bash
+npx shadcn@latest apply --preset b1Z5aAfsu
+```
+
+For mature projects where broad visual changes are risky, apply only the theme first:
+
+```bash
+npx shadcn@latest apply --preset b1Z5aAfsu --only theme
+```
+
+Before applying a preset, inspect `git status`, `components.json`, and the current component/theme setup. Record the selected command in the Component & Library Plan.
+
+For **existing non-Next projects**, initialize configuration with the standard interactive command:
 
 ```bash
 npx shadcn@latest init

package/tools-shadcn/resources/setup-guide.md

@@ -35,8 +35,8 @@ This interactive command will guide you through:
 npx create-next-app@latest my-app
 cd my-app
 
-# Initialize shadcn/ui
-npx shadcn@latest init
+# Initialize shadcn/ui with the Solmate default preset
+npx shadcn@latest init --preset b1Z5aAfsu --template next --monorepo --rtl --pointer
 
 # Add your first component
 npx shadcn@latest add button
@@ -90,13 +90,21 @@ export default {
 
 ### Step 2: Initialize shadcn/ui
 
-Run the initialization command:
+For Next.js monorepo projects, use the Solmate default initialization command:
+
+```bash
+npx shadcn@latest init --preset b1Z5aAfsu --template next --monorepo --rtl --pointer
+```
+
+Before running it in an existing project, check for `components.json`. If the file already exists, do not rerun init blindly; inspect the current aliases, Tailwind paths, style, RTL setting, and pointer behavior first.
+
+For non-Next projects, projects that are not monorepos, or projects that explicitly opt out of RTL or pointer behavior, use the standard interactive command instead:
 
 ```bash
 npx shadcn@latest init
 ```
 
-You'll be asked to configure:
+When using the standard interactive init, you'll be asked to configure:
 
 1. **Style**: Choose between `default`, `new-york`, or one of the new styles (Vega, Nova, etc.)
    - `default`: Clean and minimal design

package/tools-shadcn/scripts/verify-setup.sh

@@ -17,7 +17,8 @@ if [ -f "components.json" ]; then
     echo -e "${GREEN}✓${NC} components.json found"
 else
     echo -e "${RED}✗${NC} components.json not found"
-    echo -e "  ${YELLOW}Run:${NC} npx shadcn@latest init"
+    echo -e "  ${YELLOW}Run for Next.js monorepos:${NC} npx shadcn@latest init --preset b1Z5aAfsu --template next --monorepo --rtl --pointer"
+    echo -e "  ${YELLOW}Run for other projects:${NC} npx shadcn@latest init"
     exit 1
 fi
 

package/verify-code/SKILL.md

@@ -55,9 +55,8 @@ git diff --name-only HEAD
 
 ## Area 3: YAGNI/KISS/DRY 및 과잉 구현
 
-- `rules-dev`의 `Minimal Implementation Gate (YAGNI / KISS / DRY)` 정본을 기준으로 변경된 코드를 검토한다.
-- 현재 요구사항에 없는 미래용 코드, 단일 구현체 추상화, 피할 수 있는 새 의존성, premature abstraction을 발견하면 아래 태그로 보고한다.
-- 프로토타입·스파이크·탐색 단계의 코드는 정보성으로 표시하되, 검증·보안·에러 처리·접근성·데이터 보존 관련 안전 예외 위반은 Fail로 처리한다.
+- 판정 기준(금지 항목, 프로토타입·스파이크 예외, 안전 예외)은 `rules-dev`의 `Minimal Implementation Gate (YAGNI / KISS / DRY)` 정본을 그대로 따른다. 이 영역은 정본을 변경된 코드에 적용해 태그로 보고하는 역할만 한다.
+- 정본 기준 위반을 발견하면 아래 태그로 보고한다. (DRY 중복·재사용은 Area 4에서 함께 다룬다.)
 - 태그:
   - `delete`: 요구사항에 없는 코드이므로 제거 권장
   - `stdlib`: 표준 라이브러리로 대체 권장
@@ -65,9 +64,9 @@ git diff --name-only HEAD
   - `yagni`: 미래 가능성만 근거인 기능·추상화
   - `shrink`: 더 작은 구현으로 축소 권장
 - 체크:
-  - [ ] `rules-dev` 정본 기준으로 과잉 구현이 없는가?
-  - [ ] 프로토타입·스파이크 예외 적용 여부가 명확한가?
-  - [ ] 안전 예외 위반이 없는가?
+  - [ ] 정본 기준으로 과잉 구현이 없는가?
+  - [ ] 정본의 프로토타입·스파이크 예외 적용 여부가 명확한가?
+  - [ ] 정본의 안전 예외 위반이 없는가?
 
 ---
 

package/verify-docs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: verify-docs
-description: 프로젝트 문서가 5단계 구조(01~05), 메타데이터, Related Documents, Backlog Context Lock, HTML UI Preview Gate, UI-First Gate를 준수하는지 검증합니다. 문서 생성/수정 후, PR 전 사용.
+description: 프로젝트 문서가 5단계 구조(01~05), 메타데이터, Related Documents, Backlog Context Lock, HTML UI Preview Gate, UI-First Gate, Component & Library Planning Gate를 준수하는지 검증합니다. 문서 생성/수정 후, PR 전 사용.
 ---
 
 # 문서 구조 검증
@@ -15,8 +15,9 @@ description: 프로젝트 문서가 5단계 구조(01~05), 메타데이터, Rela
 5. HTML UI Preview Gate
 6. UI-First Gate
 7. Pre-Code Technical Brief
-8. Rubric-First Writing
-9. rules-product Gate Out 조건
+8. Component & Library Planning Gate
+9. Rubric-First Writing
+10. rules-product Gate Out 조건
 
 ## 실행 시점
 
@@ -69,6 +70,7 @@ AGENTS.md 또는 `docs/01_Concept_Design/00_COLLABORATION_GUIDE.md`를 읽어
 - [ ] 각 작업 항목에 `Related Technical Docs`가 있는가?
 - [ ] 각 작업 항목에 `Related QA Docs`가 있는가?
 - [ ] 각 작업 항목에 `Implementation Preconditions`가 있는가?
+- [ ] 각 작업 항목에 `Component & Library Plan`이 있는가?
 - [ ] 각 작업 항목에 `Acceptance Criteria`가 있는가?
 - [ ] 각 작업 항목에 `Document Sync Check`가 있는가?
 - [ ] Related 필드의 링크가 상대 경로이거나 `N/A - 사유` 형식인가?
@@ -77,6 +79,7 @@ AGENTS.md 또는 `docs/01_Concept_Design/00_COLLABORATION_GUIDE.md`를 읽어
 - [ ] `Implementation Preconditions`에 HTML Preview 사용자 확인 및 피드백 기록이 포함되어 있는가?
 - [ ] `Implementation Preconditions`에 화면/UI 선확인, 사용자 동선 확인, 데이터 흐름 확인, 로딩·빈 상태·오류 상태 확인이 포함되어 있는가?
 - [ ] `Implementation Preconditions` 또는 `Acceptance Criteria`에 데이터 소스, 최소 필드, mutation, 상태 관리 방식, 검증 가능한 acceptance criteria가 포함되어 있는가?
+- [ ] `Component & Library Plan`에 shadcn/ui 컴포넌트, 커스텀 컴포넌트, 재사용 컴포넌트, 새 라이브러리, 제외한 라이브러리, shadcn preset 적용 여부가 포함되어 있는가?
 
 위 항목 중 하나라도 누락되면 Backlog Context Lock은 Fail로 처리한다.
 
@@ -119,7 +122,20 @@ HTML Preview가 없거나 링크·사용자 확인 기록이 누락되면 HTML U
 
 데이터·API·상태 계약이 없어 구현자가 임의 구조를 만들 수밖에 없으면 Pre-Code Technical Brief는 Fail로 처리한다.
 
-### Step 8: Rubric-First Writing 검사
+### Step 8: Component & Library Planning Gate 검사
+
+`docs/03_Technical_Specs/`와 `docs/04_Logic_Progress/00_BACKLOG.md`를 함께 확인한다.
+
+체크 항목:
+- [ ] 사용할 shadcn/ui 컴포넌트 목록이 있는가?
+- [ ] 직접 만들 커스텀 컴포넌트와 재사용할 기존 컴포넌트 목록이 있는가?
+- [ ] 새로 설치할 라이브러리와 설치하지 않을 라이브러리의 이유가 있는가?
+- [ ] 상태 관리, 폼, 검증, toast, table, date/time 등 UI 주변 라이브러리 선택이 있는가?
+- [ ] shadcn `init --preset`, `apply --preset`, `apply --only theme`, 또는 `N/A - 사유`가 기록되어 있는가?
+
+컴포넌트·라이브러리 계획이 없어 구현자가 임의 패키지 설치나 중복 컴포넌트 생성을 할 수밖에 없으면 Component & Library Planning Gate는 Fail로 처리한다.
+
+### Step 9: Rubric-First Writing 검사
 
 | 레이어 | 기준 |
 |:---|:---|
@@ -129,7 +145,7 @@ HTML Preview가 없거나 링크·사용자 확인 기록이 누락되면 HTML U
 | Technical_Specs (Layer 3) | Functionality, UX (latency), Open-source 언급 (권장) |
 | Logic_Progress (Layer 4) | Functionality, UX 언급 (권장) |
 
-### Step 9: Gate Out 조건 검사
+### Step 10: Gate Out 조건 검사
 
 rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한다.
 
@@ -145,13 +161,14 @@ rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한
 - [ ] UI 문서에서 HTML Preview 상대 경로 링크
 - [ ] 화면·동선·데이터 흐름·상태별 UI 확인 기록
 - [ ] Pre-Code Technical Brief 기록
+- [ ] Component & Library Plan 기록
 
 **Phase 5 (개발문서)**:
 - [ ] `docs/03_Technical_Specs/00_DEVELOPMENT_PRINCIPLES.md`
 - [ ] `docs/04_Logic_Progress/00_ROADMAP.md`
 - [ ] `docs/05_QA_Validation/02_QA_CHECKLIST.md`
 
-### Step 10: 검증 보고서 출력
+### Step 11: 검증 보고서 출력
 
 검사 완료 후 아래 형식으로 결과를 출력한다:
 
@@ -168,6 +185,7 @@ rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한
 | HTML UI Preview Gate | Pass / Fail | HTML Preview 파일·링크·확인 기록 누락 목록 |
 | UI-First Gate | Pass / Fail | 화면·동선·데이터 흐름 누락 목록 |
 | Pre-Code Technical Brief | Pass / Fail | 데이터·API·상태 계약 누락 목록 |
+| Component & Library Planning Gate | Pass / Fail | 컴포넌트·라이브러리 계획 누락 목록 |
 | Rubric-First | Pass / Fail | |
 | Gate Out 조건 | Pass / Fail | 미충족 파일 목록 |
 

package/verify-implementation/SKILL.md

@@ -15,7 +15,7 @@ argument-hint: "[선택사항: 특정 verify 스킬 이름]"
 
 | 순서 | 스킬 | 목적 |
 |---:|---|---|
-| 1 | `verify-docs` | 문서 구조, Backlog Context Lock, UI-First Gate 검증 |
+| 1 | `verify-docs` | 문서 구조, Backlog Context Lock, HTML UI Preview Gate, UI-First Gate, Component & Library Planning Gate 검증 |
 | 2 | `verify-ui` | 구현 UI와 화면 문서, 사용자 동선, 상태별 UI 일치 검증 |
 | 3 | `verify-code` | 코드 품질, 타입, 로직, YAGNI/KISS/DRY, 사이드 이펙트 검증 |
 | 4 | `verify-security` | 인증·인가·입력·시크릿·OWASP 보안 검증 |
@@ -32,7 +32,7 @@ argument-hint: "[선택사항: 특정 verify 스킬 이름]"
 [Flow]
 현재: Phase 5 — 품질 검증
 Gate: Quality Gate + YAGNI/KISS/DRY Gate 진행 중
-완료: Phase 1, Phase 2, UI-First Gate, Pre-Code Technical Brief, Phase 3, Phase 4
+완료: Phase 1, Phase 2, HTML UI Preview Gate, UI-First Gate, Pre-Code Technical Brief, Component & Library Planning Gate, Phase 3, Phase 4
 다음: Phase 6 — 최종 전달물 또는 Handoff
 필요 확인: Fail 항목 또는 N/A 처리 사유
 권장 스킬: /verify-implementation