@edupia-tutor/spec-driven-docs 0.14.0

package/skills/prd/SKILL.tmpl

@@ -0,0 +1,188 @@
+---
+description: Generates a PRD from a product definition, or analyzes an existing PRD through 4 review lenses (QA, DEV, SA, PO) to find gaps and risks. 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
+
+This skill handles two commands: `/generate-prd` to create a PRD, and `/refine-prd` to analyze it for gaps.
+
+---
+
+## /generate-prd — Generate Product Requirements Document
+
+### Gate
+
+<!-- Directory: specs/product-definition/**/*.md -->
+{{include:steps/gate.md}}
+
+### Generate
+
+Write `specs/{domain}/{prd-slug}/prd.md`:
+
+```markdown
+# PRD — {Feature Name}
+
+**Version**: 1.0
+**Status**: draft
+**Domain**: {domain}
+**Ticket**: {TICKET_PREFIX}-{N} (if available)
+**Date**: {date}
+
+## 1. Problem Statement
+{from product-definition}
+
+## 2. Goals & Non-Goals
+
+### Goals
+- {goal 1}
+
+### Non-Goals
+- {non-goal 1}
+
+## 3. User Stories
+
+As a {persona}, I want to {action} so that {benefit}.
+
+## 4. Use Cases
+
+| UC-ID | Name | Priority | Description |
+|-------|------|----------|-------------|
+| {DOMAIN}-UC1 | {name} | High | {description} |
+
+## 5. Business Rules
+
+| BR-ID | Rule | UC |
+|-------|------|----|
+| BR-1 | {rule} | UC1 |
+
+## 6. Acceptance Criteria
+
+### {DOMAIN}-UC1: {Name}
+- AC1: Given {context}, when {action}, then {result}
+
+## 7. Out of Scope
+{from product-definition}
+
+## 8. Cross-Service Dependencies
+{from product-definition}
+
+## 9. Open Questions
+- [ ] {question requiring clarification}
+```
+
+### Output
+
+```
+✅ PRD created: specs/{domain}/{prd-slug}/prd.md
+Status: draft
+```
+
+{{include:steps/report-footer.md}}
+
+---
+
+## /refine-prd — Analyze PRD Through 4 Review Lenses
+
+Performs a structured multi-perspective analysis of a PRD and writes findings to a YAML file for human review.
+
+### Gate
+
+<!-- Directory: specs/*/*/prd.md -->
+{{include:steps/gate.md}}
+
+### Analyze — 4 Lenses (run all four perspectives)
+
+#### QA Lens — Test Coverage & Edge Cases
+Evaluate:
+- Are all acceptance criteria testable and measurable?
+- Are edge cases and error scenarios specified?
+- Are boundary conditions defined?
+- Is there ambiguity in expected behavior?
+
+#### DEV Lens — Technical Clarity & Feasibility
+Evaluate:
+- Are API inputs/outputs clearly defined?
+- Are business rules unambiguous enough to implement?
+- Are there performance or scalability concerns?
+- Are cross-service dependencies fully described?
+- Is there anything technically infeasible or risky?
+
+#### SA Lens — Architecture & Design
+Evaluate:
+- Does this fit the existing architecture?
+- Are there design patterns or constraints to apply?
+- Is data modeling clear (entities, relationships)?
+- Are there security or auth implications?
+
+#### PO Lens — Business Value & Scope
+Evaluate:
+- Is scope clearly bounded?
+- Are priorities clear?
+- Are success metrics defined?
+- Are stakeholder needs fully captured?
+- Any scope creep risk?
+
+### Write Output
+
+Derive the output filename from the PRD slug:
+- PRD file: `specs/payment/create-invoice/prd.md` → output: `.agent/review/create-invoice-findings.yaml`
+- Rule: take the PRD's parent folder name (the `prd-slug`), append `-findings.yaml`
+
+Write findings to `.agent/review/{prd-slug}-findings.yaml`:
+
+```yaml
+# Generated by /refine-prd
+# Review each finding and mark: accepted / rejected / needs_discussion
+prd_source: "specs/{domain}/{prd-slug}/prd.md"
+generated_at: "{ISO datetime}"
+status: "pending_review"
+
+findings:
+  - id: "F001"
+    lens: "QA"           # QA | DEV | SA | PO
+    severity: "major"    # critical | major | minor
+    section: "§6. Acceptance Criteria"
+    finding: "{Clear description of the gap or issue}"
+    suggestion: "{Specific actionable improvement}"
+    status: "pending"    # pending | accepted | rejected | needs_discussion
+
+  - id: "F002"
+    lens: "DEV"
+    severity: "minor"
+    section: "§8. Cross-Service Dependencies"
+    finding: "{finding}"
+    suggestion: "{suggestion}"
+    status: "pending"
+
+summary:
+  total_findings: {N}
+  by_severity:
+    critical: {N}
+    major: {N}
+    minor: {N}
+  by_lens:
+    QA: {N}
+    DEV: {N}
+    SA: {N}
+    PO: {N}
+  recommendation: "APPROVED_WITH_MINOR_CHANGES | NEEDS_REVISION | BLOCKED"
+```
+
+### Report to User
+
+```
+/refine-prd Complete — {PRD name}
+
+Findings: {total} total
+  🔴 Critical: {N}  🟡 Major: {N}  🟢 Minor: {N}
+
+Top issues:
+  [F001] QA/major — {brief description}
+  [F002] DEV/minor — {brief description}
+
+Review file: .agent/review/{prd-slug}-findings.yaml
+→ Open with Review Board extension (right-click file) to accept/reject each finding
+→ After review: update PRD and run /generate-bdd
+```
+
+{{include:steps/report-footer.md}}

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`.