solmate-skills 2.0.2 → 2.0.4
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/README.md +57 -2
- package/docs-dev/SKILL.md +51 -0
- package/package.json +2 -2
- package/rules-docs/SKILL.md +16 -0
- package/rules-workflow/SKILL.md +6 -3
- package/verify-docs/SKILL.md +26 -6
package/README.md
CHANGED
|
@@ -2,6 +2,17 @@
|
|
|
2
2
|
|
|
3
3
|
Curated skills for Solmate projects. Easily share and install AI tool skills across your team.
|
|
4
4
|
|
|
5
|
+
## What's New in 2.0.3
|
|
6
|
+
|
|
7
|
+
`solmate-skills@2.0.3` adds **Backlog Context Lock**, a documentation rule that prevents implementation work from drifting away from the dense project documents already written in the 5-Layer structure.
|
|
8
|
+
|
|
9
|
+
Key changes:
|
|
10
|
+
|
|
11
|
+
- Every backlog task must link to related Concept, UI, Technical Spec, and QA documents.
|
|
12
|
+
- `/rules-workflow` now treats linked backlog documents as implementation inputs before coding starts.
|
|
13
|
+
- `/verify-docs` fails backlog items that omit required related-document fields.
|
|
14
|
+
- Local Codex settings under `.codex/` are excluded from the npm package.
|
|
15
|
+
|
|
5
16
|
## Installation
|
|
6
17
|
|
|
7
18
|
You don't need to install this package globally. Simply use `npx`:
|
|
@@ -133,8 +144,52 @@ docs/
|
|
|
133
144
|
1. /docs-plan → Write VISION_CORE.md, LEAN_CANVAS.md, PRODUCT_SPECS.md
|
|
134
145
|
2. /docs-plan → Write SCREEN_FLOW.md, UI_DESIGN.md
|
|
135
146
|
3. /docs-dev → Write DEVELOPMENT_PRINCIPLES.md, DB_SCHEMA.md, API_SPECS.md
|
|
136
|
-
4. /docs-dev → Write ROADMAP.md, BACKLOG.md
|
|
137
|
-
5. /
|
|
147
|
+
4. /docs-dev → Write ROADMAP.md, BACKLOG.md with mandatory related document links
|
|
148
|
+
5. /rules-workflow → Implement each backlog item only after reading linked docs
|
|
149
|
+
6. /verify-docs → Audit structure, metadata, and Backlog Context Lock compliance
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
Backlog items are intentionally document-linked. Each task in `docs/04_Logic_Progress/00_BACKLOG.md` must include related Concept, UI, Technical Spec, and QA documents, plus implementation preconditions, acceptance criteria, and a document sync check. If a related document does not exist, the item must say `N/A - 사유`; implementation should pause when the missing document is required for a safe decision.
|
|
153
|
+
|
|
154
|
+
### Backlog Context Lock
|
|
155
|
+
|
|
156
|
+
Backlog Context Lock makes `docs/04_Logic_Progress/00_BACKLOG.md` act as a bridge between planning documents and implementation. A backlog item is not considered ready for coding until it names the documents that define why the task exists, how the UI should behave, what technical constraints apply, and how the work will be verified.
|
|
157
|
+
|
|
158
|
+
Required fields for every backlog item:
|
|
159
|
+
|
|
160
|
+
- `Related Concept Docs`
|
|
161
|
+
- `Related UI Docs`
|
|
162
|
+
- `Related Technical Docs`
|
|
163
|
+
- `Related QA Docs`
|
|
164
|
+
- `Implementation Preconditions`
|
|
165
|
+
- `Acceptance Criteria`
|
|
166
|
+
- `Document Sync Check`
|
|
167
|
+
|
|
168
|
+
If a related document does not exist, write `N/A - 사유`. Do not leave the field blank. If the missing document is required to make a safe implementation decision, pause implementation and write or update the document first.
|
|
169
|
+
|
|
170
|
+
**Backlog item template:**
|
|
171
|
+
|
|
172
|
+
```markdown
|
|
173
|
+
### [ ] TASK-000: Implement feature name
|
|
174
|
+
|
|
175
|
+
- Status: ToDo
|
|
176
|
+
- Related Concept Docs:
|
|
177
|
+
- [Product Specs](../01_Concept_Design/03_PRODUCT_SPECS.md) - feature purpose and user value
|
|
178
|
+
- Related UI Docs:
|
|
179
|
+
- [Screen Flow](../02_UI_Screens/00_SCREEN_FLOW.md) - target screen and interaction flow
|
|
180
|
+
- Related Technical Docs:
|
|
181
|
+
- [API Specs](../03_Technical_Specs/02_API_SPECS.md) - endpoint and data contract
|
|
182
|
+
- Related QA Docs:
|
|
183
|
+
- [QA Checklist](../05_QA_Validation/02_QA_CHECKLIST.md) - acceptance and release criteria
|
|
184
|
+
- Implementation Preconditions:
|
|
185
|
+
- [ ] Read all related documents before coding
|
|
186
|
+
- [ ] Confirm implementation scope does not conflict with documented intent
|
|
187
|
+
- Acceptance Criteria:
|
|
188
|
+
- [ ] Feature behavior matches linked Concept/UI/Technical docs
|
|
189
|
+
- [ ] QA criteria are testable and satisfied
|
|
190
|
+
- Document Sync Check:
|
|
191
|
+
- [ ] No mismatch between implementation and linked documents
|
|
192
|
+
- [ ] Update related documents if implementation changes the agreed behavior
|
|
138
193
|
```
|
|
139
194
|
|
|
140
195
|
---
|
package/docs-dev/SKILL.md
CHANGED
|
@@ -58,6 +58,32 @@ This skill manages **Layer 3 (Technical_Specs)**, **Layer 4 (Logic_Progress)**,
|
|
|
58
58
|
|
|
59
59
|
**중요 규칙**: 실무 문서(`00_BACKLOG.md`, `00_ROADMAP.md`, `01_EXECUTION_PLAN.md`) 작성 시, 모든 작업은 반드시 체크박스`[ ]`를 사용하여 원자적 단위(Atomic Task)로 최대한 상세히 나누어 기록해야 한다. "추상적인 작업" 대신 "실제로 실행 및 검증 가능한 단계"로 분할한다.
|
|
60
60
|
|
|
61
|
+
**Backlog 문서 참조 강제 규칙**: `00_BACKLOG.md`의 모든 작업 항목은 관련 문서를 읽은 뒤 작성해야 하며, 구현자는 코드 작성 전에 해당 문서를 다시 확인해야 한다. 백로그는 단순 ToDo 목록이 아니라 Concept, UI, Technical Spec, QA 기준을 구현으로 연결하는 실행 티켓이어야 한다.
|
|
62
|
+
|
|
63
|
+
Backlog 항목 작성 전 필수 확인 대상:
|
|
64
|
+
- `docs/01_Concept_Design/`: 기능 목적, 사용자 가치, 제품 방향
|
|
65
|
+
- `docs/02_UI_Screens/`: 화면 흐름, UI 상태, 인터랙션
|
|
66
|
+
- `docs/03_Technical_Specs/`: API, DB, 데이터 구조, 기술 제약
|
|
67
|
+
- `docs/05_QA_Validation/`: 테스트 기준, 수용 조건, 검증 시나리오
|
|
68
|
+
|
|
69
|
+
각 Backlog 항목은 다음 필드를 반드시 포함한다:
|
|
70
|
+
- `Related Concept Docs`: 관련 기획/디자인 문서
|
|
71
|
+
- `Related UI Docs`: 관련 화면/플로우 문서
|
|
72
|
+
- `Related Technical Docs`: 관련 기술 명세 문서
|
|
73
|
+
- `Related QA Docs`: 관련 검증 문서
|
|
74
|
+
- `Implementation Preconditions`: 구현 전 반드시 확인할 조건
|
|
75
|
+
- `Acceptance Criteria`: 완료 판단 기준
|
|
76
|
+
- `Document Sync Check`: 구현 후 문서와 코드의 일치 여부
|
|
77
|
+
|
|
78
|
+
관련 문서가 아직 없거나 해당하지 않는 경우에도 비워둘 수 없다. 반드시 `N/A - 사유`를 적고, 구현 판단에 필요한 문서가 없으면 구현 전에 문서 작성 또는 보완을 사용자에게 확인한다.
|
|
79
|
+
|
|
80
|
+
구현 시작 전 체크:
|
|
81
|
+
- 관련 문서를 실제로 읽었는가?
|
|
82
|
+
- 문서의 요구사항이 Backlog 항목에 반영되어 있는가?
|
|
83
|
+
- 구현 범위가 관련 문서의 의도와 충돌하지 않는가?
|
|
84
|
+
- 관련 QA 기준이 `Acceptance Criteria`에 반영되어 있는가?
|
|
85
|
+
- 누락된 문서가 있다면 `N/A - 사유`가 타당한가?
|
|
86
|
+
|
|
61
87
|
1. **Project Initialization**: CLI 프리셋 vs 수동 설정?
|
|
62
88
|
2. **UI Theme Strategy**: 사전 정의된 테마 vs 커스텀 브랜드 색상? 폰트 선택?
|
|
63
89
|
3. **Folder Structure**: Feature 기반 vs Type 기반?
|
|
@@ -143,6 +169,31 @@ This skill manages **Layer 3 (Technical_Specs)**, **Layer 4 (Logic_Progress)**,
|
|
|
143
169
|
- **QA_Validation**: [Test Scenarios](../05_QA_Validation/01_TEST_SCENARIOS.md) - 관련 테스트 케이스
|
|
144
170
|
```
|
|
145
171
|
|
|
172
|
+
### Template D-1 — Backlog Item
|
|
173
|
+
|
|
174
|
+
```
|
|
175
|
+
### [ ] TASK-000: [작업명]
|
|
176
|
+
|
|
177
|
+
- Status: ToDo | In Progress | Done
|
|
178
|
+
- Related Concept Docs:
|
|
179
|
+
- [문서명](../01_Concept_Design/XX_DOCUMENT.md) - 기능 목적/사용자 가치 근거
|
|
180
|
+
- Related UI Docs:
|
|
181
|
+
- [문서명](../02_UI_Screens/XX_DOCUMENT.md) - 화면 흐름/상태/인터랙션 근거
|
|
182
|
+
- Related Technical Docs:
|
|
183
|
+
- [문서명](../03_Technical_Specs/XX_DOCUMENT.md) - API/DB/데이터 구조 근거
|
|
184
|
+
- Related QA Docs:
|
|
185
|
+
- [문서명](../05_QA_Validation/XX_DOCUMENT.md) - 테스트 기준/수용 조건 근거
|
|
186
|
+
- Implementation Preconditions:
|
|
187
|
+
- [ ] 관련 문서 전체 확인 완료
|
|
188
|
+
- [ ] 구현 범위와 문서 요구사항 충돌 없음
|
|
189
|
+
- Acceptance Criteria:
|
|
190
|
+
- [ ] QA 기준이 구현 완료 판단에 반영됨
|
|
191
|
+
- [ ] 핵심 사용자 흐름이 검증됨
|
|
192
|
+
- Document Sync Check:
|
|
193
|
+
- [ ] 구현 후 코드와 관련 문서 불일치 없음
|
|
194
|
+
- [ ] 불일치가 있으면 관련 문서 또는 백로그 항목 업데이트
|
|
195
|
+
```
|
|
196
|
+
|
|
146
197
|
### Template E — QA_Validation
|
|
147
198
|
|
|
148
199
|
```
|
package/package.json
CHANGED
package/rules-docs/SKILL.md
CHANGED
|
@@ -66,6 +66,20 @@ description: Create and manage project documentation according to the 365 Princi
|
|
|
66
66
|
- `00_ROADMAP.md`: 마일스톤 및 단계별 일정 (Phase별 큰 줄기와 세부 항목 분할)
|
|
67
67
|
- `01_EXECUTION_PLAN.md`: 기술 실행 전략 및 타임라인 (구체적인 구현 스텝 및 체크박스 필수)
|
|
68
68
|
|
|
69
|
+
### Backlog Context Lock (필수)
|
|
70
|
+
|
|
71
|
+
`docs/04_Logic_Progress/00_BACKLOG.md`의 모든 작업 항목은 다른 레이어의 관련 문서를 구현 입력값으로 연결해야 한다. 백로그는 단독 ToDo가 아니며, 다음 필드를 통해 문서 기반 구현을 강제한다.
|
|
72
|
+
|
|
73
|
+
- `Related Concept Docs`
|
|
74
|
+
- `Related UI Docs`
|
|
75
|
+
- `Related Technical Docs`
|
|
76
|
+
- `Related QA Docs`
|
|
77
|
+
- `Implementation Preconditions`
|
|
78
|
+
- `Acceptance Criteria`
|
|
79
|
+
- `Document Sync Check`
|
|
80
|
+
|
|
81
|
+
각 Related 필드는 상대 경로 링크와 관계 설명을 포함해야 한다. 관련 문서가 없으면 빈칸으로 두지 않고 `N/A - 사유`를 명시한다. 단, 구현 판단에 필요한 Concept, UI, Technical Spec, QA 기준이 아직 문서화되지 않은 경우에는 백로그만으로 구현을 시작할 수 없으며, 먼저 문서 작성 또는 보완 여부를 사용자에게 확인한다.
|
|
82
|
+
|
|
69
83
|
### 메타데이터 (필수)
|
|
70
84
|
|
|
71
85
|
모든 문서 최상단:
|
|
@@ -104,6 +118,8 @@ description: Create and manage project documentation according to the 365 Princi
|
|
|
104
118
|
|
|
105
119
|
**Logic_Progress**: Concept_Design + UI_Screens + Technical_Specs (DB, API) + QA_Validation
|
|
106
120
|
|
|
121
|
+
**Backlog Items**: 각 항목 단위로 Concept_Design + UI_Screens + Technical_Specs + QA_Validation 링크를 포함한다. 구현자는 항목 착수 전 링크된 문서를 읽고 `Implementation Preconditions`를 확인해야 한다.
|
|
122
|
+
|
|
107
123
|
**QA_Validation**: 모든 상위 레이어 참조
|
|
108
124
|
|
|
109
125
|
## 6. 스킬 위임 테이블
|
package/rules-workflow/SKILL.md
CHANGED
|
@@ -13,8 +13,9 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
13
13
|
|
|
14
14
|
### Step 1. 계획 수립
|
|
15
15
|
- 요구사항·목적을 문서 또는 이슈 기준으로 정리한다.
|
|
16
|
+
- 백로그 항목이 있으면 `Related Concept Docs`, `Related UI Docs`, `Related Technical Docs`, `Related QA Docs`를 먼저 읽고 구현 입력값으로 요약한다.
|
|
16
17
|
- 변경할 파일·추가할 컴포넌트·API·DB 영향 범위를 나열한다.
|
|
17
|
-
- 체크: [ ] 목적이 명확한가? [ ] 영향 범위가 정리되었는가?
|
|
18
|
+
- 체크: [ ] 목적이 명확한가? [ ] 관련 문서를 읽었는가? [ ] 영향 범위가 정리되었는가?
|
|
18
19
|
|
|
19
20
|
### Step 2. 계획 검토
|
|
20
21
|
- 계획이 요구사항과 일치하는지, 누락된 시나리오는 없는지 검토한다.
|
|
@@ -34,7 +35,8 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
34
35
|
|
|
35
36
|
### Step 5. 구현
|
|
36
37
|
- 승인된 계획대로 구현한다. AGENTS.md·프로젝트 컨벤션(커밋, Zod, Luxon 등)을 따른다.
|
|
37
|
-
-
|
|
38
|
+
- 코드 작성 전 백로그 항목의 `Implementation Preconditions`와 `Acceptance Criteria`를 확인한다. 관련 문서 링크가 비어 있거나 `N/A - 사유`가 부실하면 구현을 보류하고 문서 보완 필요 여부를 사용자에게 확인한다.
|
|
39
|
+
- 체크: [ ] 계획 대비 변경 사항이 일치하는가? [ ] 백로그의 관련 문서 기준을 반영했는가?
|
|
38
40
|
|
|
39
41
|
---
|
|
40
42
|
|
|
@@ -90,7 +92,8 @@ Follow this workflow for feature implementation and significant code changes. Co
|
|
|
90
92
|
|
|
91
93
|
### Step 16. 관련 부분 반복 검토
|
|
92
94
|
- 검토 중 발견된 이슈와 연관된 코드·설정·문서를 다시 점검한다. 관련된 부분을 놓치지 않도록 추가로 확인한다.
|
|
93
|
-
-
|
|
95
|
+
- 백로그 항목의 `Document Sync Check`를 기준으로 구현 결과와 관련 문서의 불일치 여부를 확인한다.
|
|
96
|
+
- 체크: [ ] 발견 이슈의 연쇄 영향 [ ] 관련 모듈·설정까지 검토 [ ] 문서-구현 불일치 없음
|
|
94
97
|
|
|
95
98
|
### Step 17. 배포 가능 퀄리티 최종 검토
|
|
96
99
|
- "이대로 배포해도 될 수준인가?"를 한 번 더 검토한다. 1–16단계에서 누락된 항목이 없는지 확인한다.
|
package/verify-docs/SKILL.md
CHANGED
|
@@ -11,8 +11,9 @@ description: 프로젝트 문서가 5단계 구조(01~05)와 메타데이터 표
|
|
|
11
11
|
1. 5-Layer 폴더 구조 및 파일 네이밍
|
|
12
12
|
2. 메타데이터 표준 (Created / Last Updated)
|
|
13
13
|
3. Related Documents 섹션
|
|
14
|
-
4.
|
|
15
|
-
5.
|
|
14
|
+
4. Backlog Context Lock
|
|
15
|
+
5. Rubric-First Writing
|
|
16
|
+
6. rules-product Gate Out 조건
|
|
16
17
|
|
|
17
18
|
## 실행 시점
|
|
18
19
|
|
|
@@ -53,17 +54,35 @@ AGENTS.md 또는 `docs/01_Concept_Design/00_COLLABORATION_GUIDE.md`를 읽어
|
|
|
53
54
|
- [ ] 각 링크에 관계 설명이 포함되어 있는가?
|
|
54
55
|
- [ ] 상위 또는 하위 레이어 문서가 최소 1개 이상 연결되어 있는가?
|
|
55
56
|
|
|
56
|
-
### Step 4:
|
|
57
|
+
### Step 4: Backlog Context Lock 검사
|
|
58
|
+
|
|
59
|
+
`docs/04_Logic_Progress/00_BACKLOG.md`가 있으면 각 작업 항목을 확인한다.
|
|
60
|
+
|
|
61
|
+
체크 항목:
|
|
62
|
+
- [ ] 모든 Backlog 작업 항목이 체크박스`[ ]` 또는 `[x]`로 시작하는가?
|
|
63
|
+
- [ ] 각 작업 항목에 `Related Concept Docs`가 있는가?
|
|
64
|
+
- [ ] 각 작업 항목에 `Related UI Docs`가 있는가?
|
|
65
|
+
- [ ] 각 작업 항목에 `Related Technical Docs`가 있는가?
|
|
66
|
+
- [ ] 각 작업 항목에 `Related QA Docs`가 있는가?
|
|
67
|
+
- [ ] 각 작업 항목에 `Implementation Preconditions`가 있는가?
|
|
68
|
+
- [ ] 각 작업 항목에 `Acceptance Criteria`가 있는가?
|
|
69
|
+
- [ ] 각 작업 항목에 `Document Sync Check`가 있는가?
|
|
70
|
+
- [ ] Related 필드의 링크가 상대 경로이거나 `N/A - 사유` 형식인가?
|
|
71
|
+
- [ ] `N/A`만 있고 사유가 없는 항목은 없는가?
|
|
72
|
+
|
|
73
|
+
위 항목 중 하나라도 누락되면 Backlog Context Lock은 Fail로 처리한다.
|
|
74
|
+
|
|
75
|
+
### Step 5: Rubric-First Writing 검사
|
|
57
76
|
|
|
58
77
|
| 레이어 | 기준 |
|
|
59
78
|
|:---|:---|
|
|
60
79
|
| QA_Validation (Layer 5) | 6개 루브릭 전체 테이블 포함 (필수) |
|
|
61
|
-
| Logic_Progress (Layer 4) | 실무 문서(BACKLOG, ROADMAP, EXECUTION_PLAN) 내 체크박스`[ ]` 활용 및 원자적 단위
|
|
80
|
+
| Logic_Progress (Layer 4) | 실무 문서(BACKLOG, ROADMAP, EXECUTION_PLAN) 내 체크박스`[ ]` 활용 및 원자적 단위 분할, Backlog Context Lock 준수 (필수) |
|
|
62
81
|
| Concept_Design (Layer 1) | Novelty, Business Plan, Potential Impact 언급 (권장) |
|
|
63
82
|
| Technical_Specs (Layer 3) | Functionality, UX (latency), Open-source 언급 (권장) |
|
|
64
83
|
| Logic_Progress (Layer 4) | Functionality, UX 언급 (권장) |
|
|
65
84
|
|
|
66
|
-
### Step
|
|
85
|
+
### Step 6: Gate Out 조건 검사
|
|
67
86
|
|
|
68
87
|
rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한다.
|
|
69
88
|
|
|
@@ -81,7 +100,7 @@ rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한
|
|
|
81
100
|
- [ ] `docs/04_Logic_Progress/00_ROADMAP.md`
|
|
82
101
|
- [ ] `docs/05_QA_Validation/02_QA_CHECKLIST.md`
|
|
83
102
|
|
|
84
|
-
### Step
|
|
103
|
+
### Step 7: 검증 보고서 출력
|
|
85
104
|
|
|
86
105
|
검사 완료 후 아래 형식으로 결과를 출력한다:
|
|
87
106
|
|
|
@@ -94,6 +113,7 @@ rules-product 기준으로 각 Phase의 필수 문서 존재 여부를 확인한
|
|
|
94
113
|
| 파일 네이밍 | Pass / Fail | 위반 파일 목록 |
|
|
95
114
|
| 메타데이터 | Pass / Fail | 누락 파일 목록 |
|
|
96
115
|
| Related Documents | Pass / Fail | 미연결 파일 목록 |
|
|
116
|
+
| Backlog Context Lock | Pass / Fail | 필수 필드 누락 작업 목록 |
|
|
97
117
|
| Rubric-First | Pass / Fail | |
|
|
98
118
|
| Gate Out 조건 | Pass / Fail | 미충족 파일 목록 |
|
|
99
119
|
|