ai-developer-skill-os 8.2.0 → 8.3.0

package/.agents/docs/MIGRATION-V8.md

@@ -1,10 +1,10 @@
-# V8 Migration Protocol
-
-Every migrated skill MUST meet the following criteria before being marked as `status: stable`:
-
-- [ ] **Preserve original capability**: Do not alter the core instructions and behavior of the skill unless fixing bugs.
-- [ ] **Add V8 frontmatter**: Update the frontmatter strictly according to `_template/SKILL.md`.
-- [ ] **Map workflow**: Ensure `workflow` references an existing V8 workflow (e.g. `feature-delivery`, `bug-resolution`, `code-review`).
-- [ ] **Define verification**: Include the `verification` block with a valid `strategy`.
-- [ ] **Define selection**: Include the `selection` block with `priority` and appropriate `confidence_threshold`.
-- [ ] **Generate registry successfully**: Must pass schema validation in `node tooling/validate-skills.js` and `node tooling/generate-registry.js` without warnings.
+# V8 Migration Protocol
+
+Every migrated skill MUST meet the following criteria before being marked as `status: stable`:
+
+- [ ] **Preserve original capability**: Do not alter the core instructions and behavior of the skill unless fixing bugs.
+- [ ] **Add V8 frontmatter**: Update the frontmatter strictly according to `_template/SKILL.md`.
+- [ ] **Map workflow**: Ensure `workflow` references an existing V8 workflow (e.g. `feature-delivery`, `bug-resolution`, `code-review`).
+- [ ] **Define verification**: Include the `verification` block with a valid `strategy`.
+- [ ] **Define selection**: Include the `selection` block with `priority` and appropriate `confidence_threshold`.
+- [ ] **Generate registry successfully**: Must pass schema validation in `node tooling/validate-skills.js` and `node tooling/generate-registry.js` without warnings.

package/.agents/docs/V8-CERTIFICATION.md

@@ -1,27 +1,27 @@
-# V8 Certification
-
-V8 preserves validated V7 knowledge while introducing structured retrieval, workflow reuse, verification contracts, and lifecycle management.
-
-Skills:
-22/22 stable
-
-Registry:
-generated
-
-Schema:
-validated
-
-Legacy:
-0
-
-Retrieval tests:
-PASS
-
-Workflow tests:
-PASS
-
-Ambiguity:
-PASS
-
-Migration:
-completed
+# V8 Certification
+
+V8 preserves validated V7 knowledge while introducing structured retrieval, workflow reuse, verification contracts, and lifecycle management.
+
+Skills:
+22/22 stable
+
+Registry:
+generated
+
+Schema:
+validated
+
+Legacy:
+0
+
+Retrieval tests:
+PASS
+
+Workflow tests:
+PASS
+
+Ambiguity:
+PASS
+
+Migration:
+completed

package/.agents/docs/decisions/ADR-001-v8-migration.md

@@ -1,58 +1,58 @@
-# ADR-001: V8 Architecture Migration Strategy
-
-**Date:** 2026-07  
-**Status:** Accepted  
-**Deciders:** Quang Khánh
-
----
-
-## Context
-
-V7 (7.5.1) had 22 skills, each a monolithic SKILL.md containing:
-- Routing logic
-- Execution workflow
-- Verification steps
-- Rules and policies
-
-This made skills hard to reuse, workflows inconsistent across skills, and AI agents often confused about which skill to choose.
-
----
-
-## Decision
-
-Migrate to V8 **Agent Knowledge System** using **Structured Monolith** approach:
-
-1. **Keep skills** — don't split SKILL.md into multiple files
-2. **Add schema** — new frontmatter fields (intent, triggers, workflow ref, verification)
-3. **Extract workflows** — move execution pipelines to shared `workflows/*.yml`
-4. **Extract rules** — move global policies to `rules/*.md`
-5. **Add registry** — generated `registry/skills-index.yml` for AI retrieval
-
----
-
-## Rationale
-
-**Why not split SKILL.md into separate files?**  
-- Migration cost too high (22 skills × 4 extractions = 88 operations)
-- Risk of losing embedded knowledge in the split
-- Structured Monolith achieves the same retrieval benefit via references
-
-**Why pilot 5 skills first?**  
-- Schema may need adjustment based on real agent behavior
-- Safer to validate on 5 before committing to 22
-
-**Why keep git history instead of `archive/` folder?**  
-- V7.5.1 tagged at git → complete history available
-- Archive folder in repo creates noise for AI agents
-- Clean break is cleaner than carrying historical artifacts
-
----
-
-## Consequences
-
-- ✅ Workflows are now reusable (shared across skills)
-- ✅ AI retrieval is faster (registry index)
-- ✅ Rules are explicit and non-duplicated
-- ✅ Verification is mandatory and standardized
-- ⚠️ New schema requires migration of all 22 skills (3 weeks)
-- ⚠️ `skills.json` is now generated, not authoritative
+# ADR-001: V8 Architecture Migration Strategy
+
+**Date:** 2026-07  
+**Status:** Accepted  
+**Deciders:** Quang Khánh
+
+---
+
+## Context
+
+V7 (7.5.1) had 22 skills, each a monolithic SKILL.md containing:
+- Routing logic
+- Execution workflow
+- Verification steps
+- Rules and policies
+
+This made skills hard to reuse, workflows inconsistent across skills, and AI agents often confused about which skill to choose.
+
+---
+
+## Decision
+
+Migrate to V8 **Agent Knowledge System** using **Structured Monolith** approach:
+
+1. **Keep skills** — don't split SKILL.md into multiple files
+2. **Add schema** — new frontmatter fields (intent, triggers, workflow ref, verification)
+3. **Extract workflows** — move execution pipelines to shared `workflows/*.yml`
+4. **Extract rules** — move global policies to `rules/*.md`
+5. **Add registry** — generated `registry/skills-index.yml` for AI retrieval
+
+---
+
+## Rationale
+
+**Why not split SKILL.md into separate files?**  
+- Migration cost too high (22 skills × 4 extractions = 88 operations)
+- Risk of losing embedded knowledge in the split
+- Structured Monolith achieves the same retrieval benefit via references
+
+**Why pilot 5 skills first?**  
+- Schema may need adjustment based on real agent behavior
+- Safer to validate on 5 before committing to 22
+
+**Why keep git history instead of `archive/` folder?**  
+- V7.5.1 tagged at git → complete history available
+- Archive folder in repo creates noise for AI agents
+- Clean break is cleaner than carrying historical artifacts
+
+---
+
+## Consequences
+
+- ✅ Workflows are now reusable (shared across skills)
+- ✅ AI retrieval is faster (registry index)
+- ✅ Rules are explicit and non-duplicated
+- ✅ Verification is mandatory and standardized
+- ⚠️ New schema requires migration of all 22 skills (3 weeks)
+- ⚠️ `skills.json` is now generated, not authoritative

package/.agents/docs/decisions/ADR-002-workflow-separation.md

@@ -1,50 +1,50 @@
-# ADR-002: Workflow Separation from Skills
-
-**Date:** 2026-07  
-**Status:** Accepted
-
----
-
-## Context
-
-In V7, each SKILL.md contained its own workflow embedded in the body. This meant:
-- Workflow for bug-fixing existed in `qk-bug-resolution/SKILL.md`
-- Similar steps were duplicated across multiple skills
-- No way to reuse or compose workflows
-
----
-
-## Decision
-
-Extract workflows into dedicated `workflows/*.yml` files. Skills reference workflows by name:
-
-```yaml
-# In SKILL.md frontmatter:
-workflow: bug-resolution  # → workflows/bug-resolution.yml
-```
-
-Each workflow step MUST define `inputs` and `outputs` (not just `actions`) so agents understand what a step achieves, not just how to do it.
-
----
-
-## Rationale
-
-**Why YAML instead of Markdown?**  
-- Machine-readable: easier for agents to parse step inputs/outputs
-- Structured: enforces schema compliance
-- If found to be too rigid, can switch to Markdown+frontmatter without breaking skill references
-
-**Why inputs/outputs per step?**  
-- Agents need to know WHAT each step achieves, not just HOW
-- Enables future: step skipping based on already-available outputs
-- Better debugging: "step X failed because output Y was not produced"
-
----
-
-## Consequences
-
-- ✅ Workflows are reusable across skills
-- ✅ Each step has clear contract (inputs → outputs)
-- ✅ Easier to add new skills that reuse existing workflows
-- ⚠️ YAML can be verbose — acceptable tradeoff for clarity
-- ⚠️ If workflow changes, all referencing skills remain valid (they only reference by name)
+# ADR-002: Workflow Separation from Skills
+
+**Date:** 2026-07  
+**Status:** Accepted
+
+---
+
+## Context
+
+In V7, each SKILL.md contained its own workflow embedded in the body. This meant:
+- Workflow for bug-fixing existed in `qk-bug-resolution/SKILL.md`
+- Similar steps were duplicated across multiple skills
+- No way to reuse or compose workflows
+
+---
+
+## Decision
+
+Extract workflows into dedicated `workflows/*.yml` files. Skills reference workflows by name:
+
+```yaml
+# In SKILL.md frontmatter:
+workflow: bug-resolution  # → workflows/bug-resolution.yml
+```
+
+Each workflow step MUST define `inputs` and `outputs` (not just `actions`) so agents understand what a step achieves, not just how to do it.
+
+---
+
+## Rationale
+
+**Why YAML instead of Markdown?**  
+- Machine-readable: easier for agents to parse step inputs/outputs
+- Structured: enforces schema compliance
+- If found to be too rigid, can switch to Markdown+frontmatter without breaking skill references
+
+**Why inputs/outputs per step?**  
+- Agents need to know WHAT each step achieves, not just HOW
+- Enables future: step skipping based on already-available outputs
+- Better debugging: "step X failed because output Y was not produced"
+
+---
+
+## Consequences
+
+- ✅ Workflows are reusable across skills
+- ✅ Each step has clear contract (inputs → outputs)
+- ✅ Easier to add new skills that reuse existing workflows
+- ⚠️ YAML can be verbose — acceptable tradeoff for clarity
+- ⚠️ If workflow changes, all referencing skills remain valid (they only reference by name)

package/.agents/docs/decisions/ADR-003-registry-generated.md

@@ -1,54 +1,54 @@
-# ADR-003: Registry as Generated Artifact
-
-**Date:** 2026-07  
-**Status:** Accepted
-
----
-
-## Context
-
-V7 had `skills.json` as the primary manifest — manually maintained, often drifting from actual SKILL.md content. This created two sources of truth.
-
-V8 needs a retrieval index for AI agents to find the right skill without reading all 22 SKILL.md files.
-
----
-
-## Decision
-
-`registry/skills-index.yml` is a **generated file**. It is produced by `tooling/generate-registry.js` by reading all `SKILL.md` frontmatter.
-
-`SKILL.md` is the single source of truth. The registry is a derivative.
-
-```
-SKILL.md (source of truth)
-    ↓
-tooling/generate-registry.js
-    ↓
-registry/skills-index.yml (DO NOT EDIT MANUALLY)
-```
-
-`skills.json` is kept as a compatibility manifest for platforms that expect it (e.g., Antigravity v7 convention). It is also generated, not manually maintained.
-
----
-
-## Rationale
-
-**Why not edit the registry manually?**  
-- Two sources of truth always drift
-- Triggers, intent, complexity are already defined in SKILL.md
-- Generator can be run as a pre-commit hook or on demand
-
-**Why keep skills.json?**  
-- Antigravity and some platforms discover skills via `skills.json`
-- Backward compatibility for v7 skill consumers
-- It's generated, so no maintenance burden
-
----
-
-## Consequences
-
-- ✅ Single source of truth: SKILL.md
-- ✅ No drift between skill and registry
-- ✅ Registry update is automatic when skills are updated
-- ⚠️ Requires running generator after any SKILL.md change
-- ⚠️ If generator is not run, registry may be stale (mitigated by pre-commit hook)
+# ADR-003: Registry as Generated Artifact
+
+**Date:** 2026-07  
+**Status:** Accepted
+
+---
+
+## Context
+
+V7 had `skills.json` as the primary manifest — manually maintained, often drifting from actual SKILL.md content. This created two sources of truth.
+
+V8 needs a retrieval index for AI agents to find the right skill without reading all 22 SKILL.md files.
+
+---
+
+## Decision
+
+`registry/skills-index.yml` is a **generated file**. It is produced by `tooling/generate-registry.js` by reading all `SKILL.md` frontmatter.
+
+`SKILL.md` is the single source of truth. The registry is a derivative.
+
+```
+SKILL.md (source of truth)
+    ↓
+tooling/generate-registry.js
+    ↓
+registry/skills-index.yml (DO NOT EDIT MANUALLY)
+```
+
+`skills.json` is kept as a compatibility manifest for platforms that expect it (e.g., Antigravity v7 convention). It is also generated, not manually maintained.
+
+---
+
+## Rationale
+
+**Why not edit the registry manually?**  
+- Two sources of truth always drift
+- Triggers, intent, complexity are already defined in SKILL.md
+- Generator can be run as a pre-commit hook or on demand
+
+**Why keep skills.json?**  
+- Antigravity and some platforms discover skills via `skills.json`
+- Backward compatibility for v7 skill consumers
+- It's generated, so no maintenance burden
+
+---
+
+## Consequences
+
+- ✅ Single source of truth: SKILL.md
+- ✅ No drift between skill and registry
+- ✅ Registry update is automatic when skills are updated
+- ⚠️ Requires running generator after any SKILL.md change
+- ⚠️ If generator is not run, registry may be stale (mitigated by pre-commit hook)

package/.agents/docs/decisions/ADR-008-skill-boundary-review.md

@@ -1,27 +1,27 @@
-# ADR 008: Skill Boundary Review (V8.1.3)
-
-## Tiêu đề
-Định hướng tương lai cho ranh giới của `qk-validation-gate` và `qk-ai-builder`.
-
-## Bối cảnh
-Trong quá trình hoàn thiện Agent Engineering OS (V8.1.3), quá trình kiểm toán phát hiện rằng một số skill ban đầu có phạm vi hoạt động (scope) quá rộng hoặc chưa phân vai rõ ràng, dễ dẫn đến conflict. Tuy nhiên, để không làm vỡ kiến trúc (scope creep) trong giai đoạn chốt Control Plane, chúng ta quyết định giữ nguyên nhưng ghi chú định hướng cho V8.2.
-
-## Quyết định
-
-### 1. Về `qk-validation-gate`
-- **Hiện trạng:** Đang đóng vai trò validation coordinator.
-- **Định hướng (V8.2):** Sẽ được định hình rõ thành `release decision orchestrator`.
-- **Ranh giới tương lai:** Không trực tiếp chạy test, không trực tiếp scan security, không audit quality. Nhiệm vụ của nó là tổng hợp kết quả từ `qk-test-engineering`, `qk-security-audit`, và `qk-web-quality-gate` để ra quyết định cuối cùng (gate decision).
-
-### 2. Về `qk-ai-builder`
-- **Hiện trạng:** Đang quá rộng (gồm cả frontend AI apps, general AI coding, prompt writing...).
-- **Định hướng (V8.2):** Đổi tên (rename semantic) thành `qk-agent-platform-engineering`.
-- **Ranh giới tương lai:**
-  - **Owns:** agent architecture, MCP integration, skill generation, agent runtime patterns.
-  - **Does not own:** frontend AI apps, general AI coding, prompt writing.
-
-## Trạng thái
-Đề xuất được chấp nhận (Deferred to V8.2).
-
-## Hệ quả
-Ngăn chặn các kỹ năng này bị phình to trong quá trình triển khai thực tế. Chuẩn bị sẵn sàng cấu trúc cho giai đoạn V8.2 (Self-Improving Agent).
+# ADR 008: Skill Boundary Review (V8.1.3)
+
+## Tiêu đề
+Định hướng tương lai cho ranh giới của `qk-validation-gate` và `qk-ai-builder`.
+
+## Bối cảnh
+Trong quá trình hoàn thiện Agent Engineering OS (V8.1.3), quá trình kiểm toán phát hiện rằng một số skill ban đầu có phạm vi hoạt động (scope) quá rộng hoặc chưa phân vai rõ ràng, dễ dẫn đến conflict. Tuy nhiên, để không làm vỡ kiến trúc (scope creep) trong giai đoạn chốt Control Plane, chúng ta quyết định giữ nguyên nhưng ghi chú định hướng cho V8.2.
+
+## Quyết định
+
+### 1. Về `qk-validation-gate`
+- **Hiện trạng:** Đang đóng vai trò validation coordinator.
+- **Định hướng (V8.2):** Sẽ được định hình rõ thành `release decision orchestrator`.
+- **Ranh giới tương lai:** Không trực tiếp chạy test, không trực tiếp scan security, không audit quality. Nhiệm vụ của nó là tổng hợp kết quả từ `qk-test-engineering`, `qk-security-audit`, và `qk-web-quality-gate` để ra quyết định cuối cùng (gate decision).
+
+### 2. Về `qk-ai-builder`
+- **Hiện trạng:** Đang quá rộng (gồm cả frontend AI apps, general AI coding, prompt writing...).
+- **Định hướng (V8.2):** Đổi tên (rename semantic) thành `qk-agent-platform-engineering`.
+- **Ranh giới tương lai:**
+  - **Owns:** agent architecture, MCP integration, skill generation, agent runtime patterns.
+  - **Does not own:** frontend AI apps, general AI coding, prompt writing.
+
+## Trạng thái
+Đề xuất được chấp nhận (Deferred to V8.2).
+
+## Hệ quả
+Ngăn chặn các kỹ năng này bị phình to trong quá trình triển khai thực tế. Chuẩn bị sẵn sàng cấu trúc cho giai đoạn V8.2 (Self-Improving Agent).

package/.agents/registry/graph.json

@@ -1,7 +1,7 @@
 {
   "schema_version": 1,
   "manifest_version": "8.2",
-  "generated_at": "2026-07-27T02:25:53.340Z",
+  "generated_at": "2026-07-29T04:03:48.864Z",
   "nodes": {
     "qk-access-policy": {
       "path": ".agents/skills/qk-access-policy",
@@ -361,14 +361,12 @@
     },
     "qk-ui-builder": {
       "path": ".agents/skills/qk-ui-builder",
-      "version": "8.0.0",
+      "version": "8.2.0",
       "tags": [
         "ui",
         "builder"
       ],
-      "dependencies": [
-        "feature-delivery"
-      ],
+      "dependencies": [],
       "dependents": [
         "qk-frontend-architecture"
       ],
@@ -506,9 +504,7 @@
     "qk-ui-audit": [
       "code-review"
     ],
-    "qk-ui-builder": [
-      "feature-delivery"
-    ],
+    "qk-ui-builder": [],
     "qk-ui-system-builder": [
       "feature-delivery"
     ],

package/.agents/registry/index.yaml

@@ -2,7 +2,7 @@
 # DO NOT EDIT MANUALLY. THIS IS A GENERATED RUNTIME ARTIFACT.
 schema_version: 1
 manifest_version: '8.2'
-generated_at: '2026-07-27T02:25:53.341Z'
+generated_at: '2026-07-29T04:03:48.865Z'
 capabilities:
   qk-access-policy:
     path: .agents/skills/qk-access-policy
@@ -225,12 +225,11 @@ capabilities:
       - code-review
   qk-ui-builder:
     path: .agents/skills/qk-ui-builder
-    version: 8.0.0
+    version: 8.2.0
     tags:
       - ui
       - builder
-    dependencies:
-      - feature-delivery
+    dependencies: []
   qk-ui-system-builder:
     path: .agents/skills/qk-ui-system-builder
     version: 8.0.0