solmate-skills 2.0.4 → 2.0.6

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-react/scripts/fetch-stitch.sh

@@ -0,0 +1,30 @@
+#!/bin/bash
+# Copyright 2026 Google LLC
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#     http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+URL=$1
+OUTPUT=$2
+if [ -z "$URL" ] || [ -z "$OUTPUT" ]; then
+  echo "Usage: $0 <url> <output_path>"
+  exit 1
+fi
+echo "Initiating high-reliability fetch for Stitch HTML..."
+curl -L -f -sS --connect-timeout 10 --compressed "$URL" -o "$OUTPUT"
+if [ $? -eq 0 ]; then
+  echo "✅ Successfully retrieved HTML at: $OUTPUT"
+  exit 0
+else
+  echo "❌ Error: Failed to retrieve content. Check TLS/SNI or URL expiration."
+  exit 1
+fi

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/tools-shadcn/scripts/verify-setup.sh

@@ -0,0 +1,134 @@
+#!/usr/bin/env bash
+# shadcn/ui Setup Verification Script
+# Validates that a project is correctly configured for shadcn/ui
+
+set -e
+
+GREEN='\033[0;32m'
+RED='\033[0;31m'
+YELLOW='\033[1;33m'
+NC='\033[0m' # No Color
+
+echo "🔍 Verifying shadcn/ui setup..."
+echo ""
+
+# Check if components.json exists
+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"
+    exit 1
+fi
+
+# Check if tailwind.config exists
+if [ -f "tailwind.config.js" ] || [ -f "tailwind.config.ts" ]; then
+    echo -e "${GREEN}✓${NC} Tailwind config found"
+else
+    echo -e "${RED}✗${NC} tailwind.config.js not found"
+    echo -e "  ${YELLOW}Install Tailwind:${NC} npm install -D tailwindcss postcss autoprefixer"
+    exit 1
+fi
+
+# Check if tsconfig.json has path aliases
+if [ -f "tsconfig.json" ]; then
+    if grep -q '"@/\*"' tsconfig.json; then
+        echo -e "${GREEN}✓${NC} Path aliases configured in tsconfig.json"
+    else
+        echo -e "${YELLOW}⚠${NC} Path aliases not found in tsconfig.json"
+        echo "  Add to compilerOptions.paths:"
+        echo '  "@/*": ["./src/*"]'
+    fi
+else
+    echo -e "${YELLOW}⚠${NC} tsconfig.json not found (TypeScript not configured)"
+fi
+
+# Check if globals.css or equivalent exists
+if [ -f "src/index.css" ] || [ -f "src/globals.css" ] || [ -f "app/globals.css" ]; then
+    echo -e "${GREEN}✓${NC} Global CSS file found"
+    
+    # Check for Tailwind directives
+    CSS_FILE=$(find . -name "globals.css" -o -name "index.css" | head -n 1)
+    if grep -q "@tailwind base" "$CSS_FILE"; then
+        echo -e "${GREEN}✓${NC} Tailwind directives present"
+    else
+        echo -e "${RED}✗${NC} Tailwind directives missing"
+        echo "  Add to your CSS file:"
+        echo "  @tailwind base;"
+        echo "  @tailwind components;"
+        echo "  @tailwind utilities;"
+    fi
+    
+    # Check for CSS variables
+    if grep -q "^:root" "$CSS_FILE" || grep -q "@layer base" "$CSS_FILE"; then
+        echo -e "${GREEN}✓${NC} CSS variables defined"
+    else
+        echo -e "${YELLOW}⚠${NC} CSS variables not found"
+        echo "  shadcn/ui requires CSS variables for theming"
+    fi
+else
+    echo -e "${RED}✗${NC} Global CSS file not found"
+fi
+
+# Check if components/ui directory exists
+if [ -d "src/components/ui" ] || [ -d "components/ui" ]; then
+    echo -e "${GREEN}✓${NC} components/ui directory exists"
+    
+    # Count components
+    COMPONENT_COUNT=$(find . -path "*/components/ui/*.tsx" -o -path "*/components/ui/*.jsx" | wc -l)
+    echo -e "  ${COMPONENT_COUNT} components installed"
+else
+    echo -e "${YELLOW}⚠${NC} components/ui directory not found"
+    echo "  Add your first component: npx shadcn@latest add button"
+fi
+
+# Check if lib/utils exists
+if [ -f "src/lib/utils.ts" ] || [ -f "lib/utils.ts" ]; then
+    echo -e "${GREEN}✓${NC} lib/utils.ts exists"
+    
+    # Check for cn function
+    UTILS_FILE=$(find . -name "utils.ts" | grep "lib" | head -n 1)
+    if grep -q "export function cn" "$UTILS_FILE"; then
+        echo -e "${GREEN}✓${NC} cn() utility function present"
+    else
+        echo -e "${RED}✗${NC} cn() utility function missing"
+    fi
+else
+    echo -e "${RED}✗${NC} lib/utils.ts not found"
+fi
+
+# Check package.json dependencies
+if [ -f "package.json" ]; then
+    echo ""
+    echo "📦 Checking dependencies..."
+    
+    # Required dependencies
+    REQUIRED_DEPS=("react" "tailwindcss")
+    RECOMMENDED_DEPS=("class-variance-authority" "clsx" "tailwind-merge" "tailwindcss-animate")
+    
+    for dep in "${REQUIRED_DEPS[@]}"; do
+        if grep -q "\"$dep\"" package.json; then
+            echo -e "${GREEN}✓${NC} $dep installed"
+        else
+            echo -e "${RED}✗${NC} $dep not installed"
+        fi
+    done
+    
+    echo ""
+    echo "Recommended dependencies:"
+    for dep in "${RECOMMENDED_DEPS[@]}"; do
+        if grep -q "\"$dep\"" package.json; then
+            echo -e "${GREEN}✓${NC} $dep installed"
+        else
+            echo -e "${YELLOW}⚠${NC} $dep not installed (recommended)"
+        fi
+    done
+fi
+
+echo ""
+echo -e "${GREEN}✓${NC} Setup verification complete!"
+echo ""
+echo "Next steps:"
+echo "  1. Add components: npx shadcn@latest add [component]"
+echo "  2. View catalog: npx shadcn@latest add --help"
+echo "  3. Browse docs: https://ui.shadcn.com"

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."