@relipa/ai-flow-kit 0.1.2 → 0.1.4-beta.0

package/custom/skills/test-analysis/SKILL.md

@@ -0,0 +1,300 @@
+---
+name: test-analysis
+description: Gate 1 — AI phân tích requirements từ ticket Backlog/Jira + fetch linked docs, hỏi clarify với TESTER (từng câu một), xác định scope/risks/approach, viết test-analysis.md. TESTER review và APPROVED để sang Gate 2.
+keywords: gate1, test analysis, requirement, scope, risk, approach, tester, clarify, ticket, backlog, jira
+---
+
+# Test Analysis — Gate 1
+
+> **GATE 1: Chạy đầu tiên, trước tất cả gates khác.**
+>
+> Principle: AI đọc ticket/requirements, hỏi clarify (từng câu một), xác định scope + risks + approach, viết test-analysis.md. TESTER review và APPROVED.
+
+---
+
+## Conditions to Enter Gate 1
+
+Một trong hai:
+- ✅ Ticket context tồn tại tại `.aiflow/context/current.json` (load qua `ak use TICKET-123`)
+- ✅ Tester mô tả feature cần test trực tiếp trong chat
+
+---
+
+## Steps
+
+### Step 1: Load Input
+
+1. Đọc `.aiflow/context/current.json` nếu tồn tại → lấy ticket title, description, acceptance criteria
+2. Nếu có `supplementaryContext[]` → đọc từng item (linked tickets, comments, files, docs)
+3. Nếu thấy URL backlog/jira trong description chưa được fetch → chạy `ak fetch-links <url>` và tích hợp kết quả
+4. Nếu không có context file → hỏi TESTER: "Bạn muốn test feature nào? Mô tả ngắn gọn hoặc paste ticket description."
+
+**Trigger kép:**
+- Sau `ak use TICKET-123`: AI auto-start Gate 1 — TESTER không cần gõ thêm lệnh
+- Sau `ak fetch-links <url>` (optional): AI tích hợp linked requirements trước khi phân tích
+
+---
+
+### Step 1b: Đọc Source Code
+
+Chạy ngay sau Step 1, trước khi bắt đầu phân tích requirements.
+
+Nếu workspace mở dạng parent folder chứa cả `ak docs` lẫn source code repos:
+
+1. Xác định repo liên quan: đọc field `repo` trong `.aiflow/context/current.json`, hoặc suy từ ticket context (tên module, màn hình). Nếu không rõ → hỏi TESTER 1 câu: "Feature này thuộc repo nào?"
+2. **Nếu GitNexus MCP có sẵn** (`.mcp.json` có entry `gitnexus`): dùng GitNexus thay vì đọc file trực tiếp:
+   - `gitnexus: query("tên màn hình hoặc chức năng")` → tìm code liên quan
+   - `gitnexus: context("ClassName")` → xem toàn bộ class/service
+3. **Nếu không có GitNexus**: đọc trực tiếp các file liên quan trong repo:
+   - Routes / API endpoints của màn hình
+   - Controller / Service — logic xử lý request
+   - Validation rules / Form request / DTO
+   - Data models / Entity / DB schema
+4. Tích hợp vào phân tích:
+   - Validation rules thực tế trong code (có thể khác với spec)
+   - Business rules ẩn trong service layer
+   - API response format thực tế
+   - Constraints từ DB schema
+
+> ⚠️ Source code chỉ dùng để **mở rộng coverage** (thêm test cases dựa trên code thực tế) và phát hiện điểm không nhất quán giữa spec và implement. Expected result vẫn lấy từ ticket/spec của BA/PM — **không lấy từ code**.
+
+---
+
+### Step 2: Phân tích Requirements
+
+Dựa trên ticket/description, phân tích:
+
+1. **Scope** — Module/màn hình/feature cụ thể đang test. Ranh giới: bao gồm gì, không bao gồm gì
+2. **Functional Analysis**:
+   - Feature Overview (mô tả tính năng)
+   - Main Flow (happy path chính)
+   - Alternative Flows (các luồng phụ)
+   - User Roles / Permissions
+   - Business Rules
+   - Validations (input/output)
+   - State / Status liên quan
+   - API / External System (nếu có)
+3. **Non-Functional Analysis**:
+   - Accessibility (WCAG, screen reader)
+   - Compatibility (Browser/Device/OS)
+4. **Risk Areas** — High-risk flows, edge cases dễ có bug
+5. **Test Approach** — Manual / Automation / Mixed + estimate số TCs
+
+---
+
+### Step 3: Clarify Q&A
+
+**Hỏi clarify khi:**
+- Acceptance criteria không đo được hoặc mơ hồ
+- Scope không rõ (in-scope vs out-of-scope)
+- Business rule có edge cases chưa được document
+- Môi trường test chưa xác định (browser, device, data)
+- Dependency với feature/ticket khác chưa rõ
+- Permission/role matrix chưa đầy đủ
+
+**Cách hỏi:** từng câu một, chờ tester trả lời trước khi hỏi tiếp.
+
+**Ví dụ:**
+> "Tester có muốn test trên mobile (iOS/Android) hay chỉ desktop browser?"
+> (chờ trả lời)
+> "Role nào có thể thực hiện action này — tất cả user hay chỉ admin?"
+
+**Khi đủ thông tin** → tiến sang Step 4 mà không cần hỏi thêm.
+
+---
+
+### Step 4: Write test-analysis.md
+
+Tạo `test-plan/test-analysis.md`:
+
+```markdown
+# Test Analysis: [Ticket ID / Feature Name]
+
+**Date:** [YYYY-MM-DD]
+**Status:** ⏸️ Waiting for TESTER Approval
+**Risk Level:** [Low / Medium / High]
+**Estimate:** [S / M / L / XL]
+
+---
+
+## 1. Scope Definition
+
+### In-Scope
+- [Module/màn hình/feature cụ thể đang test]
+- [...]
+
+### Out-of-Scope
+- [Những gì KHÔNG test trong task này]
+
+---
+
+## 2. Functional Analysis
+
+### Feature Overview
+[Mô tả tính năng — 2-3 câu]
+
+### Main Flow
+1. [Bước 1]
+2. [Bước 2]
+3. [...]
+
+### Alternative Flows
+- **Alt 1:** [Tên flow] — [Mô tả]
+- **Alt 2:** [Tên flow] — [Mô tả]
+
+### User Roles / Permissions
+| Role | Quyền | Ghi chú |
+|------|-------|---------|
+| [Role] | [Được làm gì] | [Hạn chế nếu có] |
+
+### Business Rules
+- **BR1:** [Mô tả rule]
+- **BR2:** [...]
+
+### Validations
+| Field/Action | Rule | Error Message |
+|-------------|------|---------------|
+| [Field] | [Rule] | [Message] |
+
+### State / Status
+| State | Trigger | Hành vi |
+|-------|---------|---------|
+| [State] | [Khi nào] | [Màn hình/behavior] |
+
+### API / External System
+| API | Endpoint | Mục đích |
+|-----|----------|---------|
+| [API] | [URL] | [Dùng để làm gì] |
+
+---
+
+## 3. Non-Functional Analysis
+
+### Accessibility (WCAG)
+- [ ] [Yêu cầu accessibility cụ thể]
+
+### Compatibility
+| Browser/Device | Version | Priority |
+|----------------|---------|----------|
+| Chrome Desktop | Latest | High |
+| [Other] | [...] | [...] |
+
+---
+
+## 4. Test Environment
+
+### Test Data Dependencies
+- [Data cần chuẩn bị trước khi test]
+
+### Third-party Integrations
+- [Integration cần mock hay test thật]
+
+---
+
+## 5. Requirements Clarification (Q&A)
+
+| Câu hỏi | Trả lời | Ngày |
+|---------|---------|------|
+| [Q1] | [A1] | [Date] |
+| [Q2] | [A2] | [...] |
+
+---
+
+## 6. Assumptions
+
+- [Assumption 1]
+- [Assumption 2]
+
+---
+
+## 7. Risk Areas
+
+### High-Risk Flows
+- [Flow dễ có bug — lý do]
+
+### Edge Cases cần chú ý
+- [Edge case 1]
+- [Edge case 2]
+
+---
+
+## 8. Test Approach
+
+- **Manual test cases:** [N] cases
+- **Automation (Playwright):** [N] cases
+- **Test environment:** [URL, browser, device]
+- **Test data:** [Cách chuẩn bị data]
+
+---
+
+## 9. Out of Scope
+
+- [Item 1 — lý do không test]
+- [Item 2]
+
+---
+
+## 10. Effort Estimate
+
+| Loại | Size | Ghi chú |
+|------|------|---------|
+| Gate 2 (Test Planning) | S/M/L | Khoảng [N] scenarios |
+| Gate 3 (Execution) | S/M/L | Khoảng [N] TCs |
+| Gate 4 (Report) | S | Tổng hợp kết quả |
+| **Total** | **S/M/L/XL** | |
+
+> S = <2h · M = 2–4h · L = 4–8h · XL = 8h+ (split recommended)
+```
+
+---
+
+### Step 5: Present to Tester
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+⏸️ GATE 1: TEST ANALYSIS READY
+
+Summary:
+  Scope:     [N] features / [N] flows
+  Risk:      [Low / Medium / High]
+  Approach:  [Manual / Automation / Mixed]
+  Estimate:  [S / M / L / XL]
+
+→ Review: [test-plan/test-analysis.md](test-plan/test-analysis.md)
+→ Type APPROVED to proceed to Gate 2
+→ Or provide feedback to update
+
+⚠️ I will NOT proceed to Gate 2 until I receive "APPROVED".
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+**Nếu nhận được APPROVED mà còn câu hỏi clarify (Step 3) chưa được TESTER trả lời → từ chối ngay:**
+
+```
+⛔ GATE 1 BLOCKED — Còn câu hỏi chưa được trả lời.
+
+Câu hỏi đang chờ:
+- [câu hỏi clarify chưa được trả lời]
+
+→ Vui lòng trả lời câu hỏi trên trước khi gõ APPROVED.
+❌ APPROVED không được chấp nhận khi còn câu hỏi chưa được làm rõ.
+```
+
+---
+
+### Step 6: Handle Feedback
+
+- Tester cung cấp feedback → cập nhật `test-analysis.md` → re-show Gate 1 prompt
+- Tester gõ `APPROVED` → tiến sang Gate 2 (`generate-testcase` skill)
+
+---
+
+## Mandatory Rules
+
+- ❌ **KHÔNG** tiến sang Gate 2 khi chưa nhận "APPROVED"
+- ❌ **KHÔNG** hỏi nhiều câu cùng lúc — từng câu một, chờ trả lời
+- ❌ **KHÔNG** viết code ở Gate 1
+- ❌ **KHÔNG chấp nhận APPROVED** khi còn câu hỏi clarify (Step 3) chưa được TESTER trả lời — từ chối và hiển thị câu hỏi còn lại
+- ✅ **PHẢI** lưu `test-plan/test-analysis.md`
+- ✅ **PHẢI** hiển thị Gate 1 prompt và chờ APPROVED
+- ✅ **PHẢI** xác định scope rõ ràng trước khi liệt kê flows

package/custom/skills/test-skills/categories/00-core/00.01.requirement-analysis.md

@@ -0,0 +1,111 @@
+# Mục đích
+Hiểu đúng, đủ, sâu và toàn diện yêu cầu hệ thống dưới góc nhìn của Senior QA Engineer (10+ năm kinh nghiệm) trước khi tiến hành thiết kế kịch bản kiểm thử (test scenarios) hay tạo test case. Quy trình này giúp tránh sót lọt lỗi nghiệp vụ, tối ưu hóa nguồn lực kiểm thử và kiểm soát chặt chẽ phạm vi dự án.
+
+# Input
+- Tài liệu yêu cầu nghiệp vụ: SRS, User Story, PRD, hoặc mô tả tính năng.
+- Tài liệu thiết kế giao diện (UI/UX Mockups, Figma, Wireframe - nếu có).
+- Tài liệu kỹ thuật: Mô tả API (API Specs), sơ đồ cơ sở dữ liệu (DB Schema) hoặc tài liệu kiến trúc (nếu có).
+- Phạm vi kiểm thử được chỉ định ban đầu (Module, Màn hình, hoặc Tính năng cụ thể).
+- **Source code** (nếu workspace có source repos): validation rules, service/business logic, DB schema, API endpoints — đọc trực tiếp từ code để bổ sung context thực tế.
+
+# Quy trình thực hiện
+
+## 0. Đọc Source Code (nếu workspace có source repos)
+
+Thực hiện trước tất cả các bước phân tích.
+
+Nếu workspace mở dạng parent folder chứa cả tài liệu lẫn source code repos:
+
+1. Xác định repo liên quan từ ticket hoặc tên module/màn hình. Nếu không rõ → hỏi 1 câu.
+2. **Nếu GitNexus MCP có sẵn** (`.mcp.json` có entry `gitnexus`):
+   - `gitnexus: query("tên màn hình hoặc chức năng")` → tìm code liên quan
+   - `gitnexus: context("ClassName")` → xem service/controller/validator đầy đủ
+3. **Nếu không có GitNexus**: đọc trực tiếp:
+   - Validation rules / Form request / DTO — tìm constraint thực tế (max length, regex, required)
+   - Service / Business Logic — phát hiện business rules ẩn không có trong spec
+   - Data models / DB schema — tìm DB constraint (unique, nullable, FK)
+   - API response format — xác định expected output chính xác
+4. Đưa kết quả vào mục **Validations**, **Business Rules**, và **Risk** trong báo cáo:
+   - Ghi rõ nguồn gốc: `[từ code]` để phân biệt với thông tin từ spec
+   - Đánh dấu điểm không nhất quán giữa spec và code thực tế vào **Q&A List**
+
+> ⚠️ Source code chỉ dùng để **bổ sung context** và mở rộng coverage. Expected result vẫn lấy từ ticket/spec của BA/PM.
+
+## 1. Xác định Phạm vi (Scope Definition)
+- **Feature/Module cụ thể:** Xác định chính xác module, màn hình hoặc tính năng đang thực hiện phân tích kiểm thử.
+- **Ranh giới Scope (Boundary):** Định rõ phần nào nằm trong phạm vi cần kiểm thử (In-scope) và phần nào nằm ngoài phạm vi (Out-of-scope) để tránh kiểm thử tràn lan, lãng phí thời gian.
+
+## 2. Phân tích Chức năng Chi tiết (Functional Analysis)
+- **Feature Overview:** Tóm tắt tổng quan về mục đích và vai trò của tính năng đối với người dùng cuối và hệ thống.
+- **Main Flow (Luồng chính):** Xác định luồng nghiệp vụ đi chuẩn xác (Happy Path) từ đầu tới khi hoàn thành thành công.
+- **Alternative/Exception Flows (Luồng phụ/Ngoại lệ):** Phác thảo các luồng rẽ nhánh, luồng xử lý lỗi, tình huống hủy thao tác, mất kết nối, v.v.
+- **User Roles & Permissions:** Làm rõ các tác nhân (Actor) tham gia vào hệ thống, phân quyền tương ứng của từng vai trò và mức độ ảnh hưởng của quyền hạn lên tính năng.
+- **Business Rules:** Phân tích các quy tắc nghiệp vụ ngầm định, thuật toán tính toán, quy luật kiểm tra logic.
+- **Validations:** Liệt kê đầy đủ các ràng buộc kiểm tra dữ liệu đầu vào (độ dài, định dạng, ký tự đặc biệt, trường bắt buộc) và cấu trúc dữ liệu trả ra (output).
+- **State/Status Transitions:** Theo dõi sơ đồ chuyển trạng thái của đối tượng (nếu có) và điều kiện tiên quyết (Preconditions) cũng như điều kiện đầu ra (Postconditions) để chuyển trạng thái.
+- **API & External Systems:** Nhận diện các cổng API nội bộ hoặc tích hợp từ hệ thống bên ngoài tham gia xử lý dữ liệu.
+
+## 3. Phân tích Phi chức năng (Non-Functional Analysis)
+- **Accessibility Requirements:** Kiểm tra các tiêu chuẩn hỗ trợ tiếp cận (WCAG, hỗ trợ Screen Reader cho người khiếm thị, điều hướng qua bàn phím).
+- **Compatibility:** Xác định các môi trường cần tương thích bao gồm danh sách Trình duyệt (Chrome, Safari, Firefox...), Hệ điều hành (Windows, macOS, iOS, Android...) và Thiết bị (Desktop, Mobile, Tablet...).
+
+## 4. Phân tích Môi trường & Dữ liệu Kiểm thử (Test Environment & Data)
+- **Test Data dependencies:** Xác định các phụ thuộc dữ liệu cần chuẩn bị trước khi test (ví dụ: loại tài khoản, trạng thái dữ liệu nền...).
+- **Third-party integrations:** Các bên thứ ba liên quan (cổng thanh toán, SMS OTP, CRM...) và cách thức mô phỏng (stub/mock) trên môi trường test.
+
+## 5. Phát hiện Rủi ro & Làm rõ thông tin (Clarifications & Risks)
+- **Risks / Điểm dễ lỗi:** Nhận diện các điểm phức tạp, vùng logic dễ xảy ra lỗi hệ thống (deadlock, logic loop, race conditions).
+- **Assumptions (Giả định):** Những giả định được đưa ra đối với các điểm nghiệp vụ chưa rõ ràng để định hướng kiểm thử.
+- **Q&A List:** Tổng hợp các câu hỏi làm rõ đối với các yêu cầu mơ hồ, thiếu logic hoặc mâu thuẫn để thảo luận trực tiếp với BA/Stakeholders.
+
+---
+
+# Mẫu Báo cáo Phân tích Yêu cầu (Template)
+*Kết quả phân tích yêu cầu phải được trình bày theo cấu trúc chuẩn dưới dạng **bullet point** ngắn gọn, tập trung hoàn toàn vào các nội dung phục vụ kiểm thử và tuyệt đối **không tạo test case ở bước này**.*
+
+```markdown
+# BÁO CÁO PHÂN TÍCH YÊU CẦU (REQUIREMENT ANALYSIS REPORT)
+
+## 📋 SCOPE DEFINITION
+1. **Module/Màn hình/Feature cụ thể đang test:** [Tên Module/Feature]
+2. **Ranh giới scope:**
+   - **Bao gồm (In-Scope):** [Các màn hình, luồng nghiệp vụ cụ thể cần test]
+   - **Không bao gồm (Out-of-Scope):** [Các phần không test trong đợt này]
+
+## 📋 FUNCTIONAL ANALYSIS
+3. **Feature Overview:** [Mô tả tổng quan ngắn gọn về tính năng]
+4. **Main Flow:** [Happy path - các bước thực hiện luồng chính]
+5. **Alternative Flows:** [Các luồng rẽ nhánh và luồng xử lý ngoại lệ]
+6. **User Roles / Permissions:** [Các tác nhân và phân quyền thao tác tương ứng]
+7. **Business Rules:** [Các quy tắc nghiệp vụ và ràng buộc logic bắt buộc]
+8. **Validations (input/output):** [Các ràng buộc dữ liệu đầu vào và đầu ra]
+9. **State / Status liên quan:** [Các trạng thái và điều kiện chuyển trạng thái]
+10. **API / External System liên quan (nếu có):** [Tác động DB, API endpoints, bên thứ ba]
+
+## 📋 NON-FUNCTIONAL ANALYSIS
+11. **Accessibility Requirements (WCAG, screen reader):** [Yêu cầu về khả năng tiếp cận]
+12. **Compatibility (Browser/Device/OS support):** [Môi trường cần test tương thích]
+
+## 📋 TEST ENVIRONMENT
+13. **Test Data dependencies:** [Yêu cầu về dữ liệu cần chuẩn bị trước]
+14. **Third-party integrations:** [Mô phỏng/Sandbox liên quan đến các bên thứ ba]
+
+## 📋 CLARIFICATION
+15. **Risk / điểm dễ lỗi:** [Các điểm nóng tiềm ẩn rủi ro phát sinh bug]
+16. **Q&A / Out of Scope bổ sung:** [Danh sách câu hỏi cần BA/Stakeholders làm rõ]
+```
+
+---
+
+# Output
+Bản phân tích yêu cầu hoàn chỉnh định dạng Markdown bao gồm:
+- **Feature Summary & Business Rules** đã phân tích sâu.
+- **Ranh giới Test Scope** (In-scope và Out-of-scope) rõ ràng.
+- **Dependencies & Risks** (Rủi ro, dữ liệu phụ thuộc, môi trường liên quan).
+- **Q&A List** để làm việc trực tiếp với BA/Stakeholders.
+
+⚠️ **LƯU Ý QUAN TRỌNG KHI THỰC HIỆN:**
+- Trình bày dạng bullet point ngắn gọn nhưng đầy đủ, súc tích.
+- Chỉ tập trung vào SCOPE được chỉ định, không mở rộng phân tích ra ngoài phạm vi.
+- Chỉ tập trung vào các nội dung phục vụ trực tiếp cho testing.
+- **Không tự ý generate testcase ở bước này.**

package/custom/skills/test-skills/categories/00-core/00.02.risk-analysis.md

@@ -0,0 +1,24 @@
+# Mục đích
+Nhận diện, phân loại rủi ro để tối ưu hóa nguồn lực và xác định mức độ ưu tiên kiểm thử.
+
+# Input
+- Kết quả từ 00.01 (Requirement Analysis).
+- Sơ đồ kiến trúc hệ thống (nếu có).
+
+# Quy trình thực hiện
+
+## 1. Phân tích các yếu tố rủi ro
+- **Tính phức tạp:** Thuật toán khó, logic lồng nhau.
+- **Dữ liệu:** Dữ liệu lớn, cấu trúc phức tạp, rủi ro mất mát/sai lệch dữ liệu.
+- **Tích hợp:** Kết nối API, Third-party, hệ thống Legacy.
+- **Nghiệp vụ:** Ảnh hưởng trực tiếp đến doanh thu, người dùng (Business Impact).
+- **Hệ thống:** Phân quyền, Batch processing, Migration.
+
+## 2. Đánh giá & Phân loại
+- Ưu tiên mức độ dựa trên: **Xác suất xảy ra** x **Mức độ ảnh hưởng**.
+
+# Output
+- Risk Matrix (High/Medium/Low).
+- Regression Scope (Phạm vi ảnh hưởng cần test lại).
+- Mitigation Plan (Kế hoạch giảm thiểu rủi ro).
+- Testing Priority (Thứ tự ưu tiên các kịch bản).

package/custom/skills/test-skills/categories/00-core/00.03.test-scenario-builder.md

@@ -0,0 +1,90 @@
+# Mục đích
+
+Thiết kế và xây dựng danh sách các kịch bản kiểm thử (Test Scenarios - High-level) bao phủ toàn bộ các khía cạnh nghiệp vụ, phi chức năng và rủi ro được chỉ ra trong Báo cáo phân tích yêu cầu (16 mục tiêu chuẩn) và Báo cáo phân tích rủi ro, đảm bảo không bỏ sót bất kỳ luồng xử lý nào.
+
+# Input
+
+- **Báo cáo Phân tích Yêu cầu (Requirement Analysis Report) đã xác định rõ phạm vi (In-Scope)**: Chỉ tập trung xây dựng Test Scenarios/Checklist cho các tính năng và luồng nghiệp vụ nằm trong phạm vi kiểm thử đã được xác định, tuyệt đối không thiết kế lan man ra ngoài phạm vi. Báo cáo này bao gồm thông tin chi tiết về 16 hạng mục dữ liệu sau:
+  1. *Module/Màn hình/Feature cụ thể đang test* (Để bám sát đúng phạm vi)
+  2. *Ranh giới scope* (Xác định rõ In-Scope và Out-of-Scope)
+  3. *Feature Overview*
+  4. *Main Flow*
+  5. *Alternative Flows*
+  6. *User Roles / Permissions*
+  7. *Business Rules*
+  8. *Validations (input/output)*
+  9. *State / Status liên quan*
+  10. *API / External System liên quan (nếu có)*
+  11. *Accessibility Requirements (WCAG, screen reader)*
+  12. *Compatibility (Browser/Device/OS support)*
+  13. *Test Data dependencies*
+  14. *Third-party integrations*
+  15. *Risk / điểm dễ lỗi*
+  16. *Out of Scope*
+- **Báo cáo Phân tích Rủi ro (00.02.risk-analysis.md)**.
+- **Đọc file quy ước chung (QA_Writing_Standards.md)**.
+- **Tài liệu bổ trợ (nếu có):** Thiết kế UI/UX (Figma/Mockups), API Specifications, DB Schema.
+
+# Quy trình thực hiện
+
+## 1. Thiết kế Kịch bản Đa chiều dựa trên các mục dữ liệu Phân tích Yêu cầu
+
+### A. Nhóm Chức năng (Functional Scenarios)
+
+- **Happy Path (Luồng chạy đúng chuẩn):** Thiết kế dựa trên **Mục 3 (Feature Overview)** và **Mục 4 (Main Flow)** của Báo cáo phân tích yêu cầu. Đảm bảo toàn bộ luồng chính hoạt động đúng khi người dùng nhập đúng dữ liệu và thực hiện đúng trình tự.
+- **Alternative/Exception Flows (Luồng phụ và Luồng lỗi ngoại lệ):** Thiết kế dựa trên **Mục 5 (Alternative Flows)** và **Mục 9 (State / Status liên quan)**. Kịch bản bao gồm việc chuyển đổi trạng thái sai lệch, hủy thao tác giữa chừng, mất kết nối, timeout hoặc nhập sai thông tin ở luồng phụ.
+- **Permission & Role-based (Kịch bản phân quyền):** Thiết kế dựa trên **Mục 6 (User Roles / Permissions)**. Đảm bảo mỗi kịch bản kiểm tra khả năng truy cập hợp lệ, chặn truy cập trái phép và kiểm tra lỗ hổng leo thang đặc quyền.
+- **Business Rules & Data Validations (Quy tắc nghiệp vụ & Kiểm tra dữ liệu):** Thiết kế dựa trên **Mục 7 (Business Rules)** và **Mục 8 (Validations)**. Áp dụng kỹ thuật phân tích biên, phân vùng tương đương để kiểm tra logic tính toán, ràng buộc dữ liệu đầu vào (độ dài, ký tự đặc biệt) và cấu trúc đầu ra.
+- **Integration & E2E (Kịch bản tích hợp):** Thiết kế dựa trên **Mục 10 (API / External System liên quan)**. Đảm bảo tính toàn vẹn dữ liệu truyền giữa các API và cập nhật thông tin chính xác trong Database.
+
+### B. Nhóm Phi chức năng (Non-Functional Scenarios)
+
+- **Accessibility (Tính tiếp cận):** Thiết kế dựa trên **Mục 11 (Accessibility Requirements)**. Kiểm tra tính năng tương thích với Screen Reader cho người khiếm thị, khả năng điều hướng bằng bàn phím (tab, enter) và độ tương phản màu sắc theo chuẩn WCAG.
+- **Compatibility (Tính tương thích):** Thiết kế dựa trên **Mục 12 (Compatibility)**. Đảm bảo giao diện hiển thị đúng chuẩn và chức năng hoạt động mượt mà trên nhiều trình duyệt (Chrome, Safari, Firefox), hệ điều hành (iOS, Android, Windows) và kích thước màn hình khác nhau (PC, Mobile, Tablet).
+
+### C. Nhóm Môi trường & Dữ liệu Kiểm thử (Test Environment & Data Scenarios)
+
+- **Data-Driven (Dữ liệu đặc biệt):** Thiết kế dựa trên **Mục 13 (Test Data dependencies)**. Kịch bản chạy kiểm thử lặp với các bộ dữ liệu nền/tài khoản đặc thù khác nhau (ví dụ: tài khoản bị khóa, số dư âm, khách hàng VIP).
+- **Third-Party Integration Mocking (Tích hợp bên thứ ba):** Thiết kế dựa trên **Mục 14 (Third-party integrations)**. Kịch bản kiểm tra khả năng xử lý khi API của bên thứ ba trả về lỗi, timeout hoặc trả về phản hồi không mong muốn.
+
+### D. Nhóm Kịch bản Rủi ro (Risk-Based Scenarios)
+
+- Thiết kế dựa trên **Mục 15 (Risk / điểm dễ lỗi)** từ Báo cáo phân tích yêu cầu kết hợp với danh sách phân loại rủi ro từ Báo cáo phân tích rủi ro. Tập trung vào kịch bản kiểm tra khả năng tự phục hồi lỗi hệ thống (Error Recovery) và kiểm thử phá hủy (Destructive Testing) ở các vùng nghiệp vụ phức tạp.
+
+## 2. Rà soát Độ bao phủ (Coverage Review)
+
+- Xây dựng bảng ma trận để đảm bảo 100% các mục quan trọng (từ mục 1 đến 16 của Báo cáo phân tích yêu cầu) đều được kiểm thử và ánh xạ sang ít nhất một kịch bản kiểm thử tương ứng.
+
+---
+
+# Mẫu Bảng Kịch bản Kiểm thử & Traceability Matrix (Template)
+
+```markdown
+# DANH SÁCH KỊCH BẢN KIỂM THỬ (TEST SCENARIOS LIST)
+
+| Scenario ID | Feature/Module | Check List | Scenario Type | Target Req ID (1-16) | Priority | Test Data / Dependency |
+|-------------|----------------|------------|---------------|----------------------|----------|------------------------|
+| TS_01_001   | [Tên Feature]  | [Mô tả kịch bản] | Happy Path    | Req_04 (Main Flow)   | High     | [Dữ liệu cần thiết]    |
+| TS_01_002   | [Tên Feature]  | [Mô tả kịch bản] | Negative      | Req_08 (Validations) | Medium   | [Dữ liệu cần thiết]    |
+| TS_01_003   | [Tên Feature]  | [Mô tả kịch bản] | Exception     | Req_09 (Status)      | High     | [Dữ liệu cần thiết]    |
+| TS_01_004   | [Tên Feature]  | [Mô tả kịch bản] | Permission    | Req_06 (Roles)       | High     | [Dữ liệu cần thiết]    |
+| TS_01_005   | [Tên Feature]  | [Mô tả kịch bản] | Accessibility | Req_11 (Access)      | Low      | [Screen Reader tool]   |
+| TS_01_006   | [Tên Feature]  | [Mô tả kịch bản] | Risk-based    | Req_15 (Risks)       | High     | [Dữ liệu giả lập]      |
+```
+
+---
+
+# Output
+
+Bảng danh sách kịch bản kiểm thử (Test Scenarios) hoàn chỉnh bao gồm:
+
+- **Test Scenarios List** chi tiết, đa chiều (Functional, Non-functional, Risk-based).
+- **Traceability Matrix** được tích hợp sẵn thông qua cột ánh xạ nguồn gốc yêu cầu (Target Req ID).
+- **Phân loại Priority** và xác định rõ ràng **Test Data/Dependency** cho từng kịch bản.
+
+⚠️ **LƯU Ý QUAN TRỌNG KHI THỰC HIỆN:**
+
+- Trình bày rõ ràng dưới dạng bảng (table).
+- Các mô tả kịch bản (Check List) cần ở mức High-level, tập trung vào mục tiêu kiểm thử thay vì chi tiết từng bước click chuột.
+- Đảm bảo tính bao phủ (Coverage) triệt để đối với cả 16 điểm phân tích từ Báo cáo phân tích yêu cầu.
+- Chỉ tạo các kịch bản nằm trong ranh giới In-scope (đã thống nhất tại Mục 2 của Báo cáo phân tích yêu cầu).

package/custom/skills/test-skills/categories/00-core/00.04.testcase-review.md

@@ -0,0 +1,68 @@
+# Mục đích
+
+Đảm bảo chất lượng, tính chính xác, tính khả thi và độ bao phủ toàn diện của bộ Test Case dựa trên Báo cáo phân tích yêu cầu (16 hạng mục tiêu chuẩn), Báo cáo phân tích rủi ro và phạm vi kiểm thử (Scope) đã được phê duyệt.
+
+# Input
+
+- Danh sách Test Case cần review.
+- **Báo cáo Phân tích Yêu cầu (Requirement Analysis Report) hoàn chỉnh bao gồm 16 hạng mục dữ liệu:**
+  1. *Module/Màn hình/Feature cụ thể đang test*
+  2. *Ranh giới scope* (Bao gồm gì, không bao gồm gì)
+  3. *Feature Overview*
+  4. *Main Flow*
+  5. *Alternative Flows*
+  6. *User Roles / Permissions*
+  7. *Business Rules*
+  8. *Validations (input/output)*
+  9. *State / Status liên quan*
+  10. *API / External System liên quan (nếu có)*
+  11. *Accessibility Requirements (WCAG, screen reader)*
+  12. *Compatibility (Browser/Device/OS support)*
+  13. *Test Data dependencies*
+  14. *Third-party integrations*
+  15. *Risk / điểm dễ lỗi*
+  16. *Out of Scope*
+- **Báo cáo Phân tích Rủi ro (00.02.risk-analysis.md)**
+- **Đọc file quy ước chung (QA_Writing_Standards.md)**.
+
+# Checklist kiểm tra
+
+## 1. Kiểm tra Phạm vi (Scope Definition Review)
+
+- ✅ **In-scope Coverage (Bám sát phạm vi):** Tất cả các chức năng thuộc phần In-scope (Mục 1 & 2) đều phải được thiết kế test case tương ứng.
+- ✅ **No Out-of-scope (Không dư thừa):** Tuyệt đối không tạo test case cho các phần nằm trong danh sách Out-of-scope (Mục 16) hoặc các chức năng nằm ngoài biên kiểm thử.
+
+## 2. Kiểm tra Luồng chức năng (Functional Coverage Review)
+
+- ✅ **Main Flow (Luồng chính):** Các bước kiểm thử cho luồng chính (Mục 4) có rõ ràng, logic và kết quả mong muốn có chính xác không?
+- ✅ **Alternative/Exception & Status (Luồng phụ/Ngoại lệ & Trạng thái):** Đã bao phủ hết các kịch bản lỗi, hủy thao tác (Mục 5) và các trường hợp chuyển đổi trạng thái của đối tượng (Mục 9)?
+- ✅ **User Roles & Permissions (Tác nhân & Phân quyền):** Đã kiểm thử đủ cho từng vai trò người dùng (Mục 6), bao gồm cả phân quyền hợp lệ, chặn phân quyền không hợp lệ và kiểm tra leo thang đặc quyền (nếu có)?
+- ✅ **Business Rules & Validations (Quy tắc & Ràng buộc):** Đã kiểm thử các quy tắc nghiệp vụ đặc thù (Mục 7) và các ràng buộc dữ liệu đầu vào/ra (Mục 8 - ranh giới biên, kiểu dữ liệu, định dạng)?
+- ✅ **Integration & API (Tích hợp & API):** Đã kiểm thử đầy đủ các điểm giao tiếp API và tính toàn vẹn của dữ liệu lưu vào cơ sở dữ liệu (Mục 10)?
+
+## 3. Kiểm tra Phi chức năng (Non-Functional Review)
+
+- ✅ **Accessibility (Khả năng tiếp cận):** Đã có test case kiểm thử hỗ trợ Screen Reader, độ tương phản màu sắc và phím tắt điều hướng theo chuẩn WCAG (Mục 11)?
+- ✅ **Compatibility (Tính tương thích):** Đã có kịch bản chạy thử nghiệm trên các trình duyệt, hệ điều hành và thiết bị đích được yêu cầu (Mục 12)?
+
+## 4. Kiểm tra Môi trường & Dữ liệu Kiểm thử (Environment & Data Review)
+
+- ✅ **Test Data (Dữ liệu nền):** Các điều kiện tiên quyết (Prerequisites/Preconditions) và dữ liệu test cần chuẩn bị (Mục 13) có được chỉ ra cụ thể và rõ ràng trong test case không?
+- ✅ **Third-Party (Bên thứ ba):** Đã có giải pháp mô phỏng (stub/mock) hoặc test case kiểm thử các kịch bản tích hợp bên thứ ba (Mục 14)?
+
+## 5. Kiểm tra Rủi ro & Điểm dễ lỗi (Risk-Based Review)
+
+- ✅ **High-risk Areas (Vùng rủi ro cao):** Các vùng nghiệp vụ phức tạp, dễ lỗi đã được phân tích (Mục 15) và xếp hạng ưu tiên cao trong Báo cáo phân tích rủi ro có được bao phủ bởi các kịch bản kiểm thử sâu (stress test cục bộ, error recovery...) không?
+
+## 6. Chất lượng Chi tiết của Test Case (Test Case Quality Review)
+
+- ✅ **Test Steps (Các bước thực hiện):** Rõ ràng, súc tích, không mơ hồ và có thể tái hiện được?
+- ✅ **Expected Result (Kết quả mong đợi):** Cụ thể, đo lường được (không ghi chung chung như "hệ thống hoạt động đúng").
+- ✅ **Redundancy (Tính tối ưu):** Không trùng lặp nội dung giữa các test case.
+
+---
+
+# Output
+
+- Báo cáo kết quả Review Test Case (Review Comments & Feedback).
+- Trạng thái phê duyệt (Approved / Need Update / Rejected).

package/custom/skills/test-skills/categories/01-test-design/01.01.boundary-value-analysis.md

@@ -0,0 +1,30 @@
+# 01.01. Boundary Value Analysis (Phân tích giá trị biên)
+
+## Mục đích
+Đảm bảo kiểm tra các điểm tới hạn (ranh giới) nơi lỗi thường xảy ra nhất. Kỹ thuật này giúp tối ưu hóa số lượng test case bằng cách tập trung vào các giá trị tại biên của các phân vùng tương đương, thay vì kiểm tra mọi giá trị trong dải.
+
+## Kiến thức cần có
+- Khái niệm về Phân vùng tương đương (Equivalence Partitioning).
+- Hiểu biết về dải giá trị (range), độ dài (length) và các kiểu dữ liệu (data types).
+- Logic nghiệp vụ và các điều kiện ràng buộc của hệ thống.
+
+## Quy trình thực hiện
+1. **Xác định tham số:** Liệt kê các tham số đầu vào hoặc điều kiện cần kiểm tra.
+2. **Xác định dải giá trị:** Xác định dải giá trị hợp lệ cho từng tham số (Ví dụ: Tuổi từ 18 đến 60).
+3. **Xác định các giá trị biên:** Tìm các giá trị tối thiểu (Min) và tối đa (Max).
+4. **Chọn các giá trị kiểm thử:**
+   - Tại biên: Min, Max.
+   - Sát biên (hợp lệ): Min+1, Max-1.
+   - Ngoài biên (không hợp lệ): Min-1, Max+1.
+5. **Kiểm tra độ dài:** Đối với chuỗi, kiểm tra độ dài 0 (rỗng), 1, Max, Max+1.
+
+## Checklist
+- [ ] Đã xác định đúng giá trị Min và Max dựa trên yêu cầu (SRS)?
+- [ ] Đã bao gồm các giá trị biên hợp lệ (Min, Max)?
+- [ ] Đã bao gồm các giá trị biên không hợp lệ (Min-1, Max+1)?
+- [ ] Đã xem xét các trường hợp đặc biệt như rỗng (empty), null, hoặc khoảng trắng (space)?
+- [ ] Đã kiểm tra giới hạn vật lý của kiểu dữ liệu (ví dụ: giá trị lớn nhất của Integer)?
+
+## Output mong đợi
+- Danh sách các giá trị biên cụ thể cho từng tham số.
+- Các Test case bao phủ đầy đủ các kịch bản tại ranh giới (hợp lệ và không hợp lệ).

package/custom/skills/test-skills/categories/01-test-design/01.02.equivalence.partitioning.md

@@ -0,0 +1,27 @@
+# 01.02. Equivalence Partitioning (Phân vùng tương đương)
+
+## Mục đích
+Chia dữ liệu đầu vào thành các nhóm (phân vùng) mà hệ thống xử lý theo cách tương tự nhau. Kỹ thuật này giúp giảm số lượng test case cần thực thi mà vẫn đảm bảo độ bao phủ tối đa bằng cách chỉ cần kiểm tra một giá trị đại diện cho mỗi vùng.
+
+## Kiến thức cần có
+- Hiểu về các loại dữ liệu đầu vào (String, Number, Date, v.v.).
+- Hiểu biết về logic nghiệp vụ và các quy tắc xử lý của ứng dụng.
+- Khả năng phân loại dữ liệu thành các nhóm hợp lệ và không hợp lệ.
+
+## Quy trình thực hiện
+1. **Xác định đầu vào:** Liệt kê tất cả các trường dữ liệu hoặc điều kiện đầu vào của tính năng.
+2. **Chia phân vùng:**
+   - **Vùng hợp lệ (Valid):** Các giá trị mà hệ thống phải chấp nhận và xử lý đúng.
+   - **Vùng không hợp lệ (Invalid):** Các giá trị mà hệ thống phải từ chối hoặc báo lỗi.
+3. **Chọn giá trị đại diện:** Chọn ít nhất một giá trị tiêu biểu từ mỗi phân vùng để đưa vào test case.
+4. **Thiết kế test case:** Mỗi test case nên bao phủ một hoặc nhiều vùng hợp lệ, nhưng mỗi vùng không hợp lệ nên được kiểm tra bởi một test case riêng biệt để tránh lỗi bị che lấp.
+
+## Checklist
+- [ ] Đã xác định đầy đủ các vùng hợp lệ dựa trên đặc tả?
+- [ ] Đã xác định đầy đủ các vùng không hợp lệ (sai kiểu dữ liệu, ngoài dải)?
+- [ ] Có vùng nào bị chồng chéo (overlapping) hoặc bị bỏ sót không?
+- [ ] Mỗi phân vùng đã có ít nhất một giá trị đại diện cụ thể?
+
+## Output mong đợi
+- Bảng phân vùng tương đương (Equivalence Class Table).
+- Danh sách các Test case đại diện cho tất cả các phân vùng đã xác định.