ai-developer-skill-os 2.1.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.
- package/.agents/AGENTS.md +48 -0
- package/README.md +77 -130
- package/knowledge/frontend/react.md +27 -0
- package/package.json +1 -1
- package/skills/qk-access-policy/SKILL.md +40 -127
- package/skills/qk-ai-builder/SKILL.md +41 -33
- package/skills/qk-api-lifecycle/SKILL.md +62 -420
- package/skills/qk-bug-resolution/SKILL.md +65 -371
- package/skills/qk-context-loader/SKILL.md +47 -206
- package/skills/qk-data-lifecycle/SKILL.md +60 -135
- package/skills/qk-design-to-code/SKILL.md +46 -33
- package/skills/qk-docs/SKILL.md +52 -335
- package/skills/qk-documentation-system/SKILL.md +38 -33
- package/skills/qk-engineering-standard/SKILL.md +61 -171
- package/skills/qk-feature-delivery/SKILL.md +63 -432
- package/skills/qk-help/SKILL.md +37 -95
- package/skills/qk-orchestrator/SKILL.md +52 -272
- package/skills/qk-policy-engine/SKILL.md +52 -33
- package/skills/qk-production-release/SKILL.md +45 -127
- package/skills/qk-project-bootstrap/SKILL.md +43 -33
- package/skills/qk-project-health/SKILL.md +56 -650
- package/skills/qk-project-memory/SKILL.md +35 -33
- package/skills/qk-system-evolution/SKILL.md +63 -315
- package/skills/qk-ui-audit/SKILL.md +58 -152
- package/skills/qk-ui-system-builder/SKILL.md +40 -444
- package/skills/qk-validation-gate/SKILL.md +59 -33
- package/templates/bug-report.md +21 -0
- package/templates/design-report.md +21 -0
- package/templates/feature-report.md +20 -0
- package/templates/review-report.md +21 -0
|
@@ -1,33 +1,35 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: qk-project-memory
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
1. **
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
## 🛡️
|
|
28
|
-
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
1
|
+
---
|
|
2
|
+
name: qk-project-memory
|
|
3
|
+
version: 3.0.0
|
|
4
|
+
updated: 2026-07-02
|
|
5
|
+
description: Store and retrieve long-term project context across sessions.
|
|
6
|
+
category: utilities
|
|
7
|
+
priority: low
|
|
8
|
+
tags: [memory, context, storage]
|
|
9
|
+
platforms: [claude-code, cursor, windsurf, gemini-cli]
|
|
10
|
+
trigger: User asks to remember a specific configuration, rule, or architectural decision.
|
|
11
|
+
inputs: [Context to remember]
|
|
12
|
+
outputs: [Memory file updated]
|
|
13
|
+
allowed_tools: [write_to_file, read_file]
|
|
14
|
+
pipeline: [analyze, implement, complete]
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
# 🛠️ qk-project-memory - Standard Operating Procedure
|
|
18
|
+
|
|
19
|
+
> **Goal:** "Bộ nhớ dài hạn". Giúp Agent nhớ lại các cấu hình, đường dẫn API hoặc luật lệ riêng của dự án mà không cần User nhắc lại.
|
|
20
|
+
|
|
21
|
+
## 🔄 1. Chain of Thought (SOP)
|
|
22
|
+
1. **Analyze (Fact Extraction):**
|
|
23
|
+
- Extract the core facts from the conversation (e.g., "The project uses pnpm, not npm").
|
|
24
|
+
2. **Implement (Storage):**
|
|
25
|
+
- Append the fact to `.ai-memory.md` or a similar configuration file.
|
|
26
|
+
|
|
27
|
+
## 🛡️ 2. Constraints & Rules
|
|
28
|
+
- **Keep it small:** Do not write entire source files into memory. Only save abstract facts and rules.
|
|
29
|
+
|
|
30
|
+
## 🤝 3. Handoff Pipeline
|
|
31
|
+
1. `complete`: Output confirmation.
|
|
32
|
+
|
|
33
|
+
## 📝 4. Output Format
|
|
34
|
+
Vui lòng trả kết quả bằng Tiếng Việt.
|
|
35
|
+
- **Tóm tắt (Summary):** Đã ghi nhớ thông tin gì.
|
|
@@ -1,315 +1,63 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: qk-system-evolution
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
1. **
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
-
|
|
61
|
-
-
|
|
62
|
-
-
|
|
63
|
-
-
|
|
64
|
-
|
|
65
|
-
---
|
|
66
|
-
|
|
67
|
-
## Scope
|
|
68
|
-
|
|
69
|
-
- ✅ Dependency version upgrades (patch, minor, major)
|
|
70
|
-
- ✅ Framework version migrations with breaking changes
|
|
71
|
-
- ✅ Library replacement (swap one library for another)
|
|
72
|
-
- ✅ Package conflict resolution
|
|
73
|
-
- ✅ Configuration updates required by new versions
|
|
74
|
-
- ✅ Code changes required by breaking API changes
|
|
75
|
-
- ✅ Rollback planning
|
|
76
|
-
|
|
77
|
-
---
|
|
78
|
-
|
|
79
|
-
## Non-goals
|
|
80
|
-
|
|
81
|
-
- ❌ Do NOT upgrade everything at once — always upgrade incrementally
|
|
82
|
-
- ❌ Do NOT skip reading the changelog/migration guide
|
|
83
|
-
- ❌ Do NOT ignore peer dependency warnings without investigating
|
|
84
|
-
- ❌ Do NOT apply breaking changes without a rollback plan
|
|
85
|
-
- ❌ Do NOT upgrade dev dependencies and prod dependencies in the same step
|
|
86
|
-
|
|
87
|
-
---
|
|
88
|
-
|
|
89
|
-
## Severity Levels
|
|
90
|
-
|
|
91
|
-
| Level | Meaning |
|
|
92
|
-
|-------|---------|
|
|
93
|
-
| P0 | Security vulnerability (CVE) — upgrade immediately |
|
|
94
|
-
| P1 | Breaking change affecting core functionality |
|
|
95
|
-
| P2 | Deprecated API with upcoming removal |
|
|
96
|
-
| P3 | Minor version lag — low risk, upgrade when convenient |
|
|
97
|
-
|
|
98
|
-
---
|
|
99
|
-
|
|
100
|
-
## Migration Types
|
|
101
|
-
|
|
102
|
-
| Type | Risk | Strategy |
|
|
103
|
-
|------|------|----------|
|
|
104
|
-
| **Patch** (1.0.x → 1.0.y) | Low | Upgrade directly, verify tests |
|
|
105
|
-
| **Minor** (1.x.0 → 1.y.0) | Low-Medium | Read changelog, upgrade, verify |
|
|
106
|
-
| **Major** (x.0.0 → y.0.0) | High | Read migration guide, upgrade incrementally, test thoroughly |
|
|
107
|
-
| **Framework** (React 17→19) | Very High | Follow official migration guide step by step |
|
|
108
|
-
| **Library swap** | High | Strangler fig pattern — migrate incrementally |
|
|
109
|
-
|
|
110
|
-
---
|
|
111
|
-
|
|
112
|
-
## Workflow
|
|
113
|
-
|
|
114
|
-
### Phase 1 — Audit Current State
|
|
115
|
-
|
|
116
|
-
Before upgrading:
|
|
117
|
-
1. List all dependencies with current versions
|
|
118
|
-
2. Identify which are outdated (use `npm outdated` / `pnpm outdated`)
|
|
119
|
-
3. Check for known CVEs (`npm audit` / `pnpm audit`)
|
|
120
|
-
4. Classify each outdated package by migration type and risk
|
|
121
|
-
5. Check peer dependency constraints
|
|
122
|
-
|
|
123
|
-
```bash
|
|
124
|
-
npm outdated # See what's outdated
|
|
125
|
-
npm audit # Security vulnerabilities
|
|
126
|
-
npx depcheck # Unused dependencies
|
|
127
|
-
```
|
|
128
|
-
|
|
129
|
-
---
|
|
130
|
-
|
|
131
|
-
### Phase 2 — Read Migration Guide
|
|
132
|
-
|
|
133
|
-
For every major version upgrade:
|
|
134
|
-
1. Read the official CHANGELOG or migration guide
|
|
135
|
-
2. List all breaking changes that affect the project
|
|
136
|
-
3. List all deprecated APIs still in use
|
|
137
|
-
4. Estimate effort: number of files to change, complexity of changes
|
|
138
|
-
|
|
139
|
-
Document findings before touching any code.
|
|
140
|
-
|
|
141
|
-
---
|
|
142
|
-
|
|
143
|
-
### Phase 3 — Plan the Migration
|
|
144
|
-
|
|
145
|
-
Create an ordered upgrade sequence:
|
|
146
|
-
|
|
147
|
-
**Rules:**
|
|
148
|
-
- Security fixes first (P0)
|
|
149
|
-
- Dev dependencies before prod dependencies (lower risk)
|
|
150
|
-
- Upgrade one major dependency at a time — not everything together
|
|
151
|
-
- Group related packages (e.g., all `@tanstack/*` together)
|
|
152
|
-
|
|
153
|
-
**Example order:**
|
|
154
|
-
```
|
|
155
|
-
Step 1: Security patch — package-x 2.1.0 → 2.1.4 (CVE fix)
|
|
156
|
-
Step 2: Dev tools — eslint 8 → 9 (no runtime impact)
|
|
157
|
-
Step 3: Minor upgrades — axios 1.4 → 1.7 (non-breaking)
|
|
158
|
-
Step 4: Major upgrade — react-query 4 → 5 (breaking — separate PR)
|
|
159
|
-
```
|
|
160
|
-
|
|
161
|
-
---
|
|
162
|
-
|
|
163
|
-
### Phase 4 — Create Rollback Plan
|
|
164
|
-
|
|
165
|
-
Before applying any change:
|
|
166
|
-
```
|
|
167
|
-
Rollback method:
|
|
168
|
-
Option A: git revert / git checkout to previous state
|
|
169
|
-
Option B: Pin version in package.json to previous known-good version
|
|
170
|
-
Option C: Feature flag to disable new behavior
|
|
171
|
-
|
|
172
|
-
Rollback trigger:
|
|
173
|
-
- Tests fail after upgrade
|
|
174
|
-
- Runtime errors in staging
|
|
175
|
-
- Performance regression detected
|
|
176
|
-
```
|
|
177
|
-
|
|
178
|
-
---
|
|
179
|
-
|
|
180
|
-
### Phase 5 — Execute the Upgrade
|
|
181
|
-
|
|
182
|
-
For each package in the plan:
|
|
183
|
-
|
|
184
|
-
1. **Upgrade package:**
|
|
185
|
-
```bash
|
|
186
|
-
npm install package-name@version
|
|
187
|
-
# or
|
|
188
|
-
pnpm add package-name@version
|
|
189
|
-
```
|
|
190
|
-
|
|
191
|
-
2. **Update configuration** (if required by new version)
|
|
192
|
-
|
|
193
|
-
3. **Fix breaking changes** in code:
|
|
194
|
-
- Update import paths
|
|
195
|
-
- Replace deprecated APIs
|
|
196
|
-
- Update type signatures
|
|
197
|
-
- Update config files
|
|
198
|
-
|
|
199
|
-
4. **Run verification** (see Phase 6) before moving to next package
|
|
200
|
-
|
|
201
|
-
---
|
|
202
|
-
|
|
203
|
-
### Phase 6 — Verify After Each Step
|
|
204
|
-
|
|
205
|
-
After every upgrade step:
|
|
206
|
-
- [ ] `npm install` / `pnpm install` — no resolution errors
|
|
207
|
-
- [ ] `npm run build` — builds successfully
|
|
208
|
-
- [ ] `npm run type-check` — no new TypeScript errors
|
|
209
|
-
- [ ] `npm run lint` — clean
|
|
210
|
-
- [ ] `npm test` — all tests pass
|
|
211
|
-
- [ ] Manual smoke test of affected features
|
|
212
|
-
|
|
213
|
-
**If any check fails → rollback this step before continuing.**
|
|
214
|
-
|
|
215
|
-
---
|
|
216
|
-
|
|
217
|
-
### Phase 7 — Library Replacement (Strangler Fig Pattern)
|
|
218
|
-
|
|
219
|
-
When replacing one library with another (e.g., moment → date-fns):
|
|
220
|
-
|
|
221
|
-
```
|
|
222
|
-
Step 1: Install new library alongside old one
|
|
223
|
-
Step 2: Create adapter/wrapper that abstracts the library
|
|
224
|
-
Step 3: Migrate usage file by file (not all at once)
|
|
225
|
-
Step 4: Verify each file after migration
|
|
226
|
-
Step 5: Remove old library when 100% migrated
|
|
227
|
-
Step 6: Remove adapter if no longer needed
|
|
228
|
-
```
|
|
229
|
-
|
|
230
|
-
This allows incremental migration with rollback possible at any step.
|
|
231
|
-
|
|
232
|
-
---
|
|
233
|
-
|
|
234
|
-
## Decision Tree
|
|
235
|
-
|
|
236
|
-
```
|
|
237
|
-
What type of upgrade?
|
|
238
|
-
├── Patch/Minor → Upgrade directly, run tests
|
|
239
|
-
├── Major → Read changelog → plan → upgrade → verify
|
|
240
|
-
└── Framework → Follow official migration guide step by step
|
|
241
|
-
|
|
242
|
-
Security vulnerability?
|
|
243
|
-
├── P0 (critical) → Upgrade immediately, prioritize over other work
|
|
244
|
-
└── P1/P2 → Include in next planned upgrade cycle
|
|
245
|
-
|
|
246
|
-
Library replacement?
|
|
247
|
-
└── Use strangler fig pattern — never replace all at once
|
|
248
|
-
```
|
|
249
|
-
|
|
250
|
-
---
|
|
251
|
-
|
|
252
|
-
## Output Format
|
|
253
|
-
|
|
254
|
-
```
|
|
255
|
-
📦 Migration Report
|
|
256
|
-
─────────────────────────────────────────────────
|
|
257
|
-
Scope: [What was upgraded / migrated]
|
|
258
|
-
Type: [Patch / Minor / Major / Framework / Library swap]
|
|
259
|
-
Risk: [Low / Medium / High]
|
|
260
|
-
|
|
261
|
-
Changes:
|
|
262
|
-
✅ package-x: 2.1.0 → 2.1.4 (CVE fix — no code changes)
|
|
263
|
-
✅ axios: 1.4.0 → 1.7.2 (minor — updated interceptor config)
|
|
264
|
-
✅ react: 18.2.0 → 19.0.0 (major — updated 12 files)
|
|
265
|
-
|
|
266
|
-
Breaking changes handled:
|
|
267
|
-
• [Description of breaking change and how it was resolved]
|
|
268
|
-
|
|
269
|
-
📋 Rollback plan:
|
|
270
|
-
git revert <commit-hash> or pin to previous version in package.json
|
|
271
|
-
|
|
272
|
-
✅ Verification:
|
|
273
|
-
Build: PASS
|
|
274
|
-
Types: Clean
|
|
275
|
-
Tests: PASS (N tests)
|
|
276
|
-
Lint: Clean
|
|
277
|
-
Smoke test: PASS
|
|
278
|
-
|
|
279
|
-
⚠️ Known issues / follow-up:
|
|
280
|
-
• [Any remaining deprecated APIs to address]
|
|
281
|
-
• [Any packages still pending upgrade]
|
|
282
|
-
```
|
|
283
|
-
|
|
284
|
-
---
|
|
285
|
-
|
|
286
|
-
## Validation Checklist
|
|
287
|
-
|
|
288
|
-
- [ ] Migration guide read for every major version change
|
|
289
|
-
- [ ] Rollback plan documented before starting
|
|
290
|
-
- [ ] Upgraded incrementally — one major change at a time
|
|
291
|
-
- [ ] `npm audit` clean after upgrade
|
|
292
|
-
- [ ] Build, types, lint, tests all pass
|
|
293
|
-
- [ ] Smoke test of affected features complete
|
|
294
|
-
- [ ] No new peer dependency warnings left unresolved
|
|
295
|
-
- [ ] Breaking changes documented in output
|
|
296
|
-
|
|
297
|
-
---
|
|
298
|
-
|
|
299
|
-
## Common Migration Cheat Sheet
|
|
300
|
-
|
|
301
|
-
```
|
|
302
|
-
React 17 → 18: Concurrent mode, new root API, Suspense updates
|
|
303
|
-
React 18 → 19: Server components, new hooks (useActionState), ref as prop
|
|
304
|
-
Vue 2 → 3: Composition API, new reactivity system, breaking changes in lifecycle
|
|
305
|
-
Next.js 12 → 13: App Router introduced (pages/ still works)
|
|
306
|
-
Next.js 13 → 14: Server Actions stable, metadata API
|
|
307
|
-
Next.js 14 → 15: React 19, async params, updated caching defaults
|
|
308
|
-
TanStack Query 4 → 5: New API (no more isLoading/isError split), object syntax
|
|
309
|
-
```
|
|
310
|
-
|
|
311
|
-
---
|
|
312
|
-
|
|
313
|
-
## Examples
|
|
314
|
-
|
|
315
|
-
See `examples/` folder.
|
|
1
|
+
---
|
|
2
|
+
name: qk-system-evolution
|
|
3
|
+
version: 3.0.0
|
|
4
|
+
updated: 2026-07-02
|
|
5
|
+
description: Safely upgrade dependencies, migrate frameworks, and manage rollbacks.
|
|
6
|
+
category: operations
|
|
7
|
+
priority: high
|
|
8
|
+
tags: [upgrade, migration, devops, dependencies]
|
|
9
|
+
platforms: [claude-code, cursor, windsurf, gemini-cli]
|
|
10
|
+
trigger: User wants to update a library, upgrade a framework (e.g., Next.js 13 to 14), or perform a major refactor.
|
|
11
|
+
inputs: [Target package, Target version]
|
|
12
|
+
outputs: [Upgraded codebase, Rollback plan]
|
|
13
|
+
allowed_tools: [run_command, grep_search, read_file]
|
|
14
|
+
pipeline: [analyze, plan, implement, validate, complete]
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
# 🛠️ qk-system-evolution - Standard Operating Procedure
|
|
18
|
+
|
|
19
|
+
> **Goal:** Quản lý các thay đổi lớn cấp hệ thống (Major Updates) một cách an toàn, luôn có đường lui (Rollback) nếu xảy ra sự cố.
|
|
20
|
+
|
|
21
|
+
## 🔄 1. Chain of Thought (SOP)
|
|
22
|
+
1. **Analyze (Impact Analysis):**
|
|
23
|
+
- Read the Changelog or Migration Guide for the new version.
|
|
24
|
+
- Identify Breaking Changes and Deprecated APIs.
|
|
25
|
+
- Search the codebase to see how many files are affected.
|
|
26
|
+
2. **Plan (Rollback Strategy):**
|
|
27
|
+
- Document the exact Git commands or NPM commands needed to revert the system if the upgrade fails completely.
|
|
28
|
+
3. **Implement (Dry-Run & Upgrade):**
|
|
29
|
+
- Apply the dependency updates in `package.json`.
|
|
30
|
+
- Run Codemods (if provided by the library).
|
|
31
|
+
- Manually fix code affected by Breaking Changes.
|
|
32
|
+
4. **Verify (System Test):**
|
|
33
|
+
- Reinstall dependencies cleanly (`npm ci` or `yarn install`).
|
|
34
|
+
- Run the build process to ensure the system compiles.
|
|
35
|
+
|
|
36
|
+
## 🛡️ 2. Constraints & Rules
|
|
37
|
+
- **Safety First:** Never run `npm update` blindly across all packages. Update only what was requested.
|
|
38
|
+
- **Lockfiles:** Do not delete `package-lock.json` or `yarn.lock` unless resolving extreme merge conflicts.
|
|
39
|
+
- **Always Rollback:** If the system produces >50 compilation errors after an upgrade and you cannot fix them in 1 turn, immediately trigger the Rollback Plan.
|
|
40
|
+
|
|
41
|
+
## 🌳 3. Decision Tree
|
|
42
|
+
```text
|
|
43
|
+
Are there Breaking Changes in the target version?
|
|
44
|
+
├── YES → Create a migration checklist based on the official docs. Update code systematically.
|
|
45
|
+
└── NO (Minor/Patch) → Update version and run tests.
|
|
46
|
+
|
|
47
|
+
Did the Build fail after the update?
|
|
48
|
+
├── YES → Are there too many errors to fix easily?
|
|
49
|
+
│ ├── YES → Execute Rollback Plan (`git reset --hard HEAD`).
|
|
50
|
+
│ └── NO → Fix the specific API changes.
|
|
51
|
+
└── NO → Proceed to Validation.
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
## 🤝 4. Handoff Pipeline
|
|
55
|
+
1. `validate`: Run the full test suite and `npm run build` via `qk-validation-gate`.
|
|
56
|
+
2. `complete`: Generate the Evolution report.
|
|
57
|
+
|
|
58
|
+
## 📝 5. Output Format
|
|
59
|
+
Vui lòng trả kết quả bằng Tiếng Việt.
|
|
60
|
+
- **Tóm tắt (Summary):** Đã nâng cấp package nào, từ vX lên vY.
|
|
61
|
+
- **Chi tiết (Changes):** Số lượng file phải sửa do Breaking Changes.
|
|
62
|
+
- **Kế hoạch lùi (Reasoning/Risks):** Ghi rõ lệnh Rollback để User copy-paste nếu cần.
|
|
63
|
+
- **Xác thực (Verification):** Kết quả của Build/Test.
|