solmate-skills 1.0.2 → 2.0.1

package/{product-workflow → rules-product}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: product-workflow
+name: rules-product
 description: Orchestrates the full product development pipeline from planning to development docs. Diagnoses current project phase, checks gate conditions, 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.
 ---
 
@@ -10,11 +10,12 @@ You are a **workflow lead** who guides the user through the full product develop
 ## Pipeline Overview
 
 ```
-Phase 1: 기획문서       → plan-docs (Concept_Design)
-Phase 2: UI 설계 문서   → plan-docs (UI_Screens)
-Phase 3: 스티치 연결    → enhance-prompt → stitch-loop → design-md → stitch-loop 반복
-Phase 4: React 변환     → react-components
-Phase 5: 개발문서       → dev-docs
+Phase 1: 기획문서       → docs-plan (Concept_Design)
+Phase 2: UI 설계 문서   → docs-plan (UI_Screens)
+Phase 3: React 변환     → rules-react
+Phase 4: 개발문서       → docs-dev
+Phase 5: 품질 검증      → verify-implementation (verify-docs / verify-code / verify-security / verify-performance)
+Phase 6: 최종 전달물    → docs-pitch / docs-business (선택)
 ```
 
 ---
@@ -29,10 +30,9 @@ Run these checks in order:
 |-------|--------|---------|
 | `docs/01_Concept_Design/` 존재 여부 | 없으면 Phase 1 미완 | 기획문서 필요 |
 | `docs/02_UI_Screens/` 존재 여부 | 없으면 Phase 2 미완 | UI 설계 필요 |
-| Stitch project 또는 `stitch.json` 존재 여부 | 없으면 Phase 3 미완 | Stitch 연결 필요 |
-| `DESIGN.md` 존재 여부 | 없으면 Phase 3 미완 | design-md 미실행 |
-| `src/components/` 또는 React 코드 존재 여부 | 없으면 Phase 4 미완 | React 변환 필요 |
-| `docs/03_Technical_Specs/` 존재 여부 | 없으면 Phase 5 미완 | 개발문서 필요 |
+| `src/components/` 또는 React 코드 존재 여부 | 없으면 Phase 3 미완 | React 개발 필요 |
+| `docs/03_Technical_Specs/` 존재 여부 | 없으면 Phase 4 미완 | 개발문서 필요 |
+| verify-* 스킬 실행 이력 또는 사용자 확인 여부 | 없으면 Phase 5 미완 | 품질 검증 필요 |
 
 진단 결과를 다음 형식으로 보고한다:
 
@@ -60,9 +60,9 @@ Run these checks in order:
 **위임 지시**:
 
 ```
-사용할 스킬: plan-docs
+사용할 스킬: docs-plan
 작업 범위: Layer 1 (Concept_Design)
-필수 질문 선행: plan-docs의 Phase 1 질문 (Why / Who / What / How / Distribution / Layout&Brand)
+필수 질문 선행: docs-plan의 Phase 1 질문 (Why / Who / What / How / Distribution / Layout&Brand)
 ```
 
 Phase 1 완료 확인 후 다음을 묻는다:
@@ -82,8 +82,8 @@ Phase 1이 완료된 후 언제든 작성 가능하다. Phase 2 진입과 독립
 
 **위임 지시**:
 ```
-사용할 스킬: pitch-deck
-출력 모드 선택: Markdown / Reveal.js HTML / Stitch 중 하나
+사용할 스킬: docs-pitch
+출력 모드 선택: Markdown / Reveal.js HTML
 참조 문서: docs/01_Concept_Design/ 전체
 ```
 
@@ -95,15 +95,11 @@ Phase 1이 완료된 후 언제든 작성 가능하다. Phase 2 진입과 독립
 
 **위임 지시**:
 ```
-사용할 스킬: business-plan
+사용할 스킬: docs-business
 저장 경로: docs/01_Concept_Design/XX_BUSINESS_PLAN.md
 참조 문서: docs/01_Concept_Design/ 전체
 ```
 
-> 피치덱과 사업계획서는 같은 Phase 1 데이터를 소스로 사용하지만 목적과 독자가 다르다.
-> 피치덱 — 3-10분 발표, 투자자/심사위원 대상, 임팩트와 스토리 중심
-> 사업계획서 — 정식 문서, 정부/기관 대상, 구체적 수치와 실행 계획 중심
-
 ---
 
 ## Phase 2: UI 설계 문서 (UI_Screens)
@@ -120,129 +116,127 @@ Phase 1이 완료된 후 언제든 작성 가능하다. Phase 2 진입과 독립
 **위임 지시**:
 
 ```
-사용할 스킬: plan-docs
+사용할 스킬: docs-plan
 작업 범위: Layer 2 (UI_Screens)
 참조 문서: docs/01_Concept_Design/ 전체 읽기 후 시작
 ```
 
 Phase 2 완료 확인 후 다음을 묻는다:
-> "Phase 2 문서가 완성되었습니다. Phase 3(Stitch 화면 생성)으로 넘어갈까요?"
+> "Phase 2 문서가 완성되었습니다. Phase 3(React 변환 및 개발)으로 넘어갈까요?"
 
 ---
 
-## Phase 3: 스티치 연결 (Stitch Screen Generation)
+## Phase 3: React + Tailwind 개발
 
-**목표**: UI 설계 문서를 기반으로 Stitch에서 실제 화면을 생성하고, 디자인 시스템을 DESIGN.md로 추출한다.
+**목표**: UI 설계 문서를 기반으로 실제 React 컴포넌트와 페이지를 구현한다.
 
 **Gate In**:
 - Phase 2 문서 (`02_UI_Screens/`) 존재
 
 **Gate Out** (다음 단계 진입 조건):
-- [ ] Stitch project 생성 완료 (`stitch.json` 존재)
-- [ ] 주요 화면 최소 1개 이상 생성 완료
-- [ ] `DESIGN.md` 존재 (design-md 실행 완료)
+- [ ] `src/components/` 에 주요 컴포넌트 존재
+- [ ] `src/data/mockData.ts` 존재 (필요 시)
+- [ ] `npm run dev` 정상 작동 확인
 
-**실행 순서 (반드시 이 순서대로)**:
+**위임 지시**:
 
-### Step 3-1: 프롬프트 최적화
 ```
-사용할 스킬: enhance-prompt
-입력: 00_SCREEN_FLOW.md와 01_UI_DESIGN.md를 참조하여 첫 화면(주로 랜딩/홈)의 프롬프트 작성
-출력: next-prompt.md에 저장
+사용할 스킬: rules-react
+입력: docs/02_UI_Screens/ 의 화면 설계 및 디자인 가이드
+순서: 화면 중요도 순으로 처리 (홈 → 주요 기능 화면 → 기타)
 ```
 
-### Step 3-2: 첫 화면 생성
-```
-사용할 스킬: stitch-loop
-입력: next-prompt.md
-작업: 첫 화면 생성 및 stitch.json 저장
-```
+Phase 3 완료 확인 후 다음을 묻는다:
+> "Phase 3이 완료되었습니다. Phase 4(개발문서)로 넘어갈까요?"
 
-### Step 3-3: 디자인 시스템 추출
-```
-사용할 스킬: design-md
-입력: 방금 생성된 Stitch 화면
-출력: DESIGN.md (프로젝트 루트에 저장)
-목적: 이후 모든 stitch-loop 반복에서 디자인 일관성 유지
-```
+---
+
+## Phase 4: 개발문서 (Technical_Specs / Logic_Progress / QA_Validation)
+
+**목표**: 구현된 코드베이스를 기반으로 기술 명세, 로직 설계, QA 체크리스트를 작성한다.
+
+**Gate In**:
+- React 컴포넌트 구현 완료 (Phase 3)
+
+**Gate Out** (프로젝트 완성 조건):
+- [ ] `docs/03_Technical_Specs/00_DEVELOPMENT_PRINCIPLES.md` 존재
+- [ ] `docs/03_Technical_Specs/01_DB_SCHEMA.md` 존재 (DB 사용 시)
+- [ ] `docs/03_Technical_Specs/02_API_SPECS.md` 존재 (API 사용 시)
+- [ ] `docs/04_Logic_Progress/00_ROADMAP.md` 존재
+- [ ] `docs/05_QA_Validation/02_QA_CHECKLIST.md` 존재
+
+**위임 지시**:
 
-### Step 3-4: 나머지 화면 반복 생성
 ```
-사용할 스킬: stitch-loop (반복)
-조건: DESIGN.md의 디자인 시스템 블록을 모든 프롬프트에 포함
-참조: 00_SCREEN_FLOW.md의 화면 목록이 모두 완성될 때까지 반복
+사용할 스킬: docs-dev
+순서: Technical_Specs → Logic_Progress → QA_Validation
+시작 전: 코드베이스 분석 (아키텍처, 패턴, 스탠다드, 툴링)
 ```
 
-Phase 3 완료 확인:
-- `stitch.json` 존재
-- `DESIGN.md` 존재
-- `00_SCREEN_FLOW.md`에 정의된 주요 화면 커버 여부
-
-Phase 3 완료 확인 후 다음을 묻는다:
-> "Phase 3이 완료되었습니다. Phase 4(React + Tailwind 변환)으로 넘어갈까요?"
+Phase 4 완료 확인 후 다음을 묻는다:
+> "Phase 4 문서가 완성되었습니다. Phase 5(품질 검증)로 넘어갈까요?"
 
 ---
 
-## Phase 4: React + Tailwind 변환
+## Phase 5: Quality Gate (품질 검증)
 
-**목표**: Stitch에서 생성된 HTML 화면을 모듈화된 React 컴포넌트로 변환한다.
+**목표**: 코드·문서·보안·성능 전 영역을 통합 검증하여 배포 가능 수준임을 확인한다.
 
 **Gate In**:
-- Stitch project 존재 (`stitch.json`)
-- `DESIGN.md` 존재
+- Phase 4 문서 (`03_Technical_Specs/`, `04_Logic_Progress/`, `05_QA_Validation/`) 존재
+- React 코드 구현 완료 (Phase 3)
 
 **Gate Out** (다음 단계 진입 조건):
-- [ ] `src/components/` 에 주요 컴포넌트 존재
-- [ ] `src/data/mockData.ts` 존재
-- [ ] `npm run dev` 정상 작동 확인
+- [ ] `verify-docs` PASS — 문서 구조·메타데이터 정합성
+- [ ] `verify-code` PASS — 코드 품질 (로직, 타입, 중복, 사이드 이펙트)
+- [ ] `verify-security` PASS — OWASP Top 10 기준 보안 이슈 없음
+- [ ] `verify-performance` PASS — Lighthouse Performance 90+, Core Web Vitals 기준 충족
+- [ ] `verify-drizzle-schema` PASS — DB 스키마 정합성 (DB 사용 시)
 
 **위임 지시**:
 
 ```
-사용할 스킬: react-components
-입력: stitch.json의 projectId, 변환 대상 화면 목록
-주의: DESIGN.md의 Tailwind config를 style-guide.json에 동기화
-순서: 화면 중요도 순으로 처리 (홈 → 주요 기능 화면 → 기타)
+사용할 스킬: verify-implementation
+동작: 위 verify-* 스킬을 순차 실행하고 통합 보고서 생성
+FAIL 항목 발견 시: 해당 스킬로 돌아가 수정 후 재검증
 ```
 
-Phase 4 완료 확인 후 다음을 묻는다:
-> "Phase 4가 완료되었습니다. Phase 5(개발문서)로 넘어갈까요?"
+FAIL 항목이 있으면 해당 Phase로 되돌아가 수정 후 재실행한다. 모든 항목 PASS 확인 후 다음을 묻는다:
+> "모든 검증을 통과했습니다. Phase 6(최종 전달물)으로 넘어갈까요?"
 
 ---
 
-## Phase 5: 개발문서 (Technical_Specs / Logic_Progress / QA_Validation)
+## Phase 6: 최종 전달물 (선택)
 
-**목표**: 구현된 코드베이스를 기반으로 기술 명세, 로직 설계, QA 체크리스트를 작성한다.
+**목표**: 완성된 제품을 바탕으로 외부 커뮤니케이션 자료를 생성한다.
 
 **Gate In**:
-- React 컴포넌트 구현 완료 (Phase 4)
+- Phase 5 Quality Gate 전체 PASS
 
-**Gate Out** (프로젝트 완성 조건):
-- [ ] `docs/03_Technical_Specs/00_DEVELOPMENT_PRINCIPLES.md` 존재
-- [ ] `docs/03_Technical_Specs/01_DB_SCHEMA.md` 존재 (DB 사용 시)
-- [ ] `docs/03_Technical_Specs/02_API_SPECS.md` 존재 (API 사용 시)
-- [ ] `docs/04_Logic_Progress/00_ROADMAP.md` 존재
-- [ ] `docs/05_QA_Validation/02_QA_CHECKLIST.md` 존재
+**선택 항목** (하나 이상 선택, 복수 가능):
+
+| 전달물 | 사용 스킬 | 용도 |
+|--------|-----------|------|
+| 피치덱 | `docs-pitch` | 투자자·해커톤·데모데이 발표 자료 |
+| 사업계획서 | `docs-business` | 정부 지원·투자 심사·파트너십 문서 |
 
 **위임 지시**:
 
 ```
-사용할 스킬: dev-docs
-순서: Technical_Specs → Logic_Progress → QA_Validation
-시작 전: 코드베이스 분석 (아키텍처, 패턴, 스탠다드, 툴링)
+사용할 스킬: docs-pitch 또는 docs-business (사용자 선택)
+참조 문서: docs/01_Concept_Design/ + docs/03_Technical_Specs/ 전체
 ```
 
 전체 파이프라인 완료 후 최종 보고:
 
 ```
 전체 워크플로우 완료
-- Phase 1: docs/01_Concept_Design/ (기획문서)
-- Phase 2: docs/02_UI_Screens/ (UI 설계 문서)
-- Phase 3: DESIGN.md + Stitch 화면 생성 완료
-- Phase 4: src/components/ (React 컴포넌트)
-- Phase 5: docs/03_Technical_Specs/, 04_Logic_Progress/, 05_QA_Validation/
-
-검증 권장: /verify-docs, /verify-db (해당 시)
+- Phase 1: docs/01_Concept_Design/        기획문서
+- Phase 2: docs/02_UI_Screens/            UI 설계 문서
+- Phase 3: src/components/               React 컴포넌트
+- Phase 4: docs/03~05_*/                 개발·진행·QA 문서
+- Phase 5: verify-implementation PASS    품질 검증 완료
+- Phase 6: docs-pitch / docs-business    최종 전달물 (선택)
 ```
 
 ---
@@ -259,20 +253,16 @@ Phase 4 완료 확인 후 다음을 묻는다:
 
 사용자가 특정 Phase를 지정하면 해당 Phase의 Gate In 조건만 확인 후 바로 시작한다.
 
-```
-예: "Phase 3부터 시작하고 싶어요"
-→ Gate In 확인: docs/02_UI_Screens/ 존재 여부만 체크
-→ 바로 Step 3-1(enhance-prompt) 지시
-```
-
 ---
 
 ## Related Skills
 
-- **plan-docs**: Phase 1, 2 문서 작성
-- **enhance-prompt**: Phase 3 Stitch 프롬프트 최적화
-- **stitch-loop**: Phase 3 화면 반복 생성
-- **design-md**: Phase 3 디자인 시스템 추출
-- **react-components**: Phase 4 React 변환
-- **dev-docs**: Phase 5 기술 문서 작성
-- **verify-docs**: 전체 문서 구조 검증
+- **docs-plan**: Phase 1, 2 문서 작성
+- **rules-react**: Phase 3 React 개발
+- **docs-dev**: Phase 4 기술 문서 작성
+- **verify-implementation**: Phase 5 품질 검증 통합 실행
+- **verify-code**: Phase 5 코드 품질 리뷰
+- **verify-security**: Phase 5 보안 점검
+- **verify-performance**: Phase 5 성능 점검
+- **docs-pitch**: Phase 6 피치덱 작성
+- **docs-business**: Phase 6 사업계획서 작성

package/{react-components → rules-react}/README.md

@@ -17,7 +17,7 @@ Convert my Landing Page screen in my Podcast Stitch Project to a React component
 This repository follows the **Agent Skills** open standard. Each skill is self-contained with its own logic, validation scripts, and design tokens.
 
 ```text
-skills/react-components/
+skills/rules-react/
 ├── SKILL.md           — Core instructions & workflow
 ├── package.json       — Validator dependencies
 ├── scripts/           — Networking & AST validation

package/rules-react/SKILL.md

@@ -0,0 +1,39 @@
+---
+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.
+---
+
+# React Component Implementation Skill
+
+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.
+- **rules-dev**: Follow coding standards, file naming, and state management rules.
+- **Vercel Best Practices**: Follow the provided skills for performance and composition patterns.
+
+## 2. Architectural Rules
+* **Modular components**: Break the design into independent files. Avoid large, single-file outputs. Place shared components in `src/components/ui/` and feature-specific ones in their respective folders.
+* **Logic isolation**: Move complex event handlers and business logic into custom hooks in `src/hooks/`.
+* **Data decoupling**: Move all static text, image URLs, and lists into `src/data/mockData.ts` or appropriate JSON files. Use `generate_image` tool for visual assets instead of placeholders.
+* **Type safety**: Every component must include a `Readonly` TypeScript interface named `[ComponentName]Props`. Use Zod for runtime validation where necessary.
+* **Styling**: Use Vanilla CSS or TailwindCSS as defined in the project standard. Use theme-mapped variables instead of arbitrary hex codes.
+* **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**:
+    - Verify against accessibility standards.
+    - Check performance (avoid unnecessary re-renders).
+    - Ensure responsive design works across all target devices.
+    - Start the dev server with `npm run dev` to verify the live result.
+
+## 4. Related Skills
+- **docs-plan**: Source for UI design and screen flows.
+- **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.

package/rules-react/package.json

@@ -0,0 +1,15 @@
+{
+  "name": "rules-react",
+  "version": "1.0.0",
+  "description": "Design-to-code prompt to React components",
+  "type": "module",
+  "scripts": {
+    "validate": "node scripts/validate.js"
+  },
+  "dependencies": {
+    "@swc/core": "^1.3.100"
+  },
+  "engines": {
+    "node": ">=18.0.0"
+  }
+}

package/{implementation-workflow → rules-workflow}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: implementation-workflow
+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, or when the user asks for plan review, implementation review, deployment readiness check, or to follow the 18-step workflow (18단계). Ensures plan validation, implementation quality, side-effect checks, and deployment-ready quality.
 ---
 
-# Implementation Workflow (18 Steps)
+# Implementation & Execution Workflow (18 Steps)
 
 Follow this workflow for feature implementation and significant code changes. Complete each phase before advancing; use the checklists to avoid skipping steps.
 

package/{obsidian-sync → tools-obsidian}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: obsidian-sync
+name: tools-obsidian
 description: Manages the synchronization between the project's documentation and an Obsidian vault via symbolic links. Ensures metadata compatibility and provides tools to verify the link status.
 ---
 
@@ -40,5 +40,5 @@ If the project directory moves, the symlink MUST be recreated:
 `ln -sfn [NEW_PROJECT_PATH]/docs /Users/namhyeongseog/Documents/obsidian/Rural-Rest/docs`
 
 ## 5. Related Skills
-- **manage-docs**: The primary skill that generates the content being synced.
+- **rules-docs**: The primary skill that generates the content being synced.
 - **design-md**: Generates design-related documentation that will also be visible in Obsidian.

package/{shadcn-ui → tools-shadcn}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: shadcn-ui
+name: tools-shadcn
 description: Expert guidance for integrating and building applications with shadcn/ui components, including component discovery, installation, customization, and best practices.
 allowed-tools:
   - "shadcn*:*"

package/verify-code/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: verify-code
+description: PR 또는 커밋 전 코드 품질을 종합 리뷰합니다. 로직 오류, 타입 안전성, 중복 구현, 사이드 이펙트, 가독성, 불필요 코드를 체계적으로 검토합니다. 코드 작성 완료 후 커밋·PR 전, 또는 "코드 리뷰해줘", "PR 전 확인" 요청 시 사용합니다.
+argument-hint: "[선택사항: 리뷰할 파일 경로 또는 기능명]"
+---
+
+# 코드 리뷰 스킬 (verify-code)
+
+PR 또는 커밋 전 코드 품질을 종합적으로 점검합니다. 구현이 완료된 코드를 대상으로 아래 6개 영역을 순서대로 검토하고 발견된 이슈를 보고합니다.
+
+---
+
+## 실행 시점
+
+- 기능 구현 완료 후 커밋·PR 전
+- 다른 사람의 코드를 리뷰할 때
+- `rules-workflow` Step 14 (코드 품질 검토) 수행 시
+- "코드 좀 봐줘", "리뷰해줘" 요청 시
+
+---
+
+## Step 0: 리뷰 범위 확정
+
+인자가 주어진 경우 해당 파일/기능에 집중한다. 없으면 `git diff HEAD` 또는 `git diff main` 기준으로 변경된 파일 목록을 확인한 후 리뷰 범위를 사용자에게 보고하고 진행한다.
+
+```bash
+git diff --name-only HEAD
+```
+
+---
+
+## Area 1: 로직 정확성
+
+- 요구사항·기능 목적 대비 구현이 올바른지 확인한다.
+- 조건문·분기 처리에서 누락된 케이스(null, undefined, 빈 배열, 0 등)를 점검한다.
+- 비동기 처리(async/await, Promise)에서 에러 핸들링이 누락된 경로가 없는지 확인한다.
+- 체크:
+  - [ ] 핵심 시나리오가 의도대로 동작하는가?
+  - [ ] 엣지 케이스(빈 값, 경계값, 예외 입력)가 처리되었는가?
+  - [ ] 에러 핸들링이 빠진 비동기 경로가 없는가?
+
+---
+
+## Area 2: 타입 안전성
+
+- `any` 사용 여부를 확인하고 `unknown` 또는 구체 타입으로 대체 가능한지 검토한다.
+- 런타임 입력(API 응답, 폼 데이터, URL 파라미터)에 Zod 등 검증 로직이 적용되었는지 확인한다.
+- 타입 단언(`as`)이 근거 없이 사용된 경우를 지적한다.
+- 체크:
+  - [ ] `any` 사용이 정당화되었는가?
+  - [ ] 외부 입력에 런타임 검증이 적용되었는가?
+  - [ ] 불필요한 타입 단언(`as`)이 없는가?
+
+---
+
+## Area 3: 중복 및 재사용성
+
+- 동일하거나 유사한 로직이 여러 곳에 복사되어 있는지 확인한다.
+- 기존 유틸·훅·컴포넌트로 대체 가능한 새 구현이 있는지 점검한다.
+- 한 함수/컴포넌트가 두 가지 이상의 책임을 갖는지 확인한다.
+- 체크:
+  - [ ] 중복 구현이 없는가?
+  - [ ] 기존 코드를 재사용할 수 있는 경우가 없는가?
+  - [ ] 단일 책임 원칙이 지켜지는가?
+
+---
+
+## Area 4: 사이드 이펙트 및 회귀
+
+- 변경된 코드가 다른 기능·라우트·공유 상태에 의도치 않은 영향을 주는지 확인한다.
+- 전역 상태, Context, 공유 훅, 공통 유틸을 수정한 경우 영향 범위를 열거한다.
+- DB 쿼리·API 호출에 side effect(쓰기, 삭제)가 의도치 않게 추가되지 않았는지 확인한다.
+- 체크:
+  - [ ] 변경이 다른 기능에 영향을 주는 경우가 없는가?
+  - [ ] 공유 코드 수정 시 영향 범위를 파악했는가?
+  - [ ] 의도치 않은 쓰기/삭제 동작이 없는가?
+
+---
+
+## Area 5: 가독성 및 네이밍
+
+- 변수·함수·컴포넌트 이름이 역할을 명확히 반영하는지 확인한다.
+- 마법 숫자(magic number), 하드코딩된 문자열이 상수 또는 설정으로 분리되었는지 점검한다.
+- 함수 길이가 과도하게 길어 분할이 필요한 경우를 지적한다.
+- 체크:
+  - [ ] 이름만 보고 역할을 알 수 있는가?
+  - [ ] 마법 숫자·하드코딩된 값이 상수로 분리되었는가?
+  - [ ] 한 함수가 100줄을 넘지 않는가?
+
+---
+
+## Area 6: 불필요 코드 및 정리
+
+- `console.log`, `console.error` 등 디버그 출력이 남아 있는지 확인한다.
+- 사용하지 않는 `import`, 변수, 함수, 주석 처리된 코드 블록을 제거 대상으로 표시한다.
+- TODO/FIXME 주석 중 이번 작업에서 해결되지 않은 것을 목록화한다.
+- 체크:
+  - [ ] `console.*` 출력이 제거되었는가?
+  - [ ] 미사용 import·변수가 없는가?
+  - [ ] 주석 처리된 dead code가 없는가?
+
+---
+
+## 보고 형식
+
+리뷰 결과는 다음 형식으로 보고한다:
+
+```
+## 코드 리뷰 결과
+
+### PASS 항목
+- (문제 없는 영역 요약)
+
+### 개선 필요 항목
+| 위치 | 영역 | 내용 | 심각도 |
+|------|------|------|:------:|
+| src/foo.ts:42 | 타입 안전성 | API 응답에 any 사용 | 중 |
+| src/bar.tsx:15 | 불필요 코드 | console.log 미제거 | 낮음 |
+
+### 수정 권장 우선순위
+1. [높음] ...
+2. [중] ...
+3. [낮음] ...
+```
+
+심각도 기준: **높음** (배포 차단 수준) / **중** (품질 저하) / **낮음** (권장 사항)
+
+---
+
+## 관련 스킬
+
+- `rules-dev`: 프로젝트 코딩 컨벤션 기준
+- `rules-workflow`: Step 14 코드 품질 검토와 연동
+- `verify-security`: 보안 관련 이슈는 이 스킬로 위임

package/verify-docs/SKILL.md

@@ -12,7 +12,7 @@ description: 프로젝트 문서가 5단계 구조(01~05)와 메타데이터 표
 2. 메타데이터 표준 (Created / Last Updated)
 3. Related Documents 섹션
 4. Rubric-First Writing
-5. product-workflow Gate Out 조건
+5. rules-product Gate Out 조건
 
 ## 실행 시점
 
@@ -58,13 +58,14 @@ AGENTS.md 또는 `docs/01_Concept_Design/00_COLLABORATION_GUIDE.md`를 읽어
 | 레이어 | 기준 |
 |:---|:---|
 | QA_Validation (Layer 5) | 6개 루브릭 전체 테이블 포함 (필수) |
+| Logic_Progress (Layer 4) | 실무 문서(BACKLOG, ROADMAP, EXECUTION_PLAN) 내 체크박스`[ ]` 활용 및 원자적 단위 분할 (필수) |
 | Concept_Design (Layer 1) | Novelty, Business Plan, Potential Impact 언급 (권장) |
 | Technical_Specs (Layer 3) | Functionality, UX (latency), Open-source 언급 (권장) |
 | Logic_Progress (Layer 4) | Functionality, UX 언급 (권장) |
 
 ### Step 5: Gate Out 조건 검사
 
-product-workflow 기준으로 각 Phase의 필수 문서 존재 여부를 확인한다.
+rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한다.
 
 **Phase 1 (기획문서)**:
 - [ ] `docs/01_Concept_Design/01_VISION_CORE.md`