@educa-corp/sdd-framework 0.1.0

package/skills/discovery/SKILL.tmpl

@@ -0,0 +1,14 @@
+---
+description: Dẫn dắt product discovery cho một feature mới qua Q&A có cấu trúc. Trigger when: "/define-product", "khám phá tính năng", "define new feature", "start new feature", "product discovery", "tôi muốn build tính năng mới", "let's define a feature", "begin feature discovery".
+---
+
+# /define-product — Feature Discovery (Q&A theo phase)
+
+Lệnh này thực thi **y hệt** `commands/define-product.md` — không nhân bản logic ở đây để tránh lệch cấu trúc / phase / path output.
+
+`commands/define-product.md` dẫn PO qua các phase Q&A có checkpoint:
+Knowledge Sync → Feature Definition (Context/Problem/Goal/Actor/In&Out Scope/User Story/Phụ thuộc liên service) → User Flow (kèm Edge Cases) → Clarification Log → Business Rules → Business Logic → Acceptance Criteria → Validation Report.
+
+Output ghi `{paths.product_definitions_dir}/{TICKET-ID}-{slug}.md` theo `templates/product-definition.template.md` — input cho `/generate-prd`.
+
+→ **Đọc và tuân theo `commands/define-product.md`** với cùng `$ARGUMENTS`.

package/skills/prd/SKILL.md

@@ -0,0 +1,19 @@
+---
+description: Sinh PRD từ một product definition, hoặc phân tích một PRD có sẵn qua 4 lăng kính review (QA, DEV, SA, PO) để tìm gap và rủi ro. Trigger when: "/generate-prd", "/refine-prd", "tạo PRD", "generate PRD", "phân tích PRD", "review PRD", "refine PRD", "PRD có vấn đề gì không", "check PRD quality".
+---
+
+# PRD Skills — Generate & Refine
+
+Skill này xử lý `/generate-prd` và `/refine-prd`. Để **không lệch logic/schema**, skill KHÔNG nhân bản — mỗi lệnh thực thi **y hệt** command tương ứng.
+
+## /generate-prd — Sinh Product Requirements Document
+
+→ **Đọc và tuân theo `commands/generate-prd.md`** với cùng `$ARGUMENTS`.
+
+Command lo: guard discovery completed · phân giải API Source (existing/greenfield/partner) · Terminology Map · map §1c "Phụ thuộc liên service" + §4b Wireframe · slug kế thừa · template canonical (`templates/prd.template.md`) · Change Log rolling-window.
+
+## /refine-prd — Phân tích PRD qua 4 lăng kính review
+
+→ **Đọc và tuân theo `commands/refine-prd.md`** với cùng `$ARGUMENTS`.
+
+Command lo: 4 lăng kính fan-out đa sub-agent + completeness-critic (findings đầy đủ 1 lần chạy) · schema findings đầy đủ (`uc_id`, `quote`, `auto_fixable`) cho Review Board · Resume Mode (apply → bump version → reset draft → changelog).

package/skills/prd/SKILL.tmpl

@@ -0,0 +1,19 @@
+---
+description: Sinh PRD từ một product definition, hoặc phân tích một PRD có sẵn qua 4 lăng kính review (QA, DEV, SA, PO) để tìm gap và rủi ro. Trigger when: "/generate-prd", "/refine-prd", "tạo PRD", "generate PRD", "phân tích PRD", "review PRD", "refine PRD", "PRD có vấn đề gì không", "check PRD quality".
+---
+
+# PRD Skills — Generate & Refine
+
+Skill này xử lý `/generate-prd` và `/refine-prd`. Để **không lệch logic/schema**, skill KHÔNG nhân bản — mỗi lệnh thực thi **y hệt** command tương ứng.
+
+## /generate-prd — Sinh Product Requirements Document
+
+→ **Đọc và tuân theo `commands/generate-prd.md`** với cùng `$ARGUMENTS`.
+
+Command lo: guard discovery completed · phân giải API Source (existing/greenfield/partner) · Terminology Map · map §1c "Phụ thuộc liên service" + §4b Wireframe · slug kế thừa · template canonical (`templates/prd.template.md`) · Change Log rolling-window.
+
+## /refine-prd — Phân tích PRD qua 4 lăng kính review
+
+→ **Đọc và tuân theo `commands/refine-prd.md`** với cùng `$ARGUMENTS`.
+
+Command lo: 4 lăng kính fan-out đa sub-agent + completeness-critic (findings đầy đủ 1 lần chạy) · schema findings đầy đủ (`uc_id`, `quote`, `auto_fixable`) cho Review Board · Resume Mode (apply → bump version → reset draft → changelog).

package/skills/qc/qa-analyst/DOC_GAPS.template.md

@@ -0,0 +1,63 @@
+---
+version: 1.1
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Gap Analysis – <FEATURE>
+
+> File ghi lại các **khoảng trống của tài liệu** mà `qa-analyst` phát hiện sau khi
+> phân tích. Là đầu vào để hỏi dev/BA và cho `qa-planner`. Mỗi gap có ID `GAP-xx`
+> để business rule (BR-xx), acceptance criteria (AC-xx) và test case trace ngược về.
+
+| Trường | Giá trị |
+|---|---|
+| Feature | `<FEATURE>` |
+| Project / Service | `<project or service name / domain>` |
+| Tài liệu nguồn | `<đường dẫn / link PRD / user story>` |
+| Người phân tích | qa-analyst |
+| Ngày phân tích | `<YYYY-MM-DD>` |
+| Tổng số gap | `<N>` (Blocker: x · High: y · Medium: z · Low: w) |
+| Trạng thái chung | 🔴 Blocked / 🟡 Cần làm rõ / 🟢 Đủ rõ để thiết kế TC |
+
+---
+
+## Bảng Gap
+
+| ID | Loại | Mô tả gap | Vị trí (mục/nguồn) | Ảnh hưởng (chức năng / BR / AC) | Mức độ | Người trả lời | Trạng thái | Câu trả lời |
+|---|---|---|---|---|---|---|---|---|
+| GAP-01 | MISSING | … | spec §x | chức năng A / BR-02 | 🔴 Blocker | Dev/BA | Open | — |
+| GAP-02 | AMBIGUOUS | … | mockup màn hình Y | AC-03 | 🟠 High | BA | Open | — |
+| GAP-03 | CONTRADICTORY | … | §2 vs §5 | BR-04 | 🟠 High | BA | Open | — |
+| GAP-04 | ASSUMPTION | … (giả định AI tự đưa, cần xác nhận) | — | chức năng B | 🟡 Medium | Dev | Open | — |
+
+### Loại gap
+- **MISSING** – thông tin/chức năng/field/rule chưa được mô tả.
+- **AMBIGUOUS** – mô tả mơ hồ, có ≥ 2 cách hiểu.
+- **CONTRADICTORY** – các phần tài liệu mâu thuẫn nhau.
+- **ASSUMPTION** – giả định do qa-analyst tự suy ra, cần dev/BA xác nhận.
+- **OPEN QUESTION** – câu hỏi mở cần trả lời trước khi thiết kế/triển khai.
+
+### Mức độ
+🔴 Blocker (chặn thiết kế TC) · 🟠 High · 🟡 Medium · 🟢 Low
+
+---
+
+## Quy ước cập nhật
+- `qa-analyst` tạo & điền gap khi phân tích; **không tự bịa câu trả lời** cho gap Blocker.
+- Khi có phản hồi dev/BA: điền cột *Câu trả lời*, đổi *Trạng thái* → `Answered`.
+- Còn gap 🔴 Blocker `Open` ⇒ **chưa** chuyển sang `qa-designer`; đẩy sang `qa-planner`
+  (skill `questions-for-dev`) để chốt câu hỏi.
+
+---
+
+## ⚠️ Checklist bắt buộc trước khi lưu file
+
+Trước khi lưu `DOC_GAPS.md`, kiểm tra **từng hàng** trong bảng gap:
+
+- [ ] **9 cột đủ** – đúng thứ tự: `ID | Loại | Mô tả gap | Vị trí (mục/nguồn) | Ảnh hưởng (chức năng / BR / AC) | Mức độ | Người trả lời | Trạng thái | Câu trả lời`
+- [ ] **Cột Vị trí không rỗng** – phải có tham chiếu cụ thể đến mục trong tài liệu nguồn (vd `§3 UC4 BR25`, `Appendix B loại 7`, `§4.b Screen 3`). Đây là cột hay bị bỏ thiếu nhất → gây lệch toàn bộ cột sau.
+- [ ] **Cột Ảnh hưởng = BR/AC references** – KHÔNG phải mức độ severity. Ví dụ đúng: `BR25, BR26 / AC-F01-33`. Nếu thấy "Blocker" / "High" ở đây → đang bị lệch cột.
+- [ ] **Cột Mức độ có emoji** – bắt buộc dùng: `🔴 Blocker` / `🟠 High` / `🟡 Medium` / `🟢 Low`. Không được ghi text thuần.
+- [ ] **Cột Người trả lời = vai trò** (PO / BA / Dev / Design / Content / DPO / QC Lead). Nếu thấy "Open" ở đây → đang bị lệch cột.
+- [ ] **Cột Trạng thái = Open / Answered**. Nếu thấy "—" ở đây → đang bị lệch cột.

package/skills/qc/qa-analyst/acceptance-criteria.md

@@ -0,0 +1,60 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Acceptance Criteria — Sinh tiêu chí chấp nhận
+
+Chuyển yêu cầu đã phân tích thành acceptance criteria (Given/When/Then) làm cơ sở thiết kế TC.
+
+## Khi nào trigger
+- "viết acceptance criteria cho [X]" / "định nghĩa tiêu chí pass"
+- Sau spec-breakdown + business-rules, là bước cuối của qa-analyst
+- Cần điều kiện chấp nhận rõ ràng để qa-designer trace TC ngược về
+
+## Khi KHÔNG trigger
+- Cần bóc tách spec → dùng spec-breakdown
+- Cần thiết kế test case chi tiết (steps cụ thể) → dùng qa-designer
+- Cần phân tích rủi ro → dùng qa-planner
+
+---
+
+## Phase 1 — Tổng hợp
+
+Gom đầu vào từ spec-breakdown, business-rules, data-flow:
+- Mỗi chức năng/luồng → một nhóm acceptance criteria.
+- Mỗi business rule (BR-xx) → ít nhất một AC kiểm chứng.
+
+---
+
+## Phase 2 — Viết AC
+
+Dùng format Given/When/Then, mỗi AC kiểm chứng MỘT điều:
+
+```
+AC-01 (chức năng / BR-xx):
+  Given <tiền điều kiện>
+  When  <hành động + dữ liệu cụ thể>
+  Then  <kết quả mong đợi CỤ THỂ>
+```
+
+Bắt buộc phủ:
+- Happy path (điều kiện hợp lệ).
+- Negative (vi phạm validation / authorization).
+- Boundary (giá trị biên của giới hạn trong business-rules).
+- Alternate flow (luồng phụ trong data-flow).
+
+Mỗi AC gắn mã trace: chức năng + BR-xx để TC sau này map 1-1.
+
+---
+
+## Output
+
+Ghi vào **mục Acceptance Criteria** của `{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md`
+(KHÔNG tạo file riêng — qc-analyze chỉ trả 2 file: `REQUIREMENT_ANALYSIS.md` + `DOC_GAPS.md`):
+
+- Danh sách AC dạng Given/When/Then, có mã trace về chức năng, business rule (BR-xx)
+  và scenario chính thức `{UC-ID}-SC{N}` của `.feature`.
+- Bảng ma trận: BR / chức năng × AC để xác nhận không bỏ sót.
+- Đây là đầu vào trực tiếp cho `qa-designer` (mỗi AC → ≥1 test case) và `qa-reviewer` (đối chiếu coverage).

package/skills/qc/qa-analyst/business-rules.md

@@ -0,0 +1,59 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Business Rules — Trích xuất luật nghiệp vụ
+
+Trích xuất và liệt kê toàn bộ business rule, điều kiện và ràng buộc từ yêu cầu.
+
+## Khi nào trigger
+- "liệt kê business rule cho [X]" / "feature này có luật nghiệp vụ gì"
+- Sau spec-breakdown, khi cần làm rõ logic điều kiện trước khi thiết kế TC
+- Feature có nhiều điều kiện AND/OR, phân quyền, tính toán, giới hạn
+
+## Khi KHÔNG trigger
+- Cần bóc tách tổng thể spec → dùng spec-breakdown
+- Cần luồng dữ liệu → dùng data-flow
+- Cần phân tích rủi ro / lập test plan → thuộc qa-planner (skill test-plan)
+
+---
+
+## Phase 1 — Quét
+
+1. Đọc spec đã bóc tách (output của spec-breakdown) hoặc tài liệu gốc.
+2. Quét tìm: điều kiện ("nếu… thì…"), ràng buộc field, giới hạn (min/max, rate limit),
+   quy tắc phân quyền, công thức tính, quy tắc trạng thái, default value.
+
+---
+
+## Phase 2 — Cấu trúc hoá
+
+Mỗi rule ghi dưới dạng bảng:
+
+| ID | Rule | Điều kiện | Kết quả | Nguồn | Ghi chú/Ưu tiên |
+|---|---|---|---|---|---|
+| BR-01 | … | … | … | spec §x | … |
+
+Phân loại rule:
+- VALIDATION: ràng buộc input (định dạng, bắt buộc, độ dài, range).
+- AUTHORIZATION: ai được làm gì.
+- CALCULATION: công thức, làm tròn, đơn vị.
+- STATE: điều kiện chuyển trạng thái hợp lệ vs cấm.
+- LIMIT: rate limit, quota, concurrent.
+
+Với rule có nhiều điều kiện kết hợp → gợi ý dựng **Decision Table** (đầu vào cho qa-designer).
+
+---
+
+## Output
+
+Ghi vào **mục Business Rules** của `{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md`
+(KHÔNG tạo file riêng — qc-analyze chỉ trả 2 file: `REQUIREMENT_ANALYSIS.md` + `DOC_GAPS.md`):
+
+- Bảng business rule có ID (BR-xx) để TC trace ngược về.
+- Gợi ý các rule cần Decision Table / BVA khi sang qa-designer.
+
+Rule MÂU THUẪN / KHÔNG RÕ → ghi vào `{paths.qc_dir}/{UC-ID}/DOC_GAPS.md`
+(loại CONTRADICTORY / AMBIGUOUS, cột "Ảnh hưởng" trỏ BR-xx).

package/skills/qc/qa-analyst/data-flow.md

@@ -0,0 +1,64 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Data Flow — Phân tích luồng dữ liệu
+
+Phân tích luồng dữ liệu, input/output, state và điểm tích hợp của feature.
+
+## Khi nào trigger
+- "phân tích data flow cho [X]" / "dữ liệu đi qua đâu"
+- Feature có nhiều bước, qua nhiều màn hình/API/DB, hoặc tích hợp Kafka/service khác
+- Cần xác định điểm tích hợp trước khi thiết kế integration/e2e TC
+
+## Khi KHÔNG trigger
+- Chỉ cần bóc tách spec tổng quan → dùng spec-breakdown
+- Chỉ cần luật nghiệp vụ → dùng business-rules
+- Thiết kế integration TC → dùng qa-designer/integration
+
+---
+
+## Phase 1 — Lập bản đồ
+
+Với mỗi luồng nghiệp vụ, xác định:
+1. ĐIỂM BẮT ĐẦU: actor/sự kiện kích hoạt + dữ liệu đầu vào.
+2. CÁC CHẶNG: UI → API → service → DB → message queue → service ngoài.
+3. BIẾN ĐỔI: dữ liệu được tạo/sửa/xoá/validate ở mỗi chặng.
+4. ĐIỂM KẾT THÚC: output, side-effect (email, notification, audit log).
+
+---
+
+## Phase 2 — Mô tả
+
+Thể hiện luồng dạng bước tuần tự hoặc sơ đồ text:
+
+```
+[User submit form]
+   → POST /api/... (payload: ...)
+   → Service validate (rule BR-xx)
+   → DB insert bảng X
+   → Kafka topic Y (event Z)
+   → UI hiển thị kết quả / trạng thái
+```
+
+Đánh dấu cho mỗi chặng:
+- INTEGRATION POINT (nơi cần integration test).
+- STATE CHANGE (dữ liệu/trạng thái thay đổi → cần verify + cleanup).
+- FAILURE POINT (nơi có thể lỗi: timeout, validation fail, partial commit).
+
+---
+
+## Output
+
+Ghi vào **mục Data Flow** của `{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md`
+(KHÔNG tạo file riêng — qc-analyze chỉ trả 2 file: `REQUIREMENT_ANALYSIS.md` + `DOC_GAPS.md`):
+
+- Sơ đồ/list luồng dữ liệu cho mỗi kịch bản chính.
+- Danh sách integration point + state change + failure point.
+- Gợi ý loại test cần cho từng điểm (gui-feature / integration / e2e) khi sang qa-designer.
+- Dữ liệu/trạng thái cần chuẩn bị & cleanup → đầu vào fixture cho qa-runner.
+
+Chặng nào luồng/hành vi chưa rõ (vd lỗi xử lý ra sao, retry, partial commit) →
+ghi vào `{paths.qc_dir}/{UC-ID}/DOC_GAPS.md` (loại MISSING / OPEN QUESTION).

package/skills/qc/qa-analyst/spec-breakdown.md

@@ -0,0 +1,61 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Spec Breakdown — Bóc tách yêu cầu
+
+Bóc tách spec/PRD/user story thô thành mô tả yêu cầu có cấu trúc cho QC.
+
+## Khi nào trigger
+- "phân tích spec/PRD cho feature [X]" / "bóc tách yêu cầu"
+- Nhận tài liệu thô (PRD, user story, mô tả Figma, email) cần làm rõ trước khi thiết kế TC
+- Là bước ĐẦU TIÊN của pipeline, trước qa-planner
+
+## Khi KHÔNG trigger
+- Cần phân tích rủi ro / what-if → dùng qa-planner
+- Cần trích riêng business rule → dùng business-rules
+- Cần thiết kế test case → dùng qa-designer
+
+---
+
+## Phase 1 — Thu thập
+
+1. Đọc toàn bộ tài liệu nguồn QC cung cấp (PRD, user story, mockup, ghi chú).
+2. **Bỏ qua văn bản gạch ngang (strikethrough)** — đó là nội dung đã huỷ, KHÔNG đưa
+   vào phân tích/BR/AC. Với file Confluence/HTML/MHTML: phát hiện qua thẻ `<s>`,
+   `<strike>`, `<del>` hoặc style `text-decoration: line-through`.
+3. Xác định: feature name, actor/role, mục tiêu nghiệp vụ, phạm vi (in/out scope).
+4. Đánh dấu phần MƠ HỒ / THIẾU → ghi vào `DOC_GAPS.md` (gap GAP-xx).
+
+---
+
+## Phase 2 — Bóc tách
+
+Tách yêu cầu thành các khối:
+
+A. TỔNG QUAN: mục tiêu, actor, giá trị nghiệp vụ.
+B. CHỨC NĂNG: list từng chức năng (visible + ẩn + integration point).
+C. INPUT/OUTPUT: mỗi chức năng có input gì, output gì, ràng buộc field.
+D. TRẠNG THÁI & LUỒNG: các state, điều kiện chuyển, happy path + alternate flow.
+E. PHỤ THUỘC: hệ thống/API/module liên quan.
+F. GIẢ ĐỊNH & CÂU HỎI MỞ: điều suy ra được vs điều cần dev/BA xác nhận.
+
+---
+
+## Output
+
+⚠️ `/qc-analyze` chỉ ghi **ĐÚNG 2 FILE** cho mỗi UC, đặt trong thư mục QC **lộ ra ngoài**
+`{paths.qc_dir}/{UC-ID}/` (mặc định `docs/{UC-ID}/` — KHÔNG để trong `.agent/` ẩn):
+`REQUIREMENT_ANALYSIS.md` + `DOC_GAPS.md`. KHÔNG tách mỗi bước phân tích thành file riêng.
+
+Phần spec-breakdown là **mục đầu tiên** của `REQUIREMENT_ANALYSIS.md`:
+- Bảng chức năng + input/output/constraint
+- Sơ đồ/list luồng chính & phụ
+- Danh sách giả định và câu hỏi mở (đánh dấu rõ điều CHƯA chắc)
+
+Đồng thời ghi mọi khoảng trống phát hiện vào `{paths.qc_dir}/{UC-ID}/DOC_GAPS.md`
+(theo `{paths.qc_skills_dir}/qa-analyst/DOC_GAPS.template.md`), mỗi gap có ID `GAP-xx`.
+
+Kết thúc bằng gợi ý: feature đã đủ rõ để chuyển sang `qa-planner` (phân tích rủi ro) chưa.

package/skills/qc/qa-designer/e2e/journey.md

@@ -0,0 +1,41 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Test Case — E2E Journey
+
+Skill **tự chứa** để viết TC end-to-end: hành trình đầu→cuối xuyên nhiều màn/module
+(mở → nhập → submit → verify tạo + định tuyến + đồng bộ + hiển thị). Chỉ cần load file này.
+
+## Khi nào trigger
+- "viết E2E cho [feature]" / nở danh sách journey trong TEST_PLAN thành TC chi tiết đầu-cuối
+
+## Khi KHÔNG trigger
+- Test 1 màn/field → `functional/*` · test riêng 1 điểm tích hợp → `integration/*`
+
+---
+
+## Format file TC (bắt buộc)
+- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAPS.md)`.
+- **Test Data** dạng list (tài khoản/role, dữ liệu lớp/buổi…) · **Steps** `[Action]`/`[Verify]` xuyên các màn ·
+  **Expected** 1 bullet = chuỗi verify point (tạo thành công, mã đúng, định tuyến đúng, đồng bộ đúng, hiển thị danh sách).
+- ID journey `E2E-<FEATURE>-NN` · cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
+
+## Kỹ thuật áp dụng
+- **Use Case/Scenario:** mỗi journey = main + alternate + exception flow.
+- **Decision Table** để chọn journey đại diện cho mỗi nhánh của **trục bao phủ** (vd Đối tượng × Bộ phận xử lý × lớp/buổi × role × CRM).
+- **Verify points chung** (V1…Vn) áp cho mọi journey · **end-to-end data** (nhập màn A → hiện đúng màn B/DB/hệ thống ngoài).
+
+## Phase 1 — Clarify
+Lấy danh sách journey + trục bao phủ + verify points từ TEST_PLAN · mỗi journey: actor/role, tiền điều kiện
+(data + tài khoản), bước chính, kết quả/định tuyến kỳ vọng · journey nào phụ thuộc gap Blocker.
+
+## Phase 2 — Write
+Mỗi journey → 1 TC bám Format; Expected = chuỗi verify point; chuẩn bị tiền điều kiện & cleanup, mỗi journey độc lập.
+**Journey phụ thuộc gap vẫn viết + 🚫 Block: GAP-xx**, định tuyến ghi "dự kiến theo BR". Trace BR.
+
+## Output
+File TC e2e (hoặc nhóm E2E trong file feature) trong `{paths.qc_dir}/{UC-ID}/test-cases/`.
+In bảng `E2E-ID | Journey | Pri | Trace | Block` + bảng TC block. Bàn giao `qa-reviewer`.

package/skills/qc/qa-designer/exploratory/charter.md

@@ -0,0 +1,68 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Gen Test Charter — Exploratory
+ 
+Sinh bộ test charter + SFDIPOT test ideas + What-If scenarios cho exploratory session.
+ 
+## Khi nào trigger
+- "generate charter cho [Feature]" / "chuẩn bị exploratory session"
+- Trước khi bắt đầu exploratory session
+- Feature mới chưa ai khám phá, hoặc feature có risk cao
+ 
+## Khi KHÔNG trigger
+- Cần sinh functional TC từ spec → dùng qa-designer-gui-screen / qa-designer-gui-feature
+- Cần khám phá feature rồi CHUYỂN ĐỔI thành functional TC → dùng explore-to-functional
+- Cần review charter đã viết → dùng qa-reviewer/test-case/exploratory
+ 
+---
+ 
+## Phase 1 — Clarify
+ 
+Thu thập:
+1. Feature name + mô tả ngắn
+2. Tester level — junior / mid / senior (ảnh hưởng charter complexity)
+3. Time-box — 30 / 60 / 90 phút
+4. Môi trường — staging / production-like
+5. Đã có functional TC coverage chưa (nếu có → exploratory focus vào edge case NGOÀI spec)
+ 
+---
+ 
+## Phase 2 — Analyze
+ 
+Áp dụng SFDIPOT 7 dimension:
+S - Structure: thành phần/module/page liên quan
+F - Function: chức năng chính + phụ + ẩn
+D - Data: edge data, boundary, empty, max, special chars
+I - Interface: UI, API, integration point
+P - Platform: browser, OS, device, network
+O - Operations: ai dùng, khi nào, tần suất
+T - Time: timeout, expiry, concurrent, timezone
+ 
+Với mỗi dimension: 3-5 test idea CỤ THỂ.
+ 
+Brainstorm 15-20 "What If" scenarios bất thường:
+double click, network drop, 2 tab, back button, idle 2h, emoji input, device rotate...
+ 
+---
+ 
+## Phase 3 — Write
+ 
+Sinh 3-5 charter, mỗi charter gồm:
+- Format: "Explore <target> With <resource> To discover <information>"
+- Whittaker Tour phù hợp (Money/FedEx/Saboteur/Couch Potato/Intellectual/...)
+- Risk level: HIGH / MEDIUM / LOW
+- Time-box: 30 / 60 / 90 phút
+ 
+Sinh 10-15 câu hỏi cho dev/BA (assumptions, edge case, error handling, security)
+ 
+---
+ 
+## Output
+ 
+Charter files: {paths.qc_dir}/exploratory/charters/<feature>_01.md, _02.md...
+Ideas file: {paths.qc_dir}/exploratory/ideas/<feature>.md
+Bảng tổng kết: STT | Charter | Tour | Risk | Time-box

package/skills/qc/qa-designer/exploratory/explore-to-functional.md

@@ -0,0 +1,43 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Explore-to-Functional Pipeline
+
+Skill **tự chứa**: khám phá feature (chưa/thiếu spec) → draft TC → QC review → feed
+requirement → chuyển thành functional TC chính thức. Chỉ cần load file này.
+
+## Khi nào trigger
+- Feature KHÔNG có tài liệu/spec (legacy, take-over) hoặc spec mơ hồ/thiếu
+- Cần bootstrap bộ TC nhanh cho hệ thống đang chạy · "khám phá [X] rồi tạo TC"
+
+## Khi KHÔNG trigger
+- Feature có spec rõ → `functional/gui-screen`/`gui-feature` trực tiếp
+- Chỉ cần charter cho session → `exploratory/charter`
+
+---
+
+## Phase 1 — Explore (AI tự chạy)
+Dựa trên mô tả feature: list TẤT CẢ chức năng (visible + ẩn + integration point) · mỗi chức năng
+identify input/output/state/side-effect · sinh DRAFT TC (1 happy + 2–3 edge mỗi chức năng) ·
+"what if" mỗi chức năng · list chức năng liên quan QC chưa nêu. → ĐỢI QC phản hồi.
+
+## Phase 2 — QC Review + Bổ sung
+Đợi QC confirm đúng/sai, thêm business edge case, cung cấp context → sửa → draft v2. → ĐỢI QC confirm/paste requirement.
+
+## Phase 3 — Feed Requirement (nếu có)
+So requirement vs draft: requirement chưa phủ → thêm TC · TC sai logic → sửa expected · thêm Trace BR ·
+chỉnh Priority theo business. Không có requirement → giữ draft Phase 2.
+
+## Phase 4 — Convert to Functional (format chuẩn)
+Chuyển draft → TC chính thức bám **format file `TC_<FEATURE>.md`**:
+- Metadata **list**: Title · Feature · Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags ·
+  **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có BR → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx]` nếu chặn.
+- **Test Data** dạng list · **Steps** `[Action]`/`[Verify]` · **Expected** 1 bullet cụ thể.
+- Phân nhóm GUI/Functional · cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
+- Đặt file `{paths.qc_dir}/{UC-ID}/test-cases/TC_<FEATURE>.md`.
+
+## Output
+File TC functional + bảng `TC_ID | Title | Priority | Technique | Trace`. Bàn giao `qa-reviewer`.

package/skills/qc/qa-designer/functional/api.md

@@ -0,0 +1,45 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Test Case — Functional API (không qua UI)
+
+Skill **tự chứa** để viết TC kiểm thử một API endpoint ở mức chức năng (request → response).
+Chỉ cần load file này.
+
+## Khi nào trigger
+- "viết test case cho API [method] [path]" — verify contract, validation, mã lỗi của endpoint
+
+## Khi KHÔNG trigger
+- Test qua giao diện → `functional/gui-screen`/`gui-feature`
+- Luồng dữ liệu API ↔ DB/service khác → `integration/api` · message/event → `integration/kafka`
+
+---
+
+## Format file `TC_<FEATURE>.md` (bắt buộc)
+- 1 file/feature · mỗi TC **1 concept** · metadata **list** (không bảng/emoji): Title · Feature ·
+  Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags · Trace · 🚫 Block(nếu có).
+- **Trace:** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)`; không có BR → `⚠️ Chưa có Business Rule`.
+- **🚫 Block:** TC phụ thuộc gap vẫn viết đủ + `[GAP-xx](DOC_GAPS.md) — lý do`.
+- **Test Data:** dạng **list** (request cụ thể: method/path/headers/body). **Steps:** `[Action]`/`[Verify]`.
+  **Expected:** 1 bullet nêu rõ **status code + field response cần chốt** (không ✅/❌).
+- Cuối file: **Trace matrix** (BR↔TC, ⚠️ TC thiếu BR) + **bảng TC bị block** · bỏ nội dung gạch ngang.
+
+## Kỹ thuật áp dụng
+- Mỗi field request → **EP** (phân vùng valid/invalid) + **BVA** (biên độ dài/giá trị).
+- Tổ hợp điều kiện (auth × param × state) → **Decision Table**.
+
+## Phase 1 — Clarify
+Endpoint (method/path/auth/role/content-type) · request (path/query/body schema: field, kiểu, bắt buộc, ràng buộc) ·
+response (schema thành công + các mã lỗi 4xx/5xx + body lỗi) · side-effect (nếu cần verify → cân nhắc `integration/api`).
+
+## Phase 2 — Write
+- Nhóm TC: happy (200 + schema đúng) → validation (400 từng field, dùng EP/BVA) → auth (401/403)
+  → not found (404) → edge (payload lớn, ký tự đặc biệt, rate limit).
+- Mỗi TC bám khối Format; Expected ghi status code + phần body verify; trace BR; gap chặn → 🚫 Block.
+
+## Output
+File TC (`TC_<FEATURE>_API.md` hoặc gộp trong file feature) trong `{paths.qc_dir}/{UC-ID}/test-cases/`.
+In bảng TC + Trace matrix. Bàn giao `qa-reviewer`.

package/skills/qc/qa-designer/functional/gui-feature.md

@@ -0,0 +1,46 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Test Case — Functional GUI Feature (đa màn hình)
+
+Skill **tự chứa** để viết TC functional cho feature có luồng span ≥ 2 màn hình
+(wizard, master-detail, popup→list). Chỉ cần load file này.
+
+## Khi nào trigger
+- "viết test case cho feature [X]" mà flow đi qua nhiều màn/route, truyền state giữa bước
+
+## Khi KHÔNG trigger
+- Gọn trong 1 màn → `functional/gui-screen` · API thuần → `functional/api`
+- Hành trình nghiệp vụ đầu-cuối + đồng bộ hệ thống → `e2e/journey`
+
+---
+
+## Format file `TC_<FEATURE>.md` (bắt buộc)
+- 1 file/feature · mỗi TC **1 concept** · metadata **list** (không bảng/emoji): Title · Feature ·
+  Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags · Trace · 🚫 Block(nếu có).
+- **Trace:** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)`; không có BR → `⚠️ Chưa có Business Rule`.
+- **🚫 Block:** TC phụ thuộc gap vẫn viết đủ + `[GAP-xx](DOC_GAPS.md) — lý do`.
+- **Test Data:** dạng **list** (không bảng). **Steps:** `[Action]`/`[Verify]`, không `*Expected:*`/bước. **Expected:** 1 bullet cụ thể.
+- Cuối file: **Trace matrix** (BR↔TC, ⚠️ TC thiếu BR) + **bảng TC bị block** · không `#### Python Test Mapping` · bỏ nội dung gạch ngang.
+
+## Kỹ thuật áp dụng
+- **Use Case** cho flow tổng: main (P0) → alternate (P1) → exception (negative).
+- **Decision Table** cho điểm rẽ nhánh (điều kiện qua bước/nhảy màn).
+- **State Transition** nếu có trạng thái xuyên bước (draft→submitted…).
+- **EP/BVA** cho field trên từng màn.
+
+## Phase 1 — Clarify
+Liệt kê các màn/route + thứ tự điều hướng · state/dữ liệu truyền giữa màn (giữ/reset khi back) ·
+điểm rẽ nhánh · platform · CRUD scope · cleanup.
+
+## Phase 2 — Write
+- Nhóm TC: GUI từng màn → **điều hướng** (forward/back/giữ-reset state, deep-link) → happy path xuyên flow → negative.
+- Đặc biệt phủ: back có mất dữ liệu không, dữ liệu bắt buộc để qua bước sau, hủy giữa flow.
+- Mỗi TC bám khối Format; trace BR; gap chặn → 🚫 Block.
+
+## Output
+File `TC_<FEATURE>.md` trong `{paths.qc_dir}/{UC-ID}/test-cases/`. In bảng TC + Trace matrix + bảng TC block.
+Bàn giao `qa-reviewer` (test-case).