solmate-skills 2.0.7 → 2.0.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +11 -4
- package/README.md +40 -22
- package/package.json +13 -4
- package/rules-dev/SKILL.md +27 -1
- package/rules-dev/agents/openai.yaml +2 -2
- package/rules-workflow/SKILL.md +13 -8
- package/rules-workflow/agents/openai.yaml +2 -2
- package/verify-code/SKILL.md +26 -7
- package/verify-code/agents/openai.yaml +2 -2
- package/verify-implementation/SKILL.md +18 -6
- package/verify-implementation/agents/openai.yaml +2 -2
package/AGENTS.md
CHANGED
|
@@ -86,6 +86,13 @@
|
|
|
86
86
|
- **Git 관리**: 반드시 **Root Directory**에서 수행하여 문서와 코드를 통합 관리한다.
|
|
87
87
|
- **배포 설정**: 배포 서비스의 Root Directory를 **App Directory(`web/`)** 로 지정하거나, Build Command를 `cd web && npm run build` 등으로 설정한다.
|
|
88
88
|
|
|
89
|
+
### 3.2. YAGNI/KISS/DRY Gate (Minimal Implementation)
|
|
90
|
+
- **정본 위치**: 상세 기준은 `rules-dev/SKILL.md`의 `Minimal Implementation Gate (YAGNI / KISS / DRY)`를 따른다. 다른 스킬은 이 정본을 참조한다.
|
|
91
|
+
- **핵심 원칙**: 현재 문서·백로그·사용자 승인에 없는 미래용 기능·추상화는 만들지 않고, 기존 코드·표준/네이티브 기능·기존 의존성·최소 새 코드 순서로 해결한다.
|
|
92
|
+
- **DRY 기준**: 같은 지식과 같은 변경 이유를 가진 중복만 제거한다. 모양만 비슷한 코드는 억지로 추상화하지 않는다.
|
|
93
|
+
- **프로토타입 예외**: 프로토타입·스파이크·탐색 단계에서는 차단 조건이 아니라 기록성 체크로 적용한다.
|
|
94
|
+
- **안전 예외**: 검증, 인증·인가, 에러 처리, 접근성, 보안, 데이터 보존, 테스트 가능성은 단순화를 이유로 제거하지 않는다.
|
|
95
|
+
|
|
89
96
|
## 4. Skills & AI Capabilities
|
|
90
97
|
AI 에이전트는 본 프로젝트에 설치된 다음 **26개 스킬**을 활용하여 작업을 수행하며, 모든 작업 결과물은 이 스킬들의 검증 가이드를 통과해야 한다.
|
|
91
98
|
|
|
@@ -102,15 +109,15 @@ AI 에이전트는 본 프로젝트에 설치된 다음 **26개 스킬**을 활
|
|
|
102
109
|
| | `docs-dev` | Layer 3-5 기술·진행·QA 문서 작성 (DB 스키마, API, 백로그) |
|
|
103
110
|
| | `docs-pitch` | 피치덱 작성 (Markdown / Reveal.js HTML) |
|
|
104
111
|
| | `docs-business` | 사업계획서 작성 (정부 지원, 투자 심사, 파트너십 목적별 구성) |
|
|
105
|
-
| **품질 검증 (QA)** | `verify-implementation` | 모든 `verify-*` 스킬의 통합 순차 실행 및 보고 |
|
|
112
|
+
| **품질 검증 (QA)** | `verify-implementation` | 모든 `verify-*` 스킬의 통합 순차 실행 및 YAGNI/KISS/DRY Gate 보고 |
|
|
106
113
|
| | `verify-docs` | 문서 레이어 정합성 및 네이밍/메타데이터, UI-First Gate 검증 |
|
|
107
114
|
| | `verify-ui` | 구현 UI와 화면 문서·HTML Preview·사용자 동선·상태별 UI 정합성 검증 |
|
|
108
|
-
| | `verify-code` | PR 전 코드 품질 종합 리뷰 (로직, 타입, 중복, 사이드 이펙트) |
|
|
115
|
+
| | `verify-code` | PR 전 코드 품질 종합 리뷰 (로직, 타입, 중복, 과잉 구현, 사이드 이펙트) |
|
|
109
116
|
| | `verify-security` | OWASP Top 10 기준 보안 취약점 점검 (인증, 인젝션, 시크릿 노출 등) |
|
|
110
117
|
| | `verify-performance` | Lighthouse·Core Web Vitals 기준 성능 점검 (LCP, CLS, 번들, 이미지) |
|
|
111
118
|
| | `verify-drizzle-schema` | Drizzle 스키마 설계 정합성 및 기술 표준 검증 |
|
|
112
119
|
| | `verify-skills` | 스킬 패키지 메타데이터·CLI·README/AGENTS·패키징 검증 |
|
|
113
|
-
| **개발 및 설계** | `rules-dev` | 코딩
|
|
120
|
+
| **개발 및 설계** | `rules-dev` | 코딩 표준, 프로젝트 컨벤션, YAGNI/KISS/DRY Gate 준수 여부 확인 |
|
|
114
121
|
| | `rules-react` | UI 컴포넌트 설계 및 구현 표준 가이드 |
|
|
115
122
|
| | `rules-product` | 기획→UI→React→개발문서 전체 파이프라인 오케스트레이션 |
|
|
116
123
|
| **특수 도구(Tools)** | `tools-shadcn` | shadcn/ui 라이브러리 활용 및 커스텀 가이드 |
|
|
@@ -135,7 +142,7 @@ AI 에이전트는 사용자가 스킬을 호출하지 않아도, 아래 상황
|
|
|
135
142
|
| DB 스키마·API 명세·백로그 작성 요청 | `docs-dev` | "Layer 3-5 문서 작성은 `/docs-dev`를 사용하세요." |
|
|
136
143
|
| Drizzle 스키마 파일 수정 | `verify-drizzle-schema` | "스키마 변경 후 `/verify-drizzle-schema`로 정합성을 검증하세요." |
|
|
137
144
|
| 스킬 파일·CLI·패키지 메타데이터 수정 | `verify-skills` | "스킬 패키지 변경입니다. `/verify-skills`로 메타데이터와 패키징을 검증하세요." |
|
|
138
|
-
| 기능 구현 시작 전 | `rules-product`, `rules-workflow` | "먼저 `/rules-product`로 현재 단계를 진단한 뒤 `/rules-workflow`로 구현을 진행하세요." |
|
|
145
|
+
| 기능 구현 시작 전 | `rules-product`, `rules-workflow` | "먼저 `/rules-product`로 현재 단계를 진단한 뒤 `/rules-workflow`로 YAGNI/KISS/DRY Gate를 포함해 구현을 진행하세요." |
|
|
139
146
|
| 새 프로젝트 또는 단계 전환 | `rules-product` | "현재 단계를 진단하려면 `/rules-product`를 실행하세요." |
|
|
140
147
|
|
|
141
148
|
**제안 방식**:
|
package/README.md
CHANGED
|
@@ -1,41 +1,59 @@
|
|
|
1
1
|
# solmate-skills
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Reusable AI-agent skills for disciplined product work.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
`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.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
Use it when you want an AI coding agent to follow a shared workflow instead of improvising project structure, documentation, implementation order, and QA.
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
## Install
|
|
10
10
|
|
|
11
|
-
|
|
12
|
-
- UI, user paths, data flow, loading states, empty states, and error states must be confirmed before coding.
|
|
13
|
-
- UI planning must include HTML preview files under `docs/02_UI_Screens/previews/` and link them from the related UI documents.
|
|
14
|
-
- User journey SVG files belong in `docs/02_UI_Screens/assets/`.
|
|
15
|
-
- Data flow SVG files belong in `docs/03_Technical_Specs/assets/`.
|
|
16
|
-
- `/rules-workflow` now treats linked backlog documents as implementation inputs before coding starts.
|
|
17
|
-
- `/verify-docs` fails backlog items that omit required related-document fields.
|
|
18
|
-
- Local Codex settings under `.codex/` are excluded from the npm package, while skill-owned shell scripts remain publishable.
|
|
19
|
-
|
|
20
|
-
## Installation
|
|
21
|
-
|
|
22
|
-
You don't need to install this package globally. Simply use `npx`:
|
|
11
|
+
You do not need a global install. Run it with `npx` from the root of the project where you want the skills installed:
|
|
23
12
|
|
|
24
13
|
```bash
|
|
25
14
|
# List available skills
|
|
26
|
-
npx solmate-skills list
|
|
15
|
+
npx solmate-skills@latest list
|
|
27
16
|
|
|
28
|
-
# Install
|
|
17
|
+
# Install every skill
|
|
29
18
|
npx solmate-skills@latest install all
|
|
30
19
|
|
|
20
|
+
# Install one skill
|
|
21
|
+
npx solmate-skills@latest install rules-product
|
|
22
|
+
|
|
31
23
|
# Install proactive hook suggestions for Claude Code projects
|
|
32
24
|
npx solmate-skills@latest install hooks
|
|
33
|
-
|
|
34
|
-
# Install a specific skill
|
|
35
|
-
npx solmate-skills install rules-docs
|
|
36
25
|
```
|
|
37
26
|
|
|
38
|
-
|
|
27
|
+
The installer copies each selected skill folder into `.agent/skills/<skill-name>` in your current project.
|
|
28
|
+
|
|
29
|
+
## What You Get
|
|
30
|
+
|
|
31
|
+
- **Product workflow orchestration**: `/rules-product` diagnoses the current phase and routes the agent to the right next skill.
|
|
32
|
+
- **UI-first planning**: `/docs-plan` creates concept and screen documents before implementation starts.
|
|
33
|
+
- **HTML UI Preview Gate**: major screens and flows must have browser-viewable HTML previews under `docs/02_UI_Screens/previews/`.
|
|
34
|
+
- **Backlog Context Lock**: every backlog item must link the Concept, UI, HTML Preview, Technical Spec, and QA documents needed for implementation.
|
|
35
|
+
- **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.
|
|
36
|
+
- **Implementation workflow**: `/rules-workflow` keeps coding work tied to approved documents, preconditions, and acceptance criteria.
|
|
37
|
+
- **Release verification**: `/verify-implementation` runs the verification family for docs, UI, code, security, performance, DB schema, and skill package readiness.
|
|
38
|
+
|
|
39
|
+
## What's New in 2.0.9
|
|
40
|
+
|
|
41
|
+
`solmate-skills@2.0.9` adds a YAGNI/KISS/DRY Gate across development, workflow, and verification skills so agents avoid overengineering before and after implementation.
|
|
42
|
+
|
|
43
|
+
Recent workflow guardrails:
|
|
44
|
+
|
|
45
|
+
- Every backlog task must link to related Concept, UI, HTML Preview, Technical Spec, and QA documents.
|
|
46
|
+
- UI planning must include HTML preview files under `docs/02_UI_Screens/previews/` and link them from the related UI documents.
|
|
47
|
+
- Implementation must use `rules-dev` as the canonical Minimal Implementation Gate before adding new code.
|
|
48
|
+
- Prototype, spike, and exploration work applies the Gate as an advisory check, while safety exceptions still apply.
|
|
49
|
+
- `verify-code` now reports future-only abstractions, unnecessary providers/factories/interfaces, avoidable dependencies, and premature DRY abstractions.
|
|
50
|
+
- UI, user paths, data flow, loading states, empty states, and error states must be confirmed before coding.
|
|
51
|
+
- User journey SVG files belong in `docs/02_UI_Screens/assets/`.
|
|
52
|
+
- Data flow SVG files belong in `docs/03_Technical_Specs/assets/`.
|
|
53
|
+
- `/rules-workflow` treats linked backlog documents as implementation inputs before coding starts.
|
|
54
|
+
- `/verify-docs` fails backlog items that omit required related-document fields.
|
|
55
|
+
|
|
56
|
+
## Install Details
|
|
39
57
|
|
|
40
58
|
`install all` installs only skill folders that contain `SKILL.md`. Use `install hooks` separately when you want prompt/file-change suggestions that nudge the agent toward `/rules-product`, `/rules-workflow`, and the relevant `verify-*` skills.
|
|
41
59
|
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "solmate-skills",
|
|
3
|
-
"version": "2.0.
|
|
4
|
-
"description": "
|
|
3
|
+
"version": "2.0.9",
|
|
4
|
+
"description": "AI workflow skills for UI-first planning, YAGNI/KISS/DRY gates, docs, QA, and Solmate projects",
|
|
5
5
|
"main": "bin/cli.js",
|
|
6
6
|
"bin": {
|
|
7
7
|
"solmate-skills": "bin/cli.js"
|
|
@@ -10,9 +10,18 @@
|
|
|
10
10
|
"test": "echo \"Error: no test specified\" && exit 1"
|
|
11
11
|
},
|
|
12
12
|
"keywords": [
|
|
13
|
-
"skills",
|
|
13
|
+
"ai-skills",
|
|
14
|
+
"codex",
|
|
15
|
+
"claude",
|
|
16
|
+
"workflow",
|
|
17
|
+
"documentation",
|
|
18
|
+
"ui-first",
|
|
19
|
+
"yagni",
|
|
20
|
+
"kiss",
|
|
21
|
+
"dry",
|
|
22
|
+
"qa",
|
|
14
23
|
"solmate",
|
|
15
|
-
"
|
|
24
|
+
"skills",
|
|
16
25
|
"automation"
|
|
17
26
|
],
|
|
18
27
|
"author": "",
|
package/rules-dev/SKILL.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: rules-dev
|
|
3
|
-
description: Apply development setup, coding conventions, and quality
|
|
3
|
+
description: Apply development setup, coding conventions, YAGNI/KISS/DRY minimal implementation rules, and quality standards when writing code, configuring environment, or reviewing implementation. Use when the user asks about dev setup, coding standards, commit rules, env vars, DB safety, avoiding overengineering, or "what to follow when developing." Includes framework-specific patterns for Next.js, React Router v7, and React (SPA/Vite). Always align with project AGENTS.md and any DEVELOPMENT_PRINCIPLES document.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Rules Development Skill (Coding Conventions)
|
|
@@ -62,6 +62,29 @@ This skill defines **development setup**, **conventions to follow**, and **prohi
|
|
|
62
62
|
- **모노레포 원칙**: 한 저장소에서 **관리(문서·Git·설정)** 와 **구현(소스·빌드)** 을 함께 둘 때 다음을 지킨다. (1) **루트 디렉터리** = 관리 영역. `docs/`, `AGENTS.md`, 설정 파일 등. (2) **앱 디렉터리** = 구현 영역. 소스 코드, `package.json`, 빌드 산출물. (3) **Git 작업**은 루트에서 수행해 문서와 코드를 통합 관리. (4) **배포** 시 빌드·서빙 루트는 앱 디렉터리로 지정(예: Vercel root = `web`).
|
|
63
63
|
- **앱 디렉터리 이름**: 구현용 폴더 이름은 **`web`** 으로 통일한다. 루트 바로 아래 `web/` 에 프론트엔드(또는 풀스택) 앱을 두고, 배포 루트도 `web` 으로 설정한다. 프로젝트 사정으로 다른 이름(예: `app`, `frontend`)을 쓸 경우에는 `00_DEVELOPMENT_PRINCIPLES.md` 에 "앱 디렉터리: app" 처럼 명시한다.
|
|
64
64
|
|
|
65
|
+
### 3.5. Minimal Implementation Gate (YAGNI / KISS / DRY)
|
|
66
|
+
|
|
67
|
+
이 섹션이 YAGNI/KISS/DRY Gate의 정본이다. `rules-workflow`, `verify-code`, `verify-implementation`, AGENTS 문서는 이 기준을 참조하고, 같은 사다리 정의를 복제하지 않는다.
|
|
68
|
+
|
|
69
|
+
구현 전 다음 순서로 과잉 구현을 차단한다.
|
|
70
|
+
|
|
71
|
+
1. **YAGNI**: 현재 요구사항·문서·백로그에 없는 미래용 기능, 설정, 확장 포인트, provider/factory/interface를 만들지 않는다.
|
|
72
|
+
2. **기존 코드 우선**: 이미 있는 유틸, 훅, 컴포넌트, API, 스키마로 해결되는지 먼저 확인한다.
|
|
73
|
+
3. **표준/네이티브 우선**: 표준 라이브러리, 브라우저/런타임 내장 API, 프레임워크 기본 기능으로 해결되는지 확인한다.
|
|
74
|
+
4. **기존 의존성 우선**: 새 패키지 설치 전에 이미 설치된 의존성으로 충분한지 확인한다.
|
|
75
|
+
5. **최소 코드**: 새 구현이 필요하면 승인된 acceptance criteria를 만족하는 가장 작은 변경으로 끝낸다.
|
|
76
|
+
6. **DRY는 의미 기준**: 같은 지식과 같은 변경 이유를 가진 중복만 추출한다. 모양만 비슷한 코드를 premature abstraction으로 묶지 않는다.
|
|
77
|
+
|
|
78
|
+
다음은 기본적으로 금지한다:
|
|
79
|
+
|
|
80
|
+
- 구현체가 하나뿐인 interface, strategy, provider, factory.
|
|
81
|
+
- 현재 쓰이지 않는 옵션, 플래그, 환경변수, 설정 파일.
|
|
82
|
+
- 미래 확장을 위한 디렉터리·레이어·adapter.
|
|
83
|
+
- 표준 API로 충분한데 추가하는 포맷터, 파서, 날짜/문자열 유틸.
|
|
84
|
+
- 문서와 백로그에 없는 "나중에 필요할 수 있는" 기능.
|
|
85
|
+
|
|
86
|
+
프로토타입·스파이크·탐색 단계에서는 이 Gate를 차단 조건이 아니라 기록성 체크로 적용한다. 단, 검증, 인증·인가, 에러 처리, 접근성, 보안, 데이터 보존, 테스트 가능성은 단순화를 이유로 제거하지 않는다.
|
|
87
|
+
|
|
65
88
|
---
|
|
66
89
|
|
|
67
90
|
## 4. Prohibitions & Safety
|
|
@@ -74,6 +97,7 @@ This skill defines **development setup**, **conventions to follow**, and **prohi
|
|
|
74
97
|
| 임시 패치(Quick-fix) | 기술 부채·재발. 공식·표준 방식으로 해결. |
|
|
75
98
|
| 추측 기반 답변 | "아마 그럴 것이다" 금지. 도구로 상태 검증 후 답변. |
|
|
76
99
|
| 승인 없이 코드 수정 | 수정 계획 보고 후 명시적 승인을 받은 뒤 진행. |
|
|
100
|
+
| 미래용 추상화 | 현재 요구사항 없이 복잡도만 증가. YAGNI/KISS 위반. |
|
|
77
101
|
|
|
78
102
|
### 4.2. Database
|
|
79
103
|
|
|
@@ -85,6 +109,7 @@ This skill defines **development setup**, **conventions to follow**, and **prohi
|
|
|
85
109
|
- **console.log**: 배포/머지 전 디버깅용 로그 제거. 필요 시 로거/환경 분기 사용.
|
|
86
110
|
- **불필요한 주석**: 과도한 주석·죽은 코드 제거. 복잡한 로직만 의도·동작을 주석 또는 문서로 남긴다.
|
|
87
111
|
- **API/인증 수정 시**: 권한 검사(Guard Clause) 존재 여부를 다시 확인한다.
|
|
112
|
+
- **과잉 구현**: 새 추상화·새 의존성·새 설정을 추가하기 전에 Minimal Implementation Gate 통과 근거를 남긴다.
|
|
88
113
|
|
|
89
114
|
---
|
|
90
115
|
|
|
@@ -129,6 +154,7 @@ This skill defines **development setup**, **conventions to follow**, and **prohi
|
|
|
129
154
|
## 8. Execution Summary
|
|
130
155
|
|
|
131
156
|
- 코드/설정을 건드리기 전: **AGENTS.md** 및 **00_DEVELOPMENT_PRINCIPLES.md**(있으면) 확인.
|
|
157
|
+
- 구현 전: **YAGNI/KISS/DRY Gate**로 기존 코드·표준/네이티브 기능·기존 의존성·최소 코드 순서를 확인.
|
|
132
158
|
- env 추가/변경 시: `.gitignore` 확인, 로컬/운영 분리 유지.
|
|
133
159
|
- DB 작업 전: 백업 후 진행, 파괴적 명령 금지.
|
|
134
160
|
- 커밋 시: `type(scope): subject` + 한글, 3줄 이상 상세.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "Development Rules"
|
|
3
|
-
short_description: "Apply coding
|
|
4
|
-
default_prompt: "Use $rules-dev to check development conventions before editing
|
|
3
|
+
short_description: "Apply coding rules and minimal gates"
|
|
4
|
+
default_prompt: "Use $rules-dev to check development conventions and YAGNI/KISS/DRY gates before editing code."
|
package/rules-workflow/SKILL.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: rules-workflow
|
|
3
|
-
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 following the 18-step workflow. Requires product phase preflight, HTML UI Preview Gate, UI-First Gate, Backlog Context Lock, implementation quality checks, and deployment readiness.
|
|
3
|
+
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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Implementation & Execution Workflow (18 Steps)
|
|
@@ -11,7 +11,7 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
11
11
|
|
|
12
12
|
## Step 0: Product Phase Preflight
|
|
13
13
|
|
|
14
|
-
기능 구현을 시작하기 전, 먼저 `rules-product` 기준으로 현재 프로젝트 Phase를 진단한다. Concept, UI, HTML UI Preview Gate, UI-First Gate, Pre-Code Technical Brief 중 하나라도 누락되어 구현 판단이 불안정하면 코딩을 시작하지 않고 해당
|
|
14
|
+
기능 구현을 시작하기 전, 먼저 `rules-product` 기준으로 현재 프로젝트 Phase를 진단한다. Concept, UI, HTML UI Preview Gate, UI-First Gate, Pre-Code Technical Brief 중 하나라도 누락되어 구현 판단이 불안정하면 코딩을 시작하지 않고 해당 문서·백로그·계획 보완을 제안한다. YAGNI/KISS/DRY는 독립 게이트로 늘리지 않고 Step 4의 최소 구현 검토에서 확인한다.
|
|
15
15
|
|
|
16
16
|
- 체크: [ ] 현재 Phase를 진단했는가? [ ] HTML UI Preview Gate가 충족되었는가? [ ] UI-First Gate가 충족되었는가? [ ] 최소 기술 계약이 확인되었는가?
|
|
17
17
|
|
|
@@ -27,6 +27,7 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
27
27
|
- 코드 작성보다 먼저 HTML UI Preview Gate를 확인한다. `docs/02_UI_Screens/previews/`의 HTML Preview가 없거나 UI 문서에 링크되지 않았거나 사용자 확인 기록이 없으면 구현 계획을 보류하고 `docs-plan` 문서/HTML 보완을 제안한다.
|
|
28
28
|
- 그 다음 UI-First Gate를 확인한다. 화면 구조, 사용자 동선, 데이터 흐름, 로딩·빈 상태·오류 상태가 문서화되지 않았으면 구현 계획을 보류하고 `docs-plan` 또는 `docs-dev` 문서 보완을 제안한다.
|
|
29
29
|
- Pre-Code Technical Brief를 확인한다. 데이터 소스, 최소 필드, mutation, 상태 관리 방식, acceptance criteria가 불명확하면 구현 전에 사용자와 합의한다.
|
|
30
|
+
- Step 4에서 `rules-dev`의 Minimal Implementation Gate 정본을 기준으로 과잉 구현 후보를 확인한다.
|
|
30
31
|
- 변경할 파일·추가할 컴포넌트·API·DB 영향 범위를 나열한다.
|
|
31
32
|
- 체크: [ ] 목적이 명확한가? [ ] 관련 문서를 읽었는가? [ ] HTML UI Preview를 확인했는가? [ ] UI-First Gate가 확인되었는가? [ ] 최소 기술 계약이 확인되었는가? [ ] 영향 범위가 정리되었는가?
|
|
32
33
|
|
|
@@ -38,9 +39,11 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
38
39
|
- Step 2 검토 결과를 한 번 더 점검한다. "검토가 올바르게 되었는가?"를 질문으로 확인한다.
|
|
39
40
|
- 체크: [ ] 검토 기준이 일관되었는가? [ ] 반대 관점(예: 제거/롤백)도 고려했는가?
|
|
40
41
|
|
|
41
|
-
### Step 4. 계획 과도성 검토
|
|
42
|
+
### Step 4. 계획 과도성 및 최소 구현 검토
|
|
42
43
|
- 범위가 과도하게 크지 않은지 확인한다. 필요하면 단계로 나누거나 MVP로 줄인다.
|
|
43
|
-
-
|
|
44
|
+
- `rules-dev`의 `Minimal Implementation Gate (YAGNI / KISS / DRY)` 정본을 기준으로 최소 구현 여부를 확인한다.
|
|
45
|
+
- 프로토타입·스파이크·탐색 단계에서는 차단 조건이 아니라 기록성 체크로 적용한다. 단, 안전 예외는 그대로 유지한다.
|
|
46
|
+
- 체크: [ ] 한 번에 할 양이 적정한가? [ ] 나누어 진행할 수 있는가? [ ] rules-dev Minimal Implementation Gate 기준을 확인했는가?
|
|
44
47
|
|
|
45
48
|
---
|
|
46
49
|
|
|
@@ -51,8 +54,9 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
51
54
|
- 코드 작성 전 백로그 항목의 `Implementation Preconditions`와 `Acceptance Criteria`를 확인한다. 관련 문서 링크가 비어 있거나 `N/A - 사유`가 부실하면 구현을 보류하고 문서 보완 필요 여부를 사용자에게 확인한다.
|
|
52
55
|
- HTML UI Preview Gate가 통과되지 않았거나 사용자가 HTML Preview를 확인하지 않았다면 구현을 시작하지 않는다.
|
|
53
56
|
- UI-First Gate가 통과되지 않았거나 사용자가 화면/UI를 먼저 확인하지 않았다면 구현을 시작하지 않는다.
|
|
57
|
+
- 비프로토타입 작업에서 `rules-dev`의 Minimal Implementation Gate를 통과하지 못했다면 구현을 시작하지 않는다. 새 추상화·새 의존성·새 설정이 필요하면 현재 요구사항 근거를 먼저 설명한다.
|
|
54
58
|
- 구현을 시작하기 직전에 `Flow Status Block`을 출력하고, 현재 위치가 `Phase 3 — React 변환` 또는 해당 기능 구현 단계인지 명시한다.
|
|
55
|
-
- 체크: [ ] 계획 대비 변경 사항이 일치하는가? [ ] 백로그의 관련 문서 기준을 반영했는가? [ ] HTML Preview 확인 후 구현했는가? [ ] 화면·동선·데이터 흐름 확인 후 구현했는가?
|
|
59
|
+
- 체크: [ ] 계획 대비 변경 사항이 일치하는가? [ ] 백로그의 관련 문서 기준을 반영했는가? [ ] HTML Preview 확인 후 구현했는가? [ ] 화면·동선·데이터 흐름 확인 후 구현했는가? [ ] 최소 구현 원칙을 지켰는가?
|
|
56
60
|
|
|
57
61
|
---
|
|
58
62
|
|
|
@@ -76,7 +80,8 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
76
80
|
|
|
77
81
|
### Step 10. 기존 코드 통합·재사용 검토
|
|
78
82
|
- 새로 작성한 부분과 기존 코드의 통합 지점을 확인한다. 재사용 가능한 컴포넌트·유틸이 있으면 활용했는지 검토한다.
|
|
79
|
-
-
|
|
83
|
+
- DRY 기준은 `rules-dev`의 Minimal Implementation Gate 정본을 따른다.
|
|
84
|
+
- 체크: [ ] 중복 구현 없음 [ ] 기존 패턴·API와 정합성 [ ] premature abstraction 없음
|
|
80
85
|
|
|
81
86
|
---
|
|
82
87
|
|
|
@@ -88,7 +93,7 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
88
93
|
|
|
89
94
|
### Step 12. 전체 변경 사항 재검토
|
|
90
95
|
- diff·변경 파일 목록을 기준으로 전체를 한 번 더 훑는다. 누락·과도한 변경이 없는지 확인한다.
|
|
91
|
-
- 체크: [ ] 변경 집합이 목적과 일치 [ ] 불필요한 파일/코드 포함 여부
|
|
96
|
+
- 체크: [ ] 변경 집합이 목적과 일치 [ ] 불필요한 파일/코드 포함 여부 [ ] 미래용 코드·설정 없음
|
|
92
97
|
|
|
93
98
|
### Step 13. 불필요 코드 정리
|
|
94
99
|
- 구현 과정에서 불필요해진 코드(주석, 디버그 로그, 사용하지 않는 import/변수)를 제거한다.
|
|
@@ -134,7 +139,7 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
134
139
|
| 1 | 계획 수립 | [ ] |
|
|
135
140
|
| 2 | 계획 검토 | [ ] |
|
|
136
141
|
| 3 | 검토 정합성 확인 | [ ] |
|
|
137
|
-
| 4 | 계획 과도성 검토 | [ ] |
|
|
142
|
+
| 4 | 계획 과도성 및 최소 구현 검토 | [ ] |
|
|
138
143
|
| 5 | 구현 | [ ] |
|
|
139
144
|
| 6 | 목적 부합 검토 | [ ] |
|
|
140
145
|
| 7 | 버그·크리티컬·보안 검토 | [ ] |
|
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "Implementation Workflow"
|
|
3
|
-
short_description: "Follow
|
|
4
|
-
default_prompt: "Use $rules-workflow to plan, implement, verify, and prepare this feature for shipping."
|
|
3
|
+
short_description: "Follow implementation with minimal gates"
|
|
4
|
+
default_prompt: "Use $rules-workflow to plan, apply YAGNI/KISS/DRY gates, implement, verify, and prepare this feature for shipping."
|
package/verify-code/SKILL.md
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: verify-code
|
|
3
|
-
description: PR 또는 커밋 전 코드 품질을 종합 리뷰합니다. 로직 오류, 타입 안전성, 중복 구현, 사이드 이펙트, 가독성, 불필요 코드를 체계적으로 검토합니다. 코드 작성 완료 후 커밋·PR 전, 또는 "코드 리뷰해줘", "PR 전 확인" 요청 시 사용합니다.
|
|
3
|
+
description: PR 또는 커밋 전 코드 품질을 종합 리뷰합니다. 로직 오류, 타입 안전성, YAGNI/KISS/DRY 위반, 중복 구현, 과잉 추상화, 사이드 이펙트, 가독성, 불필요 코드를 체계적으로 검토합니다. 코드 작성 완료 후 커밋·PR 전, 또는 "코드 리뷰해줘", "PR 전 확인", "과잉 구현 확인" 요청 시 사용합니다.
|
|
4
4
|
argument-hint: "[선택사항: 리뷰할 파일 경로 또는 기능명]"
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# 코드 리뷰 스킬 (verify-code)
|
|
8
8
|
|
|
9
|
-
PR 또는 커밋 전 코드 품질을 종합적으로 점검합니다. 구현이 완료된 코드를 대상으로 아래
|
|
9
|
+
PR 또는 커밋 전 코드 품질을 종합적으로 점검합니다. 구현이 완료된 코드를 대상으로 아래 8개 영역을 순서대로 검토하고 발견된 이슈를 보고합니다.
|
|
10
10
|
|
|
11
11
|
---
|
|
12
12
|
|
|
@@ -53,7 +53,25 @@ git diff --name-only HEAD
|
|
|
53
53
|
|
|
54
54
|
---
|
|
55
55
|
|
|
56
|
-
## Area 3:
|
|
56
|
+
## Area 3: YAGNI/KISS/DRY 및 과잉 구현
|
|
57
|
+
|
|
58
|
+
- `rules-dev`의 `Minimal Implementation Gate (YAGNI / KISS / DRY)` 정본을 기준으로 변경된 코드를 검토한다.
|
|
59
|
+
- 현재 요구사항에 없는 미래용 코드, 단일 구현체 추상화, 피할 수 있는 새 의존성, premature abstraction을 발견하면 아래 태그로 보고한다.
|
|
60
|
+
- 프로토타입·스파이크·탐색 단계의 코드는 정보성으로 표시하되, 검증·보안·에러 처리·접근성·데이터 보존 관련 안전 예외 위반은 Fail로 처리한다.
|
|
61
|
+
- 태그:
|
|
62
|
+
- `delete`: 요구사항에 없는 코드이므로 제거 권장
|
|
63
|
+
- `stdlib`: 표준 라이브러리로 대체 권장
|
|
64
|
+
- `native`: 브라우저/런타임/프레임워크 기본 기능으로 대체 권장
|
|
65
|
+
- `yagni`: 미래 가능성만 근거인 기능·추상화
|
|
66
|
+
- `shrink`: 더 작은 구현으로 축소 권장
|
|
67
|
+
- 체크:
|
|
68
|
+
- [ ] `rules-dev` 정본 기준으로 과잉 구현이 없는가?
|
|
69
|
+
- [ ] 프로토타입·스파이크 예외 적용 여부가 명확한가?
|
|
70
|
+
- [ ] 안전 예외 위반이 없는가?
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## Area 4: 중복 및 재사용성
|
|
57
75
|
|
|
58
76
|
- 동일하거나 유사한 로직이 여러 곳에 복사되어 있는지 확인한다.
|
|
59
77
|
- 기존 유틸·훅·컴포넌트로 대체 가능한 새 구현이 있는지 점검한다.
|
|
@@ -65,7 +83,7 @@ git diff --name-only HEAD
|
|
|
65
83
|
|
|
66
84
|
---
|
|
67
85
|
|
|
68
|
-
## Area
|
|
86
|
+
## Area 5: 사이드 이펙트 및 회귀
|
|
69
87
|
|
|
70
88
|
- 변경된 코드가 다른 기능·라우트·공유 상태에 의도치 않은 영향을 주는지 확인한다.
|
|
71
89
|
- 전역 상태, Context, 공유 훅, 공통 유틸을 수정한 경우 영향 범위를 열거한다.
|
|
@@ -77,7 +95,7 @@ git diff --name-only HEAD
|
|
|
77
95
|
|
|
78
96
|
---
|
|
79
97
|
|
|
80
|
-
## Area
|
|
98
|
+
## Area 6: 가독성 및 네이밍
|
|
81
99
|
|
|
82
100
|
- 변수·함수·컴포넌트 이름이 역할을 명확히 반영하는지 확인한다.
|
|
83
101
|
- 마법 숫자(magic number), 하드코딩된 문자열이 상수 또는 설정으로 분리되었는지 점검한다.
|
|
@@ -89,7 +107,7 @@ git diff --name-only HEAD
|
|
|
89
107
|
|
|
90
108
|
---
|
|
91
109
|
|
|
92
|
-
## Area
|
|
110
|
+
## Area 7: 불필요 코드 및 정리
|
|
93
111
|
|
|
94
112
|
- `console.log`, `console.error` 등 디버그 출력이 남아 있는지 확인한다.
|
|
95
113
|
- 사용하지 않는 `import`, 변수, 함수, 주석 처리된 코드 블록을 제거 대상으로 표시한다.
|
|
@@ -101,7 +119,7 @@ git diff --name-only HEAD
|
|
|
101
119
|
|
|
102
120
|
---
|
|
103
121
|
|
|
104
|
-
## Area
|
|
122
|
+
## Area 8: UI-First 구현 정합성
|
|
105
123
|
|
|
106
124
|
TSX/JSX 화면 또는 컴포넌트 변경이 있으면 `docs/02_UI_Screens/`와 관련 백로그를 확인한다. 상세 UI 검증이 필요하면 `verify-ui`로 위임한다.
|
|
107
125
|
|
|
@@ -129,6 +147,7 @@ TSX/JSX 화면 또는 컴포넌트 변경이 있으면 `docs/02_UI_Screens/`와
|
|
|
129
147
|
| 위치 | 영역 | 내용 | 심각도 |
|
|
130
148
|
|------|------|------|:------:|
|
|
131
149
|
| src/foo.ts:42 | 타입 안전성 | API 응답에 any 사용 | 중 |
|
|
150
|
+
| src/service.ts:10 | YAGNI/KISS/DRY | 구현체가 하나뿐인 provider 추상화 | 중 |
|
|
132
151
|
| src/bar.tsx:15 | 불필요 코드 | console.log 미제거 | 낮음 |
|
|
133
152
|
| src/page.tsx:30 | UI-First 정합성 | Error state 미구현 | 중 |
|
|
134
153
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "Code Verification"
|
|
3
|
-
short_description: "Review code quality
|
|
4
|
-
default_prompt: "Use $verify-code to review changed code for logic, typing, reuse, and side effects."
|
|
3
|
+
short_description: "Review code quality and overengineering"
|
|
4
|
+
default_prompt: "Use $verify-code to review changed code for logic, typing, YAGNI/KISS/DRY, reuse, and side effects."
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: verify-implementation
|
|
3
|
-
description: 프로젝트의 모든 verify 스킬을 동적으로 탐색하여 순차
|
|
3
|
+
description: 프로젝트의 모든 verify 스킬을 동적으로 탐색하여 순차 실행하고, YAGNI/KISS/DRY Gate를 포함한 통합 검증 보고서를 생성합니다.
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: "[선택사항: 특정 verify 스킬 이름]"
|
|
6
6
|
---
|
|
@@ -9,7 +9,7 @@ argument-hint: "[선택사항: 특정 verify 스킬 이름]"
|
|
|
9
9
|
|
|
10
10
|
## 목적
|
|
11
11
|
|
|
12
|
-
프로젝트에 존재하는 모든 `verify-*` 스킬을 동적으로 탐색하여 순차적으로 실행하고 통합 검증을 수행합니다. 기본 순서를 따르되, 변경 파일과 프로젝트 특성에 따라 해당 없는 스킬은 `N/A - 사유`로 기록합니다.
|
|
12
|
+
프로젝트에 존재하는 모든 `verify-*` 스킬을 동적으로 탐색하여 순차적으로 실행하고 통합 검증을 수행합니다. 기본 순서를 따르되, 변경 파일과 프로젝트 특성에 따라 해당 없는 스킬은 `N/A - 사유`로 기록합니다. 코드 변경이 있으면 YAGNI/KISS/DRY Gate 통과 여부를 통합 보고서에 반드시 포함합니다.
|
|
13
13
|
|
|
14
14
|
## 기본 실행 순서
|
|
15
15
|
|
|
@@ -17,7 +17,7 @@ argument-hint: "[선택사항: 특정 verify 스킬 이름]"
|
|
|
17
17
|
|---:|---|---|
|
|
18
18
|
| 1 | `verify-docs` | 문서 구조, Backlog Context Lock, UI-First Gate 검증 |
|
|
19
19
|
| 2 | `verify-ui` | 구현 UI와 화면 문서, 사용자 동선, 상태별 UI 일치 검증 |
|
|
20
|
-
| 3 | `verify-code` | 코드 품질, 타입, 로직, 사이드 이펙트 검증 |
|
|
20
|
+
| 3 | `verify-code` | 코드 품질, 타입, 로직, YAGNI/KISS/DRY, 사이드 이펙트 검증 |
|
|
21
21
|
| 4 | `verify-security` | 인증·인가·입력·시크릿·OWASP 보안 검증 |
|
|
22
22
|
| 5 | `verify-performance` | Lighthouse, Core Web Vitals, 렌더링·번들 검증 |
|
|
23
23
|
| 6 | `verify-drizzle-schema` | DB 스키마 변경 시 명세·관계·인덱스 검증 |
|
|
@@ -26,12 +26,12 @@ argument-hint: "[선택사항: 특정 verify 스킬 이름]"
|
|
|
26
26
|
## 워크플로우
|
|
27
27
|
|
|
28
28
|
### Step 0: Flow 위치 확인
|
|
29
|
-
검증을 시작하기 전에 `rules-product`의 `Flow Status Block` 형식으로 현재 위치를 보고합니다. 일반적으로 현재 위치는 `Phase 5 — 품질
|
|
29
|
+
검증을 시작하기 전에 `rules-product`의 `Flow Status Block` 형식으로 현재 위치를 보고합니다. 일반적으로 현재 위치는 `Phase 5 — 품질 검증`이며, 코드 변경이 있으면 Gate에 `YAGNI/KISS/DRY Gate`를 포함합니다. 상세 기준은 `rules-dev`의 Minimal Implementation Gate 정본을 참조합니다.
|
|
30
30
|
|
|
31
31
|
```
|
|
32
32
|
[Flow]
|
|
33
33
|
현재: Phase 5 — 품질 검증
|
|
34
|
-
Gate: Quality Gate 진행 중
|
|
34
|
+
Gate: Quality Gate + YAGNI/KISS/DRY Gate 진행 중
|
|
35
35
|
완료: Phase 1, Phase 2, UI-First Gate, Pre-Code Technical Brief, Phase 3, Phase 4
|
|
36
36
|
다음: Phase 6 — 최종 전달물 또는 Handoff
|
|
37
37
|
필요 확인: Fail 항목 또는 N/A 처리 사유
|
|
@@ -58,6 +58,12 @@ Gate: Quality Gate 진행 중
|
|
|
58
58
|
### Step 4: 통합 보고서 생성
|
|
59
59
|
PASS/FAIL 통계와 발견된 이슈 목록을 생성합니다.
|
|
60
60
|
보고서 상단에는 `Flow Status Block`을 다시 포함하고, Gate 상태를 `통과`, `미통과`, `Blocked`, `N/A` 중 하나로 표시합니다.
|
|
61
|
+
코드 변경이 있으면 다음 최소 구현 항목을 별도 행 또는 별도 섹션으로 보고합니다:
|
|
62
|
+
|
|
63
|
+
- Minimal Implementation Gate: `rules-dev` 정본 기준 통과 여부
|
|
64
|
+
- verify-code Area 3 결과: `delete`, `stdlib`, `native`, `yagni`, `shrink` 태그 발생 여부
|
|
65
|
+
- Prototype/Spike Exception: 정보성 체크로 처리했는지 여부
|
|
66
|
+
- Safety Exception: 단순화 명목으로 검증·보안·에러 처리·접근성·데이터 보존을 제거하지 않았는지 여부
|
|
61
67
|
|
|
62
68
|
### Step 5: 수정 옵션 제공
|
|
63
69
|
자동 수정 또는 개별 수정을 사용자에게 제안합니다.
|
|
@@ -74,7 +80,7 @@ PASS/FAIL 통계와 발견된 이슈 목록을 생성합니다.
|
|
|
74
80
|
|---:|---|:---:|---|
|
|
75
81
|
| 1 | verify-docs | Pass / Fail / N/A | |
|
|
76
82
|
| 2 | verify-ui | Pass / Fail / N/A | |
|
|
77
|
-
| 3 | verify-code | Pass / Fail / N/A | |
|
|
83
|
+
| 3 | verify-code | Pass / Fail / N/A | YAGNI/KISS/DRY Gate 포함 |
|
|
78
84
|
| 4 | verify-security | Pass / Fail / N/A | |
|
|
79
85
|
| 5 | verify-performance | Pass / Fail / N/A | |
|
|
80
86
|
| 6 | verify-drizzle-schema | Pass / Fail / N/A | |
|
|
@@ -83,6 +89,12 @@ PASS/FAIL 통계와 발견된 이슈 목록을 생성합니다.
|
|
|
83
89
|
### 배포/PR 차단 항목
|
|
84
90
|
- [높음] ...
|
|
85
91
|
|
|
92
|
+
### YAGNI/KISS/DRY Gate
|
|
93
|
+
- Minimal Implementation Gate (rules-dev 정본): Pass / Fail / N/A
|
|
94
|
+
- verify-code Area 3: Pass / Fail / N/A
|
|
95
|
+
- Prototype/Spike Exception: Applied / Not Applied / N/A
|
|
96
|
+
- Safety Exception: Pass / Fail / N/A
|
|
97
|
+
|
|
86
98
|
### 재검증 필요 항목
|
|
87
99
|
- ...
|
|
88
100
|
```
|
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "Implementation Verification"
|
|
3
|
-
short_description: "Run all verification skills
|
|
4
|
-
default_prompt: "Use $verify-implementation to discover and run the relevant verify skills before PR."
|
|
3
|
+
short_description: "Run all verification skills and gates"
|
|
4
|
+
default_prompt: "Use $verify-implementation to discover and run the relevant verify skills, including YAGNI/KISS/DRY gates, before PR."
|