ai-developer-skill-os 2.0.1 → 3.0.0

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.
@@ -1,335 +1,52 @@
1
- ---
2
- name: qk-docs
3
- purpose: Viết và duy trì tài liệu dự án dễ hiểu cho con người (Human-readable Docs).
4
- mode_supported: [standard]
5
- input: [Code changes]
6
- output: [Updated README, API Docs, Changelog]
7
- workflow: [1. Tóm tắt Code -> 2. Generate Docs -> 3. Handoff]
8
- allowed_tools: [write_to_file]
9
- handoff_to: [qk-documentation-system]
10
- ---
11
-
12
- # 🛠️ qk-docs - Quy Trình Vận Hành Chuẩn (SOP)
13
-
14
- > **Mô tả:** Viết và duy trì tài liệu dự án dễ hiểu cho con người (Human-readable Docs).
15
-
16
- ## 🎯 1. Mục Tiêu (Goal)
17
- - Hoàn thành thành công tác vụ được giao liên quan đến nhiệm vụ của skill.
18
- - Đảm bảo chất lượng mã nguồn và tính nhất quán của hệ thống.
19
-
20
- ## 🔄 2. Chuỗi Hành Động (Chain of Thought / SOP)
21
- *(Bắt buộc AI phải suy nghĩ và làm theo đúng thứ tự)*
22
- 1. **Phân tích (Analyze):** Thu thập ngữ cảnh và hiểu rõ yêu cầu đầu vào.
23
- 2. **Lên kế hoạch (Plan):** Xác định các bước cần thay đổi/tạo mới dựa trên bộ luật (rules).
24
- 3. **Thực thi (Execute):** Tiến hành sửa đổi mã nguồn hoặc tạo tài liệu.
25
- 4. **Xác thực (Verify):** Đảm bảo đầu ra đáp ứng đúng yêu cầu và không vi phạm quy định.
26
-
27
- ## 🛡️ 3. Ràng Buộc & Quy Tắc (Constraints)
28
- - CẤM bỏ qua việc kiểm tra `qk-engineering-standard` trước khi viết code.
29
- - Mọi quyết định kỹ thuật phải dựa trên nội dung tại phần Deep Knowledge (nếu có).
30
-
31
- ## 🤝 4. Giao Thức Bàn Giao (Handoff Protocol)
32
- - Đích đến: `qk-documentation-system`
33
- - Nội dung bàn giao: Chuyển toàn bộ ngữ cảnh kết quả đã thực thi cho bước tiếp theo.
34
-
35
- ## 📚 5. Kiến Thức Chuyên Sâu (Deep Knowledge)
36
-
37
- *(Nền tảng kiến thức và quy tắc chi tiết kế thừa từ kỹ sư)*
38
-
39
- ---
40
-
41
-
42
-
43
- # Git Engineer
44
-
45
- > **Language rule:**
46
- > Use English for: code, identifiers, file names, architecture terms, technical decisions.
47
- > Use the user's language for: explanations, questions, summaries, and feedback.
48
- > The user may write in any language — detect and match it automatically.
49
-
50
- > 📌 **Standard followed:** [Conventional Commits v1.0.0](https://www.conventionalcommits.org/)
51
-
52
- ---
53
-
54
- ## Trigger
55
-
56
- Activate this skill when:
57
- - User wants to write a commit message
58
- - User has finished a feature and needs a PR description
59
- - User needs to generate a changelog for a release
60
- - User asks "what should I commit?", "write PR", "release notes"
61
- - User wants to clean up their git history before merging
62
-
63
- ---
64
-
65
- ## Scope
66
-
67
- - ✅ Write commit messages (Conventional Commits format)
68
- - ✅ Suggest logical commit groupings from a set of changes
69
- - ✅ Write pull request titles and descriptions
70
- - ✅ Generate CHANGELOG entries from commit history
71
- - ✅ Write release notes (human-readable)
72
- - ✅ Suggest branch naming conventions
73
- - ✅ Review and improve existing commit messages
74
-
75
- ---
76
-
77
- ## Non-goals
78
-
79
- - ❌ Do NOT run git commands without explicit user approval
80
- - ❌ Do NOT force-push or rebase without warning
81
- - ❌ Do NOT create commits that bundle unrelated changes
82
- - ❌ Do NOT write vague messages like "fix stuff" or "updates"
83
-
84
- ---
85
-
86
- ## Conventional Commits Format
87
-
88
- ```
89
- <type>(<scope>): <description>
90
-
91
- [optional body]
92
-
93
- [optional footer(s)]
94
- ```
95
-
96
- ### Types
97
-
98
- | Type | When to use |
99
- |------|-------------|
100
- | `feat` | New feature |
101
- | `fix` | Bug fix |
102
- | `docs` | Documentation only changes |
103
- | `style` | Formatting, missing semicolons — no logic change |
104
- | `refactor` | Code restructure without behavior change |
105
- | `perf` | Performance improvement |
106
- | `test` | Adding or fixing tests |
107
- | `build` | Build system or dependency changes |
108
- | `ci` | CI/CD configuration changes |
109
- | `chore` | Other changes that don't modify src or test files |
110
- | `revert` | Reverts a previous commit |
111
-
112
- ### Breaking Changes
113
-
114
- ```
115
- feat!: remove deprecated login endpoint
116
-
117
- BREAKING CHANGE: The /auth/login endpoint has been removed.
118
- Use /auth/v2/login instead.
119
- ```
120
-
121
- ---
122
-
123
- ## Workflow
124
-
125
- ### Phase 1 — Understand the Changes
126
-
127
- Review what has changed:
128
- 1. Read the diff or file list provided by the user
129
- 2. Group changes by concern (feature, fix, refactor, docs, etc.)
130
- 3. Identify if changes should be split into multiple commits or kept as one
131
- 4. Note any breaking changes
132
-
133
- ---
134
-
135
- ### Phase 2 — Commit Message(s)
136
-
137
- For each logical group of changes, write:
138
-
139
- **Single commit:**
140
- ```
141
- feat(auth): add refresh token rotation
142
-
143
- Implements automatic refresh token rotation on each use.
144
- Old tokens are invalidated immediately after use to prevent
145
- replay attacks.
146
-
147
- Closes #142
148
- ```
149
-
150
- **Multiple commits (if changes should be split):**
151
- ```
152
- refactor(api): extract axios instance to lib/axios.ts
153
-
154
- No behavior change — prepares for interceptor configuration.
155
-
156
- ---
157
-
158
- feat(api): add request retry interceptor
159
-
160
- Automatically retries failed requests up to 3 times with
161
- exponential backoff. Skips retry for 4xx errors.
162
- ```
163
-
164
- **Rules:**
165
- - Subject line: ≤72 characters, imperative mood ("add" not "added")
166
- - Body: explain *why*, not *what* (the diff shows what)
167
- - Reference issues: `Closes #123`, `Fixes #456`, `Refs #789`
168
-
169
- ---
170
-
171
- ### Phase 3 — Pull Request Description
172
-
173
- Structure:
174
- ```markdown
175
- ## Summary
176
- [1-3 sentences describing what this PR does and why]
177
-
178
- ## Changes
179
- - [Specific change 1]
180
- - [Specific change 2]
181
- - [Specific change 3]
182
-
183
- ## Testing
184
- - [ ] Unit tests pass
185
- - [ ] Manual testing: [describe what you tested]
186
- - [ ] [Other relevant checks]
187
-
188
- ## Breaking Changes
189
- [None | Description of breaking change and migration path]
190
-
191
- ## Screenshots / Demo
192
- [If UI changes — attach before/after screenshots]
193
-
194
- ## Related Issues
195
- Closes #[issue number]
196
- ```
197
-
198
- ---
199
-
200
- ### Phase 4 — Changelog Entry
201
-
202
- Follow [Keep a Changelog](https://keepachangelog.com/) format:
203
-
204
- ```markdown
205
- ## [1.2.0] - 2026-07-01
206
-
207
- ### Added
208
- - Refresh token rotation for improved security (#142)
209
- - Retry interceptor with exponential backoff (#138)
210
-
211
- ### Changed
212
- - Extracted axios instance to `src/lib/axios.ts` for cleaner configuration
213
-
214
- ### Fixed
215
- - Fixed race condition in useUserData hook causing stale state (#135)
216
- - Resolved memory leak when component unmounts during fetch (#133)
217
-
218
- ### Deprecated
219
- - `GET /api/v1/users` — use `GET /api/v2/users` instead (removes in v2.0)
220
-
221
- ### Removed
222
- - Removed legacy `moment.js` dependency — migrated to `date-fns`
223
-
224
- ### Security
225
- - Updated `package-x` from 2.1.0 to 2.1.4 (CVE-2026-XXXX)
226
- ```
227
-
228
- ---
229
-
230
- ### Phase 5 — Release Notes (Human-Readable)
231
-
232
- For non-technical stakeholders:
233
-
234
- ```markdown
235
- # Release v1.2.0 — Security & Stability
236
-
237
- ## What's new
238
-
239
- **Better security**: Login sessions are now more secure with automatic
240
- token rotation. Each time you use the app, your session is refreshed
241
- automatically.
242
-
243
- **More reliable**: The app now automatically retries failed requests,
244
- so temporary network issues won't interrupt your workflow.
245
-
246
- ## Bug fixes
247
-
248
- - Fixed an issue where user data could appear stale after navigating
249
- - Fixed a rare crash that occurred when closing the app during data loading
250
-
251
- ## Under the hood
252
-
253
- We've updated several internal libraries to keep the app fast, secure,
254
- and maintainable.
255
- ```
256
-
257
- ---
258
-
259
- ## Decision Tree
260
-
261
- ```
262
- What does the user need?
263
- ├── Commit message → Phase 2 only
264
- ├── PR description → Phase 3 (+ Phase 2 if commits not written)
265
- ├── Changelog entry → Phase 4 (from commit list or diff)
266
- └── Full release → Phase 2 + Phase 4 + Phase 5
267
-
268
- Should changes be split into multiple commits?
269
- ├── Changes are unrelated → Yes — split by concern
270
- ├── Changes form one atomic feature → No — single commit
271
- └── Unsure → Ask user
272
-
273
- Is there a breaking change?
274
- ├── Yes → Use `feat!` or `fix!` type + BREAKING CHANGE footer
275
- └── No → Standard type
276
- ```
277
-
278
- ---
279
-
280
- ## Branch Naming Convention
281
-
282
- ```
283
- feature/short-description → new features
284
- fix/short-description → bug fixes
285
- refactor/short-description → refactoring
286
- chore/dependency-upgrade → maintenance
287
- release/v1.2.0 → release preparation
288
- hotfix/critical-issue → urgent production fixes
289
- ```
290
-
291
- ---
292
-
293
- ## Output Format
294
-
295
- ```
296
- 📝 Git Output
297
- ─────────────────────────────────────────────────
298
- Type: [commit | PR | changelog | release-notes]
299
-
300
- ─── Commit Message ───────────────────────────────
301
- feat(scope): short imperative description
302
-
303
- Body explaining why this change was made.
304
- What problem does it solve?
305
-
306
- Closes #123
307
-
308
- ─── PR Title ─────────────────────────────────────
309
- feat(scope): short imperative description
310
-
311
- ─── PR Description ───────────────────────────────
312
- [Formatted markdown PR body]
313
-
314
- ─── Changelog ────────────────────────────────────
315
- [Formatted changelog section]
316
- ```
317
-
318
- ---
319
-
320
- ## Validation Checklist
321
-
322
- - [ ] Commit type is correct (feat/fix/refactor/etc.)
323
- - [ ] Subject line ≤72 chars, imperative mood, no period at end
324
- - [ ] Breaking changes flagged with `!` and `BREAKING CHANGE:` footer
325
- - [ ] Body explains *why*, not just *what*
326
- - [ ] Issue references included (`Closes #N`)
327
- - [ ] PR description covers: summary, changes, testing, breaking changes
328
- - [ ] Changelog uses correct sections (Added/Changed/Fixed/etc.)
329
- - [ ] No vague messages ("fix stuff", "updates", "wip")
330
-
331
- ---
332
-
333
- ## Examples
334
-
335
- See `examples/` folder.
1
+ ---
2
+ name: qk-docs
3
+ version: 3.0.0
4
+ updated: 2026-07-02
5
+ description: Write and maintain human-readable project documentation.
6
+ category: documentation
7
+ priority: low
8
+ tags: [docs, markdown, jsdoc, readme]
9
+ platforms: [claude-code, cursor, windsurf, gemini-cli]
10
+ trigger: User asks to write docs, update the README, or generate JSDoc comments.
11
+ inputs: [Source code, Task context]
12
+ outputs: [Markdown Documentation, JSDoc]
13
+ allowed_tools: [read_file, write_to_file]
14
+ pipeline: [analyze, implement, validate, complete]
15
+ ---
16
+
17
+ # 🛠️ qk-docs - Standard Operating Procedure
18
+
19
+ > **Goal:** Đóng vai trò là "Technical Writer". Viết tài liệu (README, API Docs, Code Comments) rõ ràng, dễ hiểu cho con người.
20
+
21
+ ## 🔄 1. Chain of Thought (SOP)
22
+ 1. **Analyze (Context Extraction):**
23
+ - Read the target source code to understand its Inputs, Outputs, and side effects.
24
+ 2. **Implement (Drafting):**
25
+ - Write Markdown or JSDoc comments.
26
+ - Structure: Description -> Parameters -> Returns -> Warnings/Notes.
27
+ 3. **Validate (Review Examples):**
28
+ - ALWAYS provide 1-2 real-world code examples demonstrating how to use the function/API.
29
+ 4. **Complete (Format):**
30
+ - Ensure proper Markdown syntax (bolding, code blocks with languages).
31
+
32
+ ## 🛡️ 2. Constraints & Rules
33
+ - **Human Friendly:** Avoid overly academic language. Explain it as if explaining to a junior developer.
34
+ - **Language Hybrid:** If writing Vietnamese documentation, keep technical keywords (props, state, endpoint, fetch) in English.
35
+
36
+ ## 🌳 3. Decision Tree
37
+ ```text
38
+ Is this an API Documentation?
39
+ ├── YES → Use standard REST/GraphQL documentation layout (Endpoint, Method, Body, Response).
40
+ └── NO → Is it a Component Documentation?
41
+ ├── YES → Document the Props interface and usage examples.
42
+ └── NO → Write standard JSDoc.
43
+ ```
44
+
45
+ ## 🤝 4. Handoff Pipeline
46
+ 1. `complete`: Generate the Docs and save them to the project files.
47
+
48
+ ## 📝 5. Output Format
49
+ Vui lòng trả kết quả bằng Tiếng Việt.
50
+ - **Tóm tắt (Summary):** Tài liệu nào đã được tạo/cập nhật.
51
+ - **Chi tiết (Changes):** Cấu trúc tài liệu.
52
+ - **Xác thực (Verification):** Yêu cầu User đọc lướt qua tài liệu.
@@ -1,33 +1,38 @@
1
- ---
2
- name: qk-documentation-system
3
- purpose: Hệ thống tri thức AI: Rút trích Pattern/Decision và cập nhật AI Memory.
4
- mode_supported: [enterprise]
5
- input: [Docs & Code]
6
- output: [Updated project memory (ADR, patterns)]
7
- workflow: [1. Đọc Docs mới -> 2. Trích xuất Rule -> 3. Update Memory]
8
- allowed_tools: [write_to_file]
9
- handoff_to: [none]
10
- ---
11
-
12
- # 🛠️ qk-documentation-system - Quy Trình Vận Hành Chuẩn (SOP)
13
-
14
- > **Mô tả:** Hệ thống tri thức AI: Rút trích Pattern/Decision và cập nhật AI Memory.
15
-
16
- ## 🎯 1. Mục Tiêu (Goal)
17
- - Hoàn thành thành công tác vụ được giao liên quan đến nhiệm vụ của skill.
18
- - Đảm bảo chất lượng mã nguồn và tính nhất quán của hệ thống.
19
-
20
- ## 🔄 2. Chuỗi Hành Động (Chain of Thought / SOP)
21
- *(Bắt buộc AI phải suy nghĩ và làm theo đúng thứ tự)*
22
- 1. **Phân tích (Analyze):** Thu thập ngữ cảnh và hiểu rõ yêu cầu đầu vào.
23
- 2. **Lên kế hoạch (Plan):** Xác định các bước cần thay đổi/tạo mới dựa trên bộ luật (rules).
24
- 3. **Thực thi (Execute):** Tiến hành sửa đổi mã nguồn hoặc tạo tài liệu.
25
- 4. **Xác thực (Verify):** Đảm bảo đầu ra đáp ứng đúng yêu cầu và không vi phạm quy định.
26
-
27
- ## 🛡️ 3. Ràng Buộc & Quy Tắc (Constraints)
28
- - CẤM bỏ qua việc kiểm tra `qk-engineering-standard` trước khi viết code.
29
- - Mọi quyết định kỹ thuật phải dựa trên nội dung tại phần Deep Knowledge (nếu có).
30
-
31
- ## 🤝 4. Giao Thức Bàn Giao (Handoff Protocol)
32
- - Đích đến: `none`
33
- - Nội dung bàn giao: Chuyển toàn bộ ngữ cảnh và kết quả đã thực thi cho bước tiếp theo.
1
+ ---
2
+ name: qk-documentation-system
3
+ version: 3.0.0
4
+ updated: 2026-07-02
5
+ description: Maintain system-level architecture docs and DevOps runbooks.
6
+ category: documentation
7
+ priority: low
8
+ tags: [architecture, diagrams, mermaid, runbooks]
9
+ platforms: [claude-code, cursor, windsurf, gemini-cli]
10
+ trigger: User asks to generate architecture diagrams or DevOps manuals.
11
+ inputs: [Architecture changes]
12
+ outputs: [System Docs, Mermaid Diagrams]
13
+ allowed_tools: [write_to_file, read_file]
14
+ pipeline: [analyze, design, implement, complete]
15
+ ---
16
+
17
+ # 🛠️ qk-documentation-system - Standard Operating Procedure
18
+
19
+ > **Goal:** Quản lý tài liệu cấp hệ thống (System Architecture, Sequence Diagrams, Runbooks).
20
+
21
+ ## 🔄 1. Chain of Thought (SOP)
22
+ 1. **Analyze (System Flow):**
23
+ - Understand the flow of data across microservices or complex components.
24
+ 2. **Design (Diagramming):**
25
+ - Draft the sequence or architecture diagram using Mermaid syntax.
26
+ 3. **Implement (Drafting):**
27
+ - Save the documentation into the `/docs/` folder.
28
+
29
+ ## 🛡️ 2. Constraints & Rules
30
+ - **Syntax Check:** Ensure Mermaid diagrams are syntactically valid before saving.
31
+
32
+ ## 🤝 3. Handoff Pipeline
33
+ 1. `complete`: Output the System Documentation Report.
34
+
35
+ ## 📝 4. Output Format
36
+ Vui lòng trả kết quả bằng Tiếng Việt.
37
+ - **Tóm tắt (Summary):** Tài liệu kiến trúc nào đã được tạo.
38
+ - **Chi tiết (Changes):** Đường dẫn file.