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

package/custom/skills/gate-review/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: gate-review
+description: Generate a checkbox review file for a gate output and verify it when APPROVED is received. Called at every gate pause point in both dev and tester workflows.
+keywords: gate review, checkbox, review file, approved, mandatory review
+---
+
+# Gate Review — Mandatory Checkbox Protocol
+
+> **Purpose:** Prevent blind approval. Every gate output gets a review file with one checkbox per key section. Developer checks off items in VSCode. APPROVED is only accepted after all items are checked.
+
+---
+
+## When to invoke this skill
+
+This skill is invoked in **two modes** at every gate pause point:
+
+| Mode | When | What AI does |
+|------|------|-------------|
+| `generate` | Immediately after AI finishes gate output | Write `.aiflow/review/gate-N-[ticket].md` |
+| `verify` | When developer types `APPROVED` | Run `ak review check`, interpret result, proceed or block |
+
+---
+
+## File Naming Rules
+
+**Standard gates (Dev and Tester):**
+
+```
+.aiflow/review/gate-[N]-[ticket-id].md
+```
+
+**Tester Gate 2 sub-phases only:**
+
+Tester Gate 2 produces multiple review files — one per sub-phase. Use a letter suffix instead of the base gate number alone:
+
+```
+.aiflow/review/gate-2a-[ticket-id].md   ← first sub-phase
+.aiflow/review/gate-2b-[ticket-id].md   ← second sub-phase
+.aiflow/review/gate-2c-[ticket-id].md   ← third sub-phase
+(and so on)
+```
+
+> **IMPORTANT:** Do NOT use `gate-2-[ticket].md` for Tester Gate 2 sub-phases. Always use the lettered form (`gate-2a`, `gate-2b`, etc.) so each sub-phase has its own distinct review file and the `ak review check` command can target the correct file.
+
+---
+
+## Mode 1: GENERATE — Write Review File
+
+### Step 1: Extract checklist items from gate output
+
+Read the output you just created. For each **top-level section** in the output, create one checklist item — a one-line summary of what that section contains. The summary must be specific enough to identify the content without opening the output file.
+
+**Extraction rules:**
+- One item per top-level section (H2 heading or named block)
+- Format: `**[Section name]**: [one-line summary of actual content]`
+- Maximum 12 items per gate. If more than 12 sections, group related ones.
+- The summary is the actual content, not a description of the category. ✅ "Scope: Auth module + User management (payment OUT of scope)" not ❌ "Scope: the scope section"
+
+**Examples by gate:**
+
+Dev Gate 1 (requirement.md has 4 sections → 4 items):
+```
+- [ ] **Requirements Summary**: Add batch export endpoint returning signed S3 URL, triggered by POST /exports
+- [ ] **Proposed Solution**: New ExportService + S3Adapter; reuse existing AuthMiddleware for permissions
+- [ ] **Impact Analysis**: Medium — touches ExportController, UserService (permission check added)
+- [ ] **Effort Estimate**: M (3–4 days)
+```
+
+Tester Gate 1 (test-analysis.md):
+```
+- [ ] **Scope**: Auth module + User management only; payment and notifications OUT of scope
+- [ ] **Functional Analysis**: Login, logout, session management, password reset, role-based access (3 roles)
+- [ ] **Risk Areas**: High — session token handling; Medium — email format validation
+- [ ] **Test Approach**: 60% automation (Playwright), 40% manual; ~18 TCs estimated
+- [ ] **Effort Estimate**: M (2–3 days)
+```
+
+### Step 2: Write the review file
+
+**File path:** `.aiflow/review/gate-[N]-[ticket-id].md`
+
+For Tester Gate 2 sub-phases, use the lettered form: `.aiflow/review/gate-2a-[ticket-id].md`, `.aiflow/review/gate-2b-[ticket-id].md`, etc.
+
+Where `[ticket-id]` comes from `.aiflow/context/current.json` → `ticketId` field. If ticketId is unavailable, use `unknown`.
+
+**File template:**
+
+```markdown
+# Gate [N] Review — [TICKET-ID]
+> Status: PENDING | Generated: YYYY-MM-DD
+
+## How to review
+- Toggle `[ ]` → `[x]` for each item you have read and agree with
+- Add a comment under any item you want changed: `<!-- your comment here -->`
+- Type `APPROVED` in chat when done
+
+---
+
+## Checklist
+
+- [ ] **[Section]**: [one-line summary]
+- [ ] **[Section]**: [one-line summary]
+(... one per section, max 12)
+
+---
+
+## Review Notes
+<!-- Optional: overall notes -->
+```
+
+### Step 3: Display gate pause message
+
+After writing the file, display in chat:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+⏸️  GATE [N] PAUSED — REVIEW REQUIRED
+
+📋 Open in VSCode: [.aiflow/review/gate-[N]-[ticket-id].md](.aiflow/review/gate-[N]-[ticket-id].md)
+
+  • Toggle [ ] → [x] for each item you agree with
+  • Add <!-- comment --> under any item needing changes
+  • Type APPROVED when all items are addressed
+
+⚠️  APPROVED will not be accepted until all checkboxes are checked.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+---
+
+## Mode 2: VERIFY — Check Review File on APPROVED
+
+When the developer types `APPROVED`, run this before accepting:
+
+### Step 1: Run CLI check
+
+```bash
+ak review check --gate [N] --ticket [ticket-id]
+```
+
+For Tester Gate 2 sub-phases, pass the lettered gate identifier:
+
+```bash
+ak review check --gate 2a --ticket [ticket-id]
+ak review check --gate 2b --ticket [ticket-id]
+```
+
+### Step 2: Interpret result
+
+**Exit code 0 — all checked:**
+- Gate proceeds normally
+- Run telemetry: `ak gate [N] approved --ticket [ticket-id]`
+- Continue to next gate
+
+**Exit code 1 — file missing:**
+```
+  ✗ Review file not found for gate N, ticket PROJ-33
+```
+AI response:
+> "The review file wasn't found. Let me regenerate it."
+Then re-run Mode 1 (generate) and display the gate pause message again.
+
+**Exit code 1 — items with comments (need revision):**
+```
+  Items with comments (need AI revision):
+    • **Risk Areas**: High — session token handling
+      Comment: "Missing: SQL injection risk on login form"
+```
+AI response:
+1. Read each comment
+2. Update the specific section in the gate output file
+3. Rewrite only the flagged items in the review file (keep already-checked `[x]` items as-is)
+4. Display updated gate pause message
+
+**Exit code 1 — unchecked items, no comment:**
+```
+  Items unchecked (no comment):
+    • **Scope**: Auth module only
+```
+AI response:
+> "Item(s) are unchecked without a comment. Please either:
+> - Check `[x]` if you agree with the content, or
+> - Add `<!-- your comment -->` on the next line if you want changes."
+Do NOT re-generate. Wait for developer to update the file.
+
+---
+
+## Mandatory Rules
+
+- ❌ **NEVER** accept `APPROVED` without first running `ak review check`
+- ❌ **NEVER** re-generate already-checked `[x]` items when doing a partial revision
+- ✅ **ALWAYS** create `.aiflow/review/` directory if it doesn't exist (use `mkdir -p`)
+- ✅ **ALWAYS** use the ticket ID from `.aiflow/context/current.json` in the file name
+- ✅ **ALWAYS** keep review items specific to the actual content — not generic category names
+- ✅ **ALWAYS** use lettered suffixes (`gate-2a`, `gate-2b`, …) for Tester Gate 2 sub-phases — never plain `gate-2`

package/custom/skills/generate-test-report/SKILL.md

@@ -75,7 +75,7 @@ Coverage: [N]% acceptance criteria covered
 Recommendation: [Go / No-Go / Conditional go]
 [Nếu Conditional: điều kiện cụ thể]
 
-→ Review: test-plan/test-report.md
+→ Review: [test-plan/test-report.md](test-plan/test-report.md)
 → Type APPROVED to sign off and submit to Backlog/Jira
 → Type NO-GO: [reason] to reject release
 ```

package/custom/skills/generate-testcase/SKILL.md

@@ -21,6 +21,29 @@ Trước khi tạo bất kỳ testcase nào:
 - Nếu requirement chưa rõ → hỏi TESTER từng câu một, chờ trả lời
 - **KHÔNG tạo testcase ở bước này**
 
+**Bước 1b — Đọc Source Code (nếu workspace có source repos):**
+
+Chạy ngay sau khi đọc `test-analysis.md`, trước khi phân tích scenarios.
+
+Nếu workspace mở dạng parent folder chứa cả `ak docs` lẫn source code repos:
+
+1. Xác định repo từ `test-analysis.md` (field Repo) hoặc từ ticket context. 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 đầ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 — tìm business rules ẩn không có trong spec
+   - API response format — xác định expected result chính xác
+   - Data models / DB schema — tìm DB constraint, unique, nullable
+4. Bổ sung vào phân tích:
+   - Validation cases từ code (độ dài max, format regex, required vs optional)
+   - Business rules phát hiện trong service layer
+   - Edge cases từ DB constraint (unique violation, FK constraint)
+   - Điểm không nhất quán giữa spec và code thực tế → đặt câu hỏi với TESTER
+
+> ⚠️ Source code chỉ dùng để **mở rộng coverage** — thêm test cases dựa trên code thực tế. Expected result vẫn lấy từ ticket/spec của BA/PM, **không lấy từ code**.
+
 ---
 
 ### Bước 2 — Dev Artifacts Check (Phase 2a — trước checklist)
@@ -80,7 +103,7 @@ Liệt kê scenarios theo nhóm, output vào `test-plan/checklist.md`:
 ⏸️ GATE 2 — PHASE 2a: SCENARIOS READY
 Scenarios: [N] total
 - Functional: [N] | Non-functional: [N] | Integration: [N] | Exploratory: [N] | Regression: [N]
-→ Review: test-plan/checklist.md
+→ Review: [test-plan/checklist.md](test-plan/checklist.md)
 → Type APPROVED to proceed to Phase 2b
 ```
 
@@ -158,8 +181,8 @@ Output testcases: `test-plan/test-cases/[ScreenID]-testcases.md`
 ```
 ⏸️ GATE 2 — PHASE 2b: TESTCASES GENERATED
 Test cases: [N] total ([N] positive / [N] negative / [N] edge)
-Test plan:  test-plan/test-plan.md
-→ Review: test-plan/test-cases/
+Test plan:  [test-plan/test-plan.md](test-plan/test-plan.md)
+→ Review: [test-plan/test-cases/](test-plan/test-cases/)
 → Type APPROVED to proceed to Phase 2c (Review & Optimize)
 → Or provide feedback to update
 ```
@@ -209,11 +232,26 @@ Kiểm tra theo thứ tự, output vào `test-plan/review-report.md`:
 ```
 ⏸️ GATE 2 — PHASE 2c: REVIEW COMPLETE
 Issues: [N] duplicate | [N] problematic | [N] to optimize | [N] missing
-→ Review: test-plan/review-report.md
-→ Type APPROVED to proceed to Phase 2d (Coverage Check & Final Output)
+High priority chưa xử lý: [N]
+→ Review: [test-plan/review-report.md](test-plan/review-report.md)
+→ Type APPROVED to proceed to Phase 2d (chỉ khi High priority = 0)
 → Or provide specific fixes to apply
 ```
 
+**Nếu nhận được APPROVED mà còn issues Priority High chưa xử lý → từ chối ngay:**
+
+```
+⛔ PHASE 2c BLOCKED — Còn [N] issues Priority HIGH chưa được xử lý:
+
+| TC_ID | Vấn đề | Đề xuất sửa |
+|-------|--------|------------|
+| [TC_ID] | [vấn đề] | [đề xuất] |
+
+→ Cung cấp fixes cho các issues trên, sau đó gõ APPROVED.
+❌ APPROVED chỉ được chấp nhận khi không còn issues Priority High.
+Medium và Low có thể defer — không block APPROVED.
+```
+
 ---
 
 ## Validation Rules — 14 Field Types
@@ -301,3 +339,12 @@ Issues: [N] duplicate | [N] problematic | [N] to optimize | [N] missing
 | **High** | Chức năng chính không hoạt động đúng |
 | **Medium** | Chức năng phụ bị ảnh hưởng, workaround có thể có |
 | **Low** | UI/UX nhỏ, cosmetic, không ảnh hưởng chức năng |
+
+---
+
+## Mandatory Rules
+
+- ✅ **PHẢI** dừng và chờ APPROVED sau mỗi Phase (2a → 2b → 2c → 2d)
+- ❌ **KHÔNG chấp nhận APPROVED** ở Phase 2c khi còn issues Priority **High** chưa được xử lý — từ chối và hiển thị danh sách issues cần fix
+- ✅ Medium và Low issues không block APPROVED — có thể defer
+- ❌ **KHÔNG** tự động chuyển phase mà không có APPROVED từ TESTER

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

@@ -35,6 +35,31 @@ Một trong hai:
 
 ---
 
+### 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:
@@ -235,7 +260,7 @@ Summary:
   Approach:  [Manual / Automation / Mixed]
   Estimate:  [S / M / L / XL]
 
-→ Review: test-plan/test-analysis.md
+→ Review: [test-plan/test-analysis.md](test-plan/test-analysis.md)
 → Type APPROVED to proceed to Gate 2
 → Or provide feedback to update
 
@@ -243,6 +268,18 @@ Summary:
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
+**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
@@ -257,6 +294,7 @@ Summary:
 - ❌ **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).