solmate-skills 2.0.3 → 2.0.5

package/rules-product/SKILL.md

@@ -12,6 +12,8 @@ You are a **workflow lead** who guides the user through the full product develop
 ```
 Phase 1: 기획문서       → docs-plan (Concept_Design)
 Phase 2: UI 설계 문서   → docs-plan (UI_Screens)
+UI-First Gate: 화면·동선·데이터 흐름 확인
+Pre-Code Technical Brief: 데이터·API·상태 최소 합의
 Phase 3: React 변환     → rules-react
 Phase 4: 개발문서       → docs-dev
 Phase 5: 품질 검증      → verify-implementation (verify-docs / verify-code / verify-security / verify-performance)
@@ -30,16 +32,28 @@ Run these checks in order:
 |-------|--------|---------|
 | `docs/01_Concept_Design/` 존재 여부 | 없으면 Phase 1 미완 | 기획문서 필요 |
 | `docs/02_UI_Screens/` 존재 여부 | 없으면 Phase 2 미완 | UI 설계 필요 |
+| UI-First Gate 확인 여부 | 없으면 Phase 3 진입 보류 | 화면·동선·데이터 흐름 확인 필요 |
+| Pre-Code Technical Brief 여부 | 없으면 Phase 3 진입 보류 | 최소 기술 합의 필요 |
 | `src/components/` 또는 React 코드 존재 여부 | 없으면 Phase 3 미완 | React 개발 필요 |
 | `docs/03_Technical_Specs/` 존재 여부 | 없으면 Phase 4 미완 | 개발문서 필요 |
 | verify-* 스킬 실행 이력 또는 사용자 확인 여부 | 없으면 Phase 5 미완 | 품질 검증 필요 |
 
-진단 결과를 다음 형식으로 보고한다:
+진단 결과는 항상 아래 `Flow Status Block` 형식으로 보고한다. 새 작업 시작, Phase 전환, 구현 시작 전, 검증 시작 전, 최종 보고 시에도 같은 형식을 짧게 반복한다.
 
 ```
-현재 단계: Phase N — [단계명]
-완료된 단계: Phase 1, 2, ...
-다음 액션: [구체적 지시]
+[Flow]
+현재: Phase N — [단계명]
+Gate: [진행 중 / 통과 / 미통과 / N/A]
+완료: [완료된 Phase 또는 없음]
+다음: [다음 Phase 또는 Gate]
+필요 확인: [막힌 조건 또는 확인할 항목]
+권장 스킬: /skill-name
+```
+
+일상적인 중간 답변에서는 한 줄 축약형을 쓸 수 있다:
+
+```
+현재 위치: Phase N — [단계명] / Gate: [상태] / 다음: [다음 액션]
 ```
 
 사용자가 특정 단계를 명시한 경우 그 단계로 바로 이동한다.
@@ -68,6 +82,8 @@ Run these checks in order:
 Phase 1 완료 확인 후 다음을 묻는다:
 > "Phase 1 문서가 완성되었습니다. Phase 2(UI 설계 문서)로 넘어갈까요? 또는 기획문서를 바탕으로 파생 문서(피치덱, 사업계획서)를 먼저 작성할 수도 있습니다."
 
+Phase 1 완료 보고에는 `Flow Status Block`을 포함한다.
+
 ---
 
 ### Phase 1 파생 문서 (선택, 순서 무관)
@@ -112,6 +128,11 @@ Phase 1이 완료된 후 언제든 작성 가능하다. Phase 2 진입과 독립
 **Gate Out** (다음 단계 진입 조건):
 - [ ] `docs/02_UI_Screens/00_SCREEN_FLOW.md` 존재
 - [ ] `docs/02_UI_Screens/01_UI_DESIGN.md` 존재
+- [ ] 주요 화면 목록과 화면별 목적이 정의됨
+- [ ] 사용자 진입·이탈·전환 동선이 정의됨
+- [ ] 화면별 입력 데이터, 출력 데이터, 상태 변화가 정의됨
+- [ ] 로딩·빈 상태·오류 상태가 정의됨
+- [ ] 사용자가 화면/UI를 먼저 확인했거나, 확인할 수 있는 프로토타입/스크린샷/리뷰 문서가 있음
 
 **위임 지시**:
 
@@ -121,8 +142,53 @@ Phase 1이 완료된 후 언제든 작성 가능하다. Phase 2 진입과 독립
 참조 문서: docs/01_Concept_Design/ 전체 읽기 후 시작
 ```
 
-Phase 2 완료 확인 후 다음을 묻는다:
-> "Phase 2 문서가 완성되었습니다. Phase 3(React 변환 및 개발)으로 넘어갈까요?"
+Phase 2 완료 후 곧바로 코딩하지 않는다. 먼저 UI-First Gate를 확인하고 다음을 묻는다:
+> "화면 구조, 사용자 동선, 데이터 흐름, 로딩/빈/오류 상태를 먼저 확인했습니다. 현재 단계에서 더 구체화하거나 보완할 점이 있을까요?"
+
+Phase 2 완료 보고에는 `Flow Status Block`을 포함하고, 다음 위치가 `UI-First Gate`임을 명시한다.
+
+---
+
+## UI-First Gate: 화면·동선·데이터 흐름 확인
+
+**목표**: 구동 코드 작성 전에 실제 화면 기준으로 사용 흐름과 데이터 흐름을 합의한다. 이 게이트를 통과하기 전에는 Phase 3 구현을 시작하지 않는다.
+
+**필수 확인 항목**:
+- [ ] 주요 화면과 화면별 목적
+- [ ] 사용자 진입 경로, 다음 행동, 이탈 경로
+- [ ] 화면별 CTA와 인터랙션
+- [ ] 화면별 입력 데이터, 출력 데이터, 상태 변화
+- [ ] 로딩, 빈 상태, 오류 상태, 권한 없음 상태
+- [ ] 모바일·데스크톱에서 구조 차이가 큰 구간
+- [ ] 사용자 또는 의사결정권자가 화면/UI를 먼저 확인한 기록
+
+**Gate Out**:
+- [ ] `00_SCREEN_FLOW.md`에 사용자 여정과 전환 흐름이 기록됨
+- [ ] `01_UI_DESIGN.md` 또는 `XX_PROTOTYPE_REVIEW.md`에 화면 상태와 피드백이 기록됨
+- [ ] 필요한 경우 `docs/04_Logic_Progress/00_BACKLOG.md`의 작업 항목에 UI 확인 결과가 반영됨
+
+UI-First Gate 보고에는 `Flow Status Block`을 포함하고, 다음 위치가 `Pre-Code Technical Brief`임을 명시한다.
+
+---
+
+## Pre-Code Technical Brief: 데이터·API·상태 최소 합의
+
+**목표**: UI 확인 후 바로 코딩하지 않고, 구현에 필요한 최소 기술 계약을 먼저 정한다. 완전한 기술 명세가 아니어도 되지만, React 구현이 임의의 데이터 구조와 상태 흐름을 만들지 않도록 한다.
+
+**필수 확인 항목**:
+- [ ] 화면별 데이터 소스: mock data, API, DB, 외부 서비스 중 무엇인가?
+- [ ] 화면별 입력·출력 데이터의 최소 필드
+- [ ] 주요 mutation: 생성, 수정, 삭제, 제출, 업로드 등
+- [ ] 상태 관리 방식: local state, URL state, server state, global store 중 무엇인가?
+- [ ] API/DB가 필요한 경우 임시 계약 또는 문서 위치
+- [ ] Acceptance Criteria: 구현 완료를 판단할 사용자 시나리오
+
+**Gate Out**:
+- [ ] `docs/03_Technical_Specs/` 문서가 있으면 관련 계약이 반영됨
+- [ ] 기술 문서가 아직 없으면 백로그의 `Implementation Preconditions` 또는 `Acceptance Criteria`에 최소 계약이 기록됨
+- [ ] 구현자가 mock data 구조와 실제 데이터 전환 방식을 설명할 수 있음
+
+Pre-Code Technical Brief 보고에는 `Flow Status Block`을 포함하고, 다음 위치가 `Phase 3 — React 변환`임을 명시한다.
 
 ---
 
@@ -132,6 +198,9 @@ Phase 2 완료 확인 후 다음을 묻는다:
 
 **Gate In**:
 - Phase 2 문서 (`02_UI_Screens/`) 존재
+- UI-First Gate 통과
+- 화면·동선·데이터 흐름 확인 결과가 백로그 또는 UI 문서에 반영됨
+- Pre-Code Technical Brief 통과
 
 **Gate Out** (다음 단계 진입 조건):
 - [ ] `src/components/` 에 주요 컴포넌트 존재
@@ -149,6 +218,8 @@ Phase 2 완료 확인 후 다음을 묻는다:
 Phase 3 완료 확인 후 다음을 묻는다:
 > "Phase 3이 완료되었습니다. Phase 4(개발문서)로 넘어갈까요?"
 
+Phase 3 완료 보고에는 `Flow Status Block`을 포함한다.
+
 ---
 
 ## Phase 4: 개발문서 (Technical_Specs / Logic_Progress / QA_Validation)
@@ -176,6 +247,8 @@ Phase 3 완료 확인 후 다음을 묻는다:
 Phase 4 완료 확인 후 다음을 묻는다:
 > "Phase 4 문서가 완성되었습니다. Phase 5(품질 검증)로 넘어갈까요?"
 
+Phase 4 완료 보고에는 `Flow Status Block`을 포함한다.
+
 ---
 
 ## Phase 5: Quality Gate (품질 검증)
@@ -188,10 +261,12 @@ Phase 4 완료 확인 후 다음을 묻는다:
 
 **Gate Out** (다음 단계 진입 조건):
 - [ ] `verify-docs` PASS — 문서 구조·메타데이터 정합성
+- [ ] `verify-ui` PASS — 구현 UI와 화면 문서·사용자 동선·상태별 UI 정합성
 - [ ] `verify-code` PASS — 코드 품질 (로직, 타입, 중복, 사이드 이펙트)
 - [ ] `verify-security` PASS — OWASP Top 10 기준 보안 이슈 없음
 - [ ] `verify-performance` PASS — Lighthouse Performance 90+, Core Web Vitals 기준 충족
 - [ ] `verify-drizzle-schema` PASS — DB 스키마 정합성 (DB 사용 시)
+- [ ] `verify-skills` PASS — 스킬 패키지 변경 시 메타데이터·CLI·패키징 정합성
 
 **위임 지시**:
 
@@ -204,6 +279,8 @@ FAIL 항목 발견 시: 해당 스킬로 돌아가 수정 후 재검증
 FAIL 항목이 있으면 해당 Phase로 되돌아가 수정 후 재실행한다. 모든 항목 PASS 확인 후 다음을 묻는다:
 > "모든 검증을 통과했습니다. Phase 6(최종 전달물)으로 넘어갈까요?"
 
+Phase 5 검증 보고에는 `Flow Status Block`을 포함하고, Fail이 있으면 `필요 확인`에 차단 항목을 적는다.
+
 ---
 
 ## Phase 6: 최종 전달물 (선택)
@@ -230,6 +307,14 @@ FAIL 항목이 있으면 해당 Phase로 되돌아가 수정 후 재실행한다
 전체 파이프라인 완료 후 최종 보고:
 
 ```
+[Flow]
+현재: Phase 6 — 최종 전달물 또는 Handoff
+Gate: 완료
+완료: Phase 1, Phase 2, UI-First Gate, Pre-Code Technical Brief, Phase 3, Phase 4, Phase 5
+다음: 사용자 선택 후속 작업
+필요 확인: 남은 TODO 또는 없음
+권장 스킬: /docs-pitch 또는 /docs-business (선택)
+
 전체 워크플로우 완료
 - Phase 1: docs/01_Concept_Design/        기획문서
 - Phase 2: docs/02_UI_Screens/            UI 설계 문서
@@ -239,6 +324,18 @@ FAIL 항목이 있으면 해당 Phase로 되돌아가 수정 후 재실행한다
 - Phase 6: docs-pitch / docs-business    최종 전달물 (선택)
 ```
 
+## Final Handoff Checklist
+
+Phase 6이 선택 사항이어도, 작업을 마무리할 때는 아래 항목을 최종 보고에 포함한다.
+
+- [ ] 현재 Phase와 완료된 Phase 목록
+- [ ] 구현 또는 문서 산출물 경로
+- [ ] UI-First Gate와 Pre-Code Technical Brief 충족 여부
+- [ ] 실행한 verify 스킬과 결과
+- [ ] 배포 URL 또는 로컬 실행 방법 (해당 시)
+- [ ] 남은 TODO, Known Issue, 문서-구현 불일치 여부
+- [ ] 다음 작업자가 바로 이어갈 수 있는 다음 액션
+
 ---
 
 ## Anti-Rush Rules (AGENTS.md 준수)
@@ -261,8 +358,10 @@ FAIL 항목이 있으면 해당 Phase로 되돌아가 수정 후 재실행한다
 - **rules-react**: Phase 3 React 개발
 - **docs-dev**: Phase 4 기술 문서 작성
 - **verify-implementation**: Phase 5 품질 검증 통합 실행
+- **verify-ui**: Phase 5 UI 정합성 검증
 - **verify-code**: Phase 5 코드 품질 리뷰
 - **verify-security**: Phase 5 보안 점검
 - **verify-performance**: Phase 5 성능 점검
+- **verify-skills**: 스킬 패키지 변경 검증
 - **docs-pitch**: Phase 6 피치덱 작성
 - **docs-business**: Phase 6 사업계획서 작성

package/rules-product/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Product Workflow"
+  short_description: "Orchestrate planning, UI, docs, and QA phases"
+  default_prompt: "Use $rules-product to diagnose the current product phase and choose the next skill."

package/rules-react/SKILL.md

@@ -8,7 +8,8 @@ description: Create modular, premium React components and pages based on UI desi
 You are a senior frontend engineer focused on transforming UI designs into clean, premium, and performant React code. You follow a modular approach and use modern best practices.
 
 ## 1. Input Sources
-- **docs-plan Layer 2**: Read `docs/02_UI_Screens/01_UI_DESIGN.md` for tokens and `XX_PROTOTYPE_REVIEW.md` for layout details.
+- **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.
 - **rules-dev**: Follow coding standards, file naming, and state management rules.
 - **Vercel Best Practices**: Follow the provided skills for performance and composition patterns.
 
@@ -21,11 +22,13 @@ You are a senior frontend engineer focused on transforming UI designs into clean
 * **Aesthetics**: Implement rich aesthetics, smooth transitions, and premium typography as per the "Web Application Development" guidelines.
 
 ## 3. Execution steps
-1. **Analyze Design**: Read the UI Screens documentation and technical specs. Identify components, state requirements, and interactive elements.
-2. **Draft Logic**: Decide on state management and hook structure.
-3. **Data layer**: Prepare mock data or data fetching logic.
-4. **Implement UI**: Build components starting from the most granular (atoms) to full pages.
-5. **Quality check**:
+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**:
     - Verify against accessibility standards.
     - Check performance (avoid unnecessary re-renders).
     - Ensure responsive design works across all target devices.
@@ -36,4 +39,4 @@ You are a senior frontend engineer focused on transforming UI designs into clean
 - **rules-dev**: Development standards and conventions.
 - **docs-dev**: Technical specs and backend integration details.
 - **vercel-react-best-practices**: Performance optimization.
-- **vercel-composition-patterns**: Reusable component architecture.
+- **vercel-composition-patterns**: Reusable component architecture.

package/rules-react/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "React Rules"
+  short_description: "Build modular premium React components"
+  default_prompt: "Use $rules-react to implement UI screens as modular, typed React components."

package/rules-workflow/SKILL.md

@@ -9,13 +9,25 @@ Follow this workflow for feature implementation and significant code changes. Co
 
 ---
 
+## Step 0: Product Phase Preflight
+
+기능 구현을 시작하기 전, 먼저 `rules-product` 기준으로 현재 프로젝트 Phase를 진단한다. Concept, UI, UI-First Gate, Pre-Code Technical Brief 중 하나라도 누락되어 구현 판단이 불안정하면 코딩을 시작하지 않고 해당 문서 또는 백로그 보완을 제안한다.
+
+- 체크: [ ] 현재 Phase를 진단했는가? [ ] UI-First Gate가 충족되었는가? [ ] 최소 기술 계약이 확인되었는가?
+
+진단 결과는 `rules-product`의 `Flow Status Block` 형식으로 먼저 보고한다. 구현 단계 중 사용자가 "지금 어디야?", "다음 뭐야?", "현재 단계가 뭐야?"라고 묻거나 Phase 1-6 경계에 도달하면 같은 형식을 다시 출력한다.
+
+---
+
 ## Phase 1: Plan (Steps 1–4)
 
 ### Step 1. 계획 수립
 - 요구사항·목적을 문서 또는 이슈 기준으로 정리한다.
 - 백로그 항목이 있으면 `Related Concept Docs`, `Related UI Docs`, `Related Technical Docs`, `Related QA Docs`를 먼저 읽고 구현 입력값으로 요약한다.
+- 코드 작성보다 먼저 UI-First Gate를 확인한다. 화면 구조, 사용자 동선, 데이터 흐름, 로딩·빈 상태·오류 상태가 문서화되지 않았으면 구현 계획을 보류하고 `docs-plan` 또는 `docs-dev` 문서 보완을 제안한다.
+- Pre-Code Technical Brief를 확인한다. 데이터 소스, 최소 필드, mutation, 상태 관리 방식, acceptance criteria가 불명확하면 구현 전에 사용자와 합의한다.
 - 변경할 파일·추가할 컴포넌트·API·DB 영향 범위를 나열한다.
-- 체크: [ ] 목적이 명확한가? [ ] 관련 문서를 읽었는가? [ ] 영향 범위가 정리되었는가?
+- 체크: [ ] 목적이 명확한가? [ ] 관련 문서를 읽었는가? [ ] UI-First Gate가 확인되었는가? [ ] 최소 기술 계약이 확인되었는가? [ ] 영향 범위가 정리되었는가?
 
 ### Step 2. 계획 검토
 - 계획이 요구사항과 일치하는지, 누락된 시나리오는 없는지 검토한다.
@@ -36,7 +48,9 @@ Follow this workflow for feature implementation and significant code changes. Co
 ### Step 5. 구현
 - 승인된 계획대로 구현한다. AGENTS.md·프로젝트 컨벤션(커밋, Zod, Luxon 등)을 따른다.
 - 코드 작성 전 백로그 항목의 `Implementation Preconditions`와 `Acceptance Criteria`를 확인한다. 관련 문서 링크가 비어 있거나 `N/A - 사유`가 부실하면 구현을 보류하고 문서 보완 필요 여부를 사용자에게 확인한다.
-- 체크: [ ] 계획 대비 변경 사항이 일치하는가? [ ] 백로그의 관련 문서 기준을 반영했는가?
+- UI-First Gate가 통과되지 않았거나 사용자가 화면/UI를 먼저 확인하지 않았다면 구현을 시작하지 않는다.
+- 구현을 시작하기 직전에 `Flow Status Block`을 출력하고, 현재 위치가 `Phase 3 — React 변환` 또는 해당 기능 구현 단계인지 명시한다.
+- 체크: [ ] 계획 대비 변경 사항이 일치하는가? [ ] 백로그의 관련 문서 기준을 반영했는가? [ ] 화면·동선·데이터 흐름 확인 후 구현했는가?
 
 ---
 
@@ -97,6 +111,7 @@ Follow this workflow for feature implementation and significant code changes. Co
 
 ### Step 17. 배포 가능 퀄리티 최종 검토
 - "이대로 배포해도 될 수준인가?"를 한 번 더 검토한다. 1–16단계에서 누락된 항목이 없는지 확인한다.
+- 최종 검토 시 `Flow Status Block`을 출력하고, 다음 위치가 `Phase 6 — Ship/Handoff`인지 명시한다.
 - 체크: [ ] 배포 전 필수 조건 충족 [ ] 롤백·모니터링 고려 여부
 
 ---

package/rules-workflow/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Implementation Workflow"
+  short_description: "Follow the full implementation lifecycle"
+  default_prompt: "Use $rules-workflow to plan, implement, verify, and prepare this feature for shipping."

package/tools-obsidian/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Obsidian Sync"
+  short_description: "Synchronize project docs with Obsidian"
+  default_prompt: "Use $tools-obsidian to verify or set up documentation sync with an Obsidian vault."

package/tools-shadcn/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "shadcn UI Tools"
+  short_description: "Use and validate shadcn/ui components"
+  default_prompt: "Use $tools-shadcn to install, compose, or validate shadcn/ui components."

package/verify-code/SKILL.md

@@ -6,7 +6,7 @@ argument-hint: "[선택사항: 리뷰할 파일 경로 또는 기능명]"
 
 # 코드 리뷰 스킬 (verify-code)
 
-PR 또는 커밋 전 코드 품질을 종합적으로 점검합니다. 구현이 완료된 코드를 대상으로 아래 6개 영역을 순서대로 검토하고 발견된 이슈를 보고합니다.
+PR 또는 커밋 전 코드 품질을 종합적으로 점검합니다. 구현이 완료된 코드를 대상으로 아래 7개 영역을 순서대로 검토하고 발견된 이슈를 보고합니다.
 
 ---
 
@@ -101,6 +101,20 @@ git diff --name-only HEAD
 
 ---
 
+## Area 7: UI-First 구현 정합성
+
+TSX/JSX 화면 또는 컴포넌트 변경이 있으면 `docs/02_UI_Screens/`와 관련 백로그를 확인한다. 상세 UI 검증이 필요하면 `verify-ui`로 위임한다.
+
+- 구현된 화면이 UI 문서의 화면 구조, 사용자 동선, CTA와 일치하는지 확인한다.
+- 로딩, 빈 상태, 오류 상태, 권한 없음 상태가 빠지지 않았는지 확인한다.
+- 화면에서 사용하는 데이터가 문서의 입력·출력·저장 흐름과 충돌하지 않는지 확인한다.
+- 체크:
+  - [ ] UI-First Gate 문서 또는 백로그를 기준으로 구현했는가?
+  - [ ] 상태별 UI가 구현되어 있는가?
+  - [ ] 구현이 문서와 달라졌다면 관련 문서를 업데이트했는가?
+
+---
+
 ## 보고 형식
 
 리뷰 결과는 다음 형식으로 보고한다:
@@ -116,6 +130,7 @@ git diff --name-only HEAD
 |------|------|------|:------:|
 | src/foo.ts:42 | 타입 안전성 | API 응답에 any 사용 | 중 |
 | src/bar.tsx:15 | 불필요 코드 | console.log 미제거 | 낮음 |
+| src/page.tsx:30 | UI-First 정합성 | Error state 미구현 | 중 |
 
 ### 수정 권장 우선순위
 1. [높음] ...
@@ -131,4 +146,5 @@ git diff --name-only HEAD
 
 - `rules-dev`: 프로젝트 코딩 컨벤션 기준
 - `rules-workflow`: Step 14 코드 품질 검토와 연동
+- `verify-ui`: 화면 문서와 구현 UI 일치 여부 검증
 - `verify-security`: 보안 관련 이슈는 이 스킬로 위임

package/verify-code/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Code Verification"
+  short_description: "Review code quality before commit or PR"
+  default_prompt: "Use $verify-code to review changed code for logic, typing, reuse, and side effects."

package/verify-docs/SKILL.md

@@ -12,8 +12,10 @@ description: 프로젝트 문서가 5단계 구조(01~05)와 메타데이터 표
 2. 메타데이터 표준 (Created / Last Updated)
 3. Related Documents 섹션
 4. Backlog Context Lock
-5. Rubric-First Writing
-6. rules-product Gate Out 조건
+5. UI-First Gate
+6. Pre-Code Technical Brief
+7. Rubric-First Writing
+8. rules-product Gate Out 조건
 
 ## 실행 시점
 
@@ -69,10 +71,37 @@ AGENTS.md 또는 `docs/01_Concept_Design/00_COLLABORATION_GUIDE.md`를 읽어
 - [ ] 각 작업 항목에 `Document Sync Check`가 있는가?
 - [ ] Related 필드의 링크가 상대 경로이거나 `N/A - 사유` 형식인가?
 - [ ] `N/A`만 있고 사유가 없는 항목은 없는가?
+- [ ] `Implementation Preconditions`에 화면/UI 선확인, 사용자 동선 확인, 데이터 흐름 확인, 로딩·빈 상태·오류 상태 확인이 포함되어 있는가?
+- [ ] `Implementation Preconditions` 또는 `Acceptance Criteria`에 데이터 소스, 최소 필드, mutation, 상태 관리 방식, 검증 가능한 acceptance criteria가 포함되어 있는가?
 
 위 항목 중 하나라도 누락되면 Backlog Context Lock은 Fail로 처리한다.
 
-### Step 5: Rubric-First Writing 검사
+### Step 5: UI-First Gate 검사
+
+`docs/02_UI_Screens/`와 `docs/04_Logic_Progress/00_BACKLOG.md`를 함께 확인한다.
+
+체크 항목:
+- [ ] `00_SCREEN_FLOW.md`에 주요 화면, 진입·전환·이탈 동선이 있는가?
+- [ ] `00_SCREEN_FLOW.md` 또는 관련 UI 문서에 화면별 입력·출력 데이터가 있는가?
+- [ ] `01_UI_DESIGN.md` 또는 `XX_PROTOTYPE_REVIEW.md`에 로딩·빈 상태·오류 상태가 있는가?
+- [ ] `XX_PROTOTYPE_REVIEW.md` 또는 백로그에 사용자의 화면/UI 선확인 기록이 있는가?
+- [ ] 코드 구현 백로그가 UI 확인 없이 `In Progress` 또는 `Done`으로 이동하지 않았는가?
+
+구현 판단에 필요한 화면·동선·데이터 흐름이 누락되면 UI-First Gate는 Fail로 처리한다.
+
+### Step 6: Pre-Code Technical Brief 검사
+
+`docs/03_Technical_Specs/`와 `docs/04_Logic_Progress/00_BACKLOG.md`를 함께 확인한다.
+
+체크 항목:
+- [ ] 구현 대상 화면의 데이터 소스가 정리되어 있는가?
+- [ ] 화면별 최소 필드와 mock data 또는 API 계약이 있는가?
+- [ ] mutation과 상태 관리 방식이 기록되어 있는가?
+- [ ] acceptance criteria가 사용자 시나리오 기준으로 검증 가능한가?
+
+데이터·API·상태 계약이 없어 구현자가 임의 구조를 만들 수밖에 없으면 Pre-Code Technical Brief는 Fail로 처리한다.
+
+### Step 7: Rubric-First Writing 검사
 
 | 레이어 | 기준 |
 |:---|:---|
@@ -82,7 +111,7 @@ AGENTS.md 또는 `docs/01_Concept_Design/00_COLLABORATION_GUIDE.md`를 읽어
 | Technical_Specs (Layer 3) | Functionality, UX (latency), Open-source 언급 (권장) |
 | Logic_Progress (Layer 4) | Functionality, UX 언급 (권장) |
 
-### Step 6: Gate Out 조건 검사
+### Step 8: Gate Out 조건 검사
 
 rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한다.
 
@@ -94,13 +123,15 @@ rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한
 **Phase 2 (UI 설계)**:
 - [ ] `docs/02_UI_Screens/00_SCREEN_FLOW.md`
 - [ ] `docs/02_UI_Screens/01_UI_DESIGN.md`
+- [ ] 화면·동선·데이터 흐름·상태별 UI 확인 기록
+- [ ] Pre-Code Technical Brief 기록
 
 **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 7: 검증 보고서 출력
+### Step 9: 검증 보고서 출력
 
 검사 완료 후 아래 형식으로 결과를 출력한다:
 
@@ -114,6 +145,8 @@ rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한
 | 메타데이터 | Pass / Fail | 누락 파일 목록 |
 | Related Documents | Pass / Fail | 미연결 파일 목록 |
 | Backlog Context Lock | Pass / Fail | 필수 필드 누락 작업 목록 |
+| UI-First Gate | Pass / Fail | 화면·동선·데이터 흐름 누락 목록 |
+| Pre-Code Technical Brief | Pass / Fail | 데이터·API·상태 계약 누락 목록 |
 | Rubric-First | Pass / Fail | |
 | Gate Out 조건 | Pass / Fail | 미충족 파일 목록 |
 

package/verify-docs/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Docs Verification"
+  short_description: "Audit documentation structure and metadata"
+  default_prompt: "Use $verify-docs to audit the five-layer docs structure and metadata fields."

package/verify-drizzle-schema/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Drizzle Schema Verification"
+  short_description: "Check Drizzle schema and spec alignment"
+  default_prompt: "Use $verify-drizzle-schema to compare Drizzle schema changes against the technical docs."

package/verify-implementation/SKILL.md

@@ -5,35 +5,89 @@ disable-model-invocation: true
 argument-hint: "[선택사항: 특정 verify 스킬 이름]"
 ---
 
-# 구현 검증 (Master Template)
+# 구현 검증 (Master)
 
 ## 목적
 
-프로젝트에 존재하는 모든 `verify-*` 스킬을 동적으로 탐색하여 순차적으로 실행하고 통합 검증을 수행합니다.
+프로젝트에 존재하는 모든 `verify-*` 스킬을 동적으로 탐색하여 순차적으로 실행하고 통합 검증을 수행합니다. 기본 순서를 따르되, 변경 파일과 프로젝트 특성에 따라 해당 없는 스킬은 `N/A - 사유`로 기록합니다.
 
-## 실행 대상 스킬 (Dynamic)
+## 기본 실행 순서
 
-| # | 스킬 | 설명 |
-|---|------|------|
-| * | `verify-*` | `.agent/skills` 또는 `.claude/commands`에서 자동 탐색 |
+| 순서 | 스킬 | 목적 |
+|---:|---|---|
+| 1 | `verify-docs` | 문서 구조, Backlog Context Lock, UI-First Gate 검증 |
+| 2 | `verify-ui` | 구현 UI와 화면 문서, 사용자 동선, 상태별 UI 일치 검증 |
+| 3 | `verify-code` | 코드 품질, 타입, 로직, 사이드 이펙트 검증 |
+| 4 | `verify-security` | 인증·인가·입력·시크릿·OWASP 보안 검증 |
+| 5 | `verify-performance` | Lighthouse, Core Web Vitals, 렌더링·번들 검증 |
+| 6 | `verify-drizzle-schema` | DB 스키마 변경 시 명세·관계·인덱스 검증 |
+| 7 | `verify-skills` | solmate-skills 패키지 자체 변경 시 스킬 메타데이터·CLI·패키징 검증 |
 
 ## 워크플로우
 
+### Step 0: Flow 위치 확인
+검증을 시작하기 전에 `rules-product`의 `Flow Status Block` 형식으로 현재 위치를 보고합니다. 일반적으로 현재 위치는 `Phase 5 — 품질 검증`입니다.
+
+```
+[Flow]
+현재: Phase 5 — 품질 검증
+Gate: Quality Gate 진행 중
+완료: Phase 1, Phase 2, UI-First Gate, Pre-Code Technical Brief, Phase 3, Phase 4
+다음: Phase 6 — 최종 전달물 또는 Handoff
+필요 확인: Fail 항목 또는 N/A 처리 사유
+권장 스킬: /verify-implementation
+```
+
 ### Step 1: 동적 스킬 탐색
-`.agent/skills/` 및 `.claude/commands/` 하위의 `verify-*` 패턴을 탐색합니다.
+`.agent/skills/`, `.claude/commands/`, 또는 현재 저장소 하위의 `verify-*` 패턴을 탐색합니다.
+
+### Step 2: 변경 파일 기반 실행 계획 수립
+`git diff --name-only HEAD` 기준으로 실행 대상을 정합니다.
 
-### Step 2: 순차 실행
-각 스킬의 `Workflow`, `Exceptions`, `Related Files`를 파싱하여 개별 검사를 수행합니다.
+- 문서 변경: `verify-docs`
+- TS/TSX/JS/JSX 변경: `verify-code`
+- TSX/JSX 화면 변경: `verify-ui`
+- auth/api/middleware/env/db 변경: `verify-security`
+- page/layout/image/font/bundle 관련 변경: `verify-performance`
+- schema/migration 변경: `verify-drizzle-schema`
+- `SKILL.md`, `agents/openai.yaml`, `bin/cli.js`, `README.md`, `AGENTS.md`, `package.json` 변경: `verify-skills`
 
-### Step 3: 통합 보고서 생성
+### Step 3: 순차 실행
+기본 실행 순서대로 각 스킬의 `Workflow`, `Exceptions`, `Related Files`를 파싱하여 개별 검사를 수행합니다. 앞 단계가 Fail이면 뒤 단계는 실행하되, 해당 Fail이 뒤 단계 판단을 왜곡하는 경우 `Blocked - 사유`로 표시합니다.
+
+### Step 4: 통합 보고서 생성
 PASS/FAIL 통계와 발견된 이슈 목록을 생성합니다.
+보고서 상단에는 `Flow Status Block`을 다시 포함하고, Gate 상태를 `통과`, `미통과`, `Blocked`, `N/A` 중 하나로 표시합니다.
 
-### Step 4: 수정 옵션 제공
+### Step 5: 수정 옵션 제공
 자동 수정 또는 개별 수정을 사용자에게 제안합니다.
 
-### Step 5: 수정 적용 및 재검증
+### Step 6: 수정 적용 및 재검증
 수정이 적용된 경우 해당 스킬을 다시 실행하여 통과 여부를 최종 확인합니다.
 
+## 보고 형식
+
+```
+## 통합 구현 검증 결과
+
+| 순서 | 스킬 | 결과 | 비고 |
+|---:|---|:---:|---|
+| 1 | verify-docs | Pass / Fail / N/A | |
+| 2 | verify-ui | Pass / Fail / N/A | |
+| 3 | verify-code | Pass / Fail / N/A | |
+| 4 | verify-security | Pass / Fail / N/A | |
+| 5 | verify-performance | Pass / Fail / N/A | |
+| 6 | verify-drizzle-schema | Pass / Fail / N/A | |
+| 7 | verify-skills | Pass / Fail / N/A | |
+
+### 배포/PR 차단 항목
+- [높음] ...
+
+### 재검증 필요 항목
+- ...
+```
+
 ## 예외사항
 1. **자기 자신** (`verify-implementation`)은 실행 대상에서 제외.
 2. **관리 스킬** (`manage-skills` 등)은 `verify-`로 시작하지 않으므로 제외.
+3. **해당 없음**: DB, UI, 패키지 메타데이터 등 변경 범위와 관련 없는 검증은 `N/A - 사유`로 기록.

package/verify-implementation/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Implementation Verification"
+  short_description: "Run all verification skills as one review"
+  default_prompt: "Use $verify-implementation to discover and run the relevant verify skills before PR."

package/verify-performance/SKILL.md

@@ -176,6 +176,20 @@ npx lighthouse http://localhost:3000 --view --output=html
 
 ---
 
+## Check 7: 상태별 UI 성능
+
+UI-First Gate에서 정의한 로딩, 빈 상태, 오류 상태가 성능과 레이아웃 안정성을 해치지 않는지 확인한다.
+
+- 로딩 스켈레톤 또는 placeholder가 최종 콘텐츠와 유사한 크기를 가져 CLS를 줄이는지 점검한다.
+- 빈 상태와 오류 상태가 이미지·아이콘·폰트를 과도하게 로드하지 않는지 확인한다.
+- 모바일 첫 화면에서 핵심 CTA가 로딩 상태 또는 오류 배너에 밀려 사라지지 않는지 확인한다.
+- 체크:
+  - [ ] 로딩 상태가 최종 레이아웃과 유사한 공간을 예약하는가?
+  - [ ] 빈/오류 상태가 불필요한 대형 에셋을 초기 로드하지 않는가?
+  - [ ] 상태 전환이 CLS 또는 긴 INP를 유발하지 않는가?
+
+---
+
 ## 보고 형식
 
 ```
@@ -196,6 +210,7 @@ npx lighthouse http://localhost:3000 --view --output=html
 |------|-----------|------|:---------:|
 | src/pages/Home.tsx | 이미지 최적화 | <img> 직접 사용, LCP 지연 가능성 | LCP |
 | src/app/layout.tsx | 폰트 최적화 | Google Fonts <link> 직접 로드 | CLS·FCP |
+| src/components/List.tsx | 상태별 UI 성능 | Empty state 전환 시 레이아웃 시프트 가능 | CLS |
 
 ### 수정 권장 우선순위
 1. [높음] ...
@@ -216,6 +231,7 @@ npx lighthouse http://localhost:3000 --view --output=html
 ## 관련 스킬
 
 - `verify-code`: 코드 품질 전반 리뷰
+- `verify-ui`: 화면 상태와 사용자 동선 검증
 - `verify-security`: 보안 취약점 점검
 - `rules-dev`: 렌더링 전략·코드 스플리팅 컨벤션 기준
 - `verify-implementation`: 전체 verify-* 통합 실행 시 포함 대상

package/verify-performance/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Performance Verification"
+  short_description: "Check Lighthouse and Core Web Vitals risks"
+  default_prompt: "Use $verify-performance to inspect rendering, bundle, image, and Lighthouse risks."

package/verify-security/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Security Verification"
+  short_description: "Review OWASP security risks before release"
+  default_prompt: "Use $verify-security to review authentication, authorization, inputs, secrets, and OWASP risks."