@relipa/ai-flow-kit 0.1.3 → 0.1.4

package/custom/skills/ba-skills/skill-ba-phan-tich-ban-dau-v1.md

@@ -0,0 +1,44 @@
+# Skill: Phân tích yêu cầu ban đầu (BA Analyst) - Phiên bản v1
+
+## 1. Mục đích (Purpose)
+Kỹ năng này giúp Business Analyst (hoặc Agent) quét, đọc hiểu và cấu trúc hóa các yêu cầu thô được cung cấp bởi khách hàng hoặc các stakeholders. Mục tiêu là phân tách rõ ràng giữa các thông tin thực tế (Facts) và các giả định (Assumptions), phát hiện các khoảng trống nghiệp vụ (Gaps), và tạo cơ sở cho việc lập danh sách câu hỏi làm rõ (Q&A) cũng như dự thảo spec ban đầu.
+
+## 2. Kiến thức cần có (Prerequisite Knowledge)
+- **Tư duy phân tích (Analytical Thinking):** Khả năng chia nhỏ một yêu cầu lớn thành các luồng nghiệp vụ nhỏ và các thành phần cấu thành.
+- **Phân biệt Fact vs. Assumption:**
+  - *Fact (Sự thật):* Thông tin được ghi rõ ràng trong tài liệu, được khẳng định từ khách hàng.
+  - *Assumption (Giả định):* Những giả thiết do BA đưa ra dựa trên kinh nghiệm hoặc ngữ cảnh mà chưa được khách hàng xác nhận bằng văn bản.
+- **Kỹ thuật Gap Analysis:** Kỹ thuật nhận diện các điểm chưa thống nhất, các thông tin bị thiếu (ví dụ: thiếu thông báo lỗi khi validate thất bại, thiếu quy tắc lưu trữ vào cơ sở dữ liệu, thiếu mô tả quyền truy cập).
+- **Thuật ngữ phần mềm cơ bản:** Khách hàng (Client), Người dùng (User), Tác nhân (Actor), Ràng buộc (Constraints), Luồng chính (Happy Path), Trường hợp ngoại lệ (Edge cases).
+
+## 3. Quy trình thực hiện (Step-by-step Process)
+- **Bước 1: Tiếp nhận và đọc quét (Read & Scan):**
+  Đọc toàn bộ tài liệu đầu vào (ví dụ trong folder `TÀI LIỆU/input/`) ít nhất 2 lần để nắm bức tranh tổng thể và ngữ cảnh nghiệp vụ.
+  Sau đó đọc source code liên quan (nếu workspace có source repos):
+  - Ưu tiên đọc: data models/entity, API endpoints hiện tại, service/business logic
+  - Mục đích: hiểu hệ thống đang tồn tại, tìm constraints kỹ thuật, tránh đề xuất mâu thuẫn architecture
+  - Nếu GitNexus MCP có sẵn: dùng `gitnexus: query()` / `gitnexus: context()` thay vì đọc file trực tiếp
+- **Bước 2: Phân loại thông tin (Categorize):**
+  Trích xuất các thông tin theo các cấu trúc:
+    - Mục tiêu của chức năng.
+    - Các tác nhân tham gia vào luồng.
+    - Các yêu cầu chức năng (các hành động, nút bấm, trường thông tin).
+    - Các yêu cầu phi chức năng (bảo mật, hiệu năng, nền tảng hệ điều hành/trình duyệt).
+- **Bước 3: Nhận diện và ghi nhận Gap (Identify Gaps):**
+  Đối chiếu từng yêu cầu chức năng với các câu hỏi:
+    - Dữ liệu đầu vào của trường này có giới hạn độ dài/định dạng không?
+    - Nếu để trống thì hệ thống xử lý thế nào? Có thông báo lỗi gì không?
+    - Có quy tắc nghiệp vụ (Business rules) ngầm định nào không?
+    - Luồng thay thế (Alternative flows) hoặc luồng lỗi (Exception flows) là gì?
+- **Bước 4: Soạn dự thảo Kết quả phân tích ban đầu:**
+  Áp dụng template phân tích ban đầu (`skill-ba-template-phan-tich-ban-dau-v1.md`) để điền thông tin và lập bảng Gap/Assumption.
+
+## 4. Checklist kiểm tra (Checklist for Verification)
+- [ ] Đã xác định rõ Mục tiêu hệ thống/chức năng chưa? (Hệ thống giải quyết bài toán gì?)
+- [ ] Đã làm rõ tất cả các Tác nhân (Actors) tham gia chưa?
+- [ ] Đã bóc tách hết các trường thông tin (Inputs) được liệt kê trong tài liệu thô chưa?
+- [ ] Đã ghi nhận rõ ràng danh sách các điểm mơ hồ hoặc thiếu thông tin dưới dạng **Gap/Assumption** chưa?
+- [ ] Không tự tiện bổ sung các tính năng ngoài phạm vi yêu cầu của khách hàng khi chưa có thảo luận/Q&A.
+
+## 5. Output mong đợi (Expected Output)
+- File tài liệu phân tích ban đầu định dạng markdown, cấu trúc thống nhất dựa theo `@skill-ba-template-phan-tich-ban-dau-v1.md`, đặt tên theo chuẩn: `Tên chức năng_Kết quả phân tích(n).md` trong thư mục `TÀI LIỆU/output/Kết quả phân tích/`.

package/custom/skills/ba-skills/skill-ba-prototype-v1.md

@@ -0,0 +1,35 @@
+# Skill: Thiết kế Layout và Prototype HTML/CSS - Phiên bản v1
+
+## 1. Mục đích (Purpose)
+Kỹ năng này hướng dẫn BA thiết kế và hiện thực hóa giao diện người dùng (UI mockup/prototype) dưới dạng mã nguồn HTML/CSS tự chứa (self-contained). Prototype giúp khách hàng hình dung trực quan luồng đi của màn hình, đồng thời giúp lập trình viên và kiểm thử viên xác định chính xác cấu trúc trang, ID của các phần tử và vị trí hiển thị lỗi.
+
+## 2. Kiến thức cần có (Prerequisite Knowledge)
+- **HTML5 Semantic Tags:** Sử dụng các thẻ ngữ nghĩa như `<header>`, `<main>`, `<section>`, `<nav>`, `<form>`, `<input>`, `<button>`, `<label>` để trang web có cấu trúc chuẩn SEO và dễ kiểm thử.
+- **Vanilla CSS Layouts:** Thành thạo Flexbox và CSS Grid để dựng bố cục nhanh chóng, đáp ứng tốt trên các kích thước màn hình khác nhau (Responsive).
+- **Nguyên lý UX/UI cơ bản:**
+  - *Primary Flow & Visual Hierarchy:* Làm nổi bật các thành phần quan trọng bằng kích thước, màu sắc và độ tương phản (ví dụ: nút bấm chính).
+  - *Bố cục F-pattern & Z-pattern:* Đặt tiêu đề, logo ở góc trên bên trái, thông tin quan trọng chạy ngang và chéo xuống nút bấm thực thi ở góc dưới bên phải.
+  - *Khoảng trắng (Whitespace):* Giữ khoảng cách hợp lý giữa các nhóm thông tin (Chunking) để tránh rối mắt.
+
+## 3. Quy trình thực hiện (Step-by-step Process)
+- **Bước 1: Phân tích các thành phần (Wireframing mentally):**
+  Dựa trên tài liệu phân tích, liệt kê tất cả các phần tử UI cần có (ví dụ: Logo, Tiêu đề, Ô nhập ID, Ô nhập Password, Nút Đăng nhập, Link Quên mật khẩu, Vùng hiển thị lỗi).
+- **Bước 2: Dựng khung HTML:**
+  - Viết mã HTML chuẩn. Bắt buộc đặt các thuộc tính `id`, `name`, `type`, `placeholder` rõ ràng cho các ô nhập liệu (ví dụ: `<input type="text" id="username" name="username"...>`).
+  - Đưa các thông báo lỗi (Error message) vào đúng vị trí dưới các ô nhập liệu, gán class dạng `.error-message` hoặc `.inline-error` và tạm ẩn đi bằng CSS (`display: none;` hoặc thông qua trạng thái ẩn) nhưng vẫn có mặt trong mã nguồn để Tester biết vị trí hiển thị.
+- **Bước 3: Tạo kiểu dáng CSS:**
+  - Sử dụng thẻ `<style>` nội bộ nằm ngay trong file HTML (để file HTML tự chứa tất cả tài nguyên, dễ chia sẻ và import vào tài liệu spec).
+  - Sử dụng bảng màu hiện đại (tránh màu đỏ/xanh lá gốc, dùng các màu trung tính, dịu mắt phối hợp hiệu ứng hover cho các nút bấm).
+  - Đảm bảo thiết kế responsive cơ bản bằng media queries nếu cần.
+- **Bước 4: Kiểm tra và lưu trữ:**
+  Mở file HTML trên trình duyệt để kiểm tra trực quan. Lưu vào thư mục `TÀI LIỆU/output/design/`.
+
+## 4. Checklist kiểm tra (Checklist for Verification)
+- [ ] File HTML có tự chứa toàn bộ CSS không? (Không liên kết tới file CSS bên ngoài trừ font chữ hệ thống).
+- [ ] Tất cả các trường nhập liệu đã có thẻ `<label>` tương ứng và thuộc tính `id`, `name` chưa?
+- [ ] Vị trí các thông báo lỗi (Alert và Inline error) đã được dựng sẵn trong code và định dạng rõ ràng chưa?
+- [ ] Giao diện có hiển thị cân đối trên cả màn hình Desktop và Mobile không?
+- [ ] Các phần tử tương tác (Button, Link, Input) có hiệu ứng trực quan khi hover hoặc focus không?
+
+## 5. Output mong đợi (Expected Output)
+- Một file HTML độc lập chứa đầy đủ code HTML và CSS nội bộ, đặt tên theo chuẩn: `Tên chức năng_design.html` trong thư mục `TÀI LIỆU/output/design/`.

package/custom/skills/ba-skills/skill-ba-qa-template-v1.md

@@ -0,0 +1,21 @@
+# Skill: Template Q&A - Phiên bản v1
+
+Mẫu tài liệu dùng để trình bày danh sách câu hỏi Q&A và theo dõi phản hồi từ khách hàng.
+
+---
+
+# Tài liệu Q&A: [Tên Chức Năng]
+
+*Tài liệu này dùng để theo dõi các vấn đề nghiệp vụ cần làm rõ giữa đội ngũ dự án và khách hàng. Trạng thái bao gồm: **Open** (Đang chờ phản hồi), **Confirmed** (Đã thống nhất).*
+
+## Danh sách câu hỏi Q&A
+
+| ID | Chức năng / Màn hình | Nội dung yêu cầu hiện tại | Câu hỏi / Điểm chưa rõ | Đề xuất giải pháp (Options) | Câu trả lời của Khách hàng | Trạng thái |
+| :-: | :--- | :--- | :--- | :--- | :--- | :-: |
+| **QA-01** | *Đăng nhập* | *Có text link đổi mật khẩu* | *Text link này sẽ dẫn sang URL cụ thể nào? Hệ thống tự sinh OTP gửi mail hay chuyển sang màn nhập email?* | *- Option A: Chuyển sang URL `/forgot-password` để nhập Email nhận link reset.<br>- Option B: Hiển thị popup nhập SĐT nhận OTP.* | *Khách hàng phản hồi: Chọn Option A, link URL là `/forgot-password`* | **Confirmed** |
+| **QA-02** | | | | | | **Open** |
+
+---
+## Lịch sử cập nhật tài liệu
+*Sau mỗi lần nhận phản hồi, BA cập nhật bảng trên và ghi nhận lịch sử tại đây:*
+- **Ngày [dd/mm/yyyy]:** Nhận phản hồi lần 1 từ khách hàng cho câu hỏi QA-01. Cập nhật trạng thái sang **Confirmed** và chỉnh sửa tài liệu Phân tích bản đầu tương ứng.

package/custom/skills/ba-skills/skill-ba-qa-v1.md

@@ -0,0 +1,35 @@
+# Skill: Xử lý và Thiết kế Q&A (Q&A Specification) - Phiên bản v1
+
+## 1. Mục đích (Purpose)
+Kỹ năng này giúp BA thiết kế các câu hỏi rõ ràng, khách quan và chuyên nghiệp để gửi tới khách hàng/stakeholders nhằm làm rõ các khoảng trống nghiệp vụ (Gaps). Đồng thời, hướng dẫn cách tiếp nhận câu trả lời để cập nhật tài liệu phân tích một cách nhất quán, tránh hiểu sai hoặc tự ý giả định thông tin.
+
+## 2. Kiến thức cần có (Prerequisite Knowledge)
+- **Kỹ năng giao tiếp bằng văn bản (Written Communication):** Sử dụng câu từ ngắn gọn, lịch sự, đi thẳng vào vấn đề.
+- **Kỹ thuật đặt câu hỏi mở và đóng:**
+    - Tránh câu hỏi mập mờ (ví dụ: "Hệ thống có cần khóa tài khoản không?").
+    - Nên đưa ra các tùy chọn rõ ràng (ví dụ: "Khi nhập sai mật khẩu liên tiếp, hệ thống sẽ xử lý thế nào? Tùy chọn A: Khóa tài khoản sau 5 lần sai trong 30 phút. Tùy chọn B: Chỉ hiển thị thông báo lỗi mà không khóa tài khoản. Tùy chọn C: Ý kiến khác...").
+- **Tư duy kiểm thử (Testing Mindset):** Đứng dưới góc nhìn của Tester để hỏi về các biên dữ liệu, các trường hợp lỗi mạng, mất kết nối cơ sở dữ liệu, hoặc dữ liệu không hợp lệ.
+
+## 3. Quy trình thực hiện (Step-by-step Process)
+- **Bước 1: Chuyển đổi Gap thành câu hỏi Q&A:**
+  Từ danh sách khoảng trống phát hiện ở bước Phân tích ban đầu, chuyển mỗi dòng thành một câu hỏi Q&A cụ thể.
+- **Bước 2: Chuẩn hóa câu hỏi theo mẫu `@skill-ba-qa-template-v1.md`:**
+  - Xác định phân vùng nghiệp vụ (Module/Screen).
+  - Trích dẫn yêu cầu hiện tại (Current Status/Requirement).
+  - Nêu rõ vấn đề mơ hồ.
+  - Đưa ra các giải pháp đề xuất (Options) cùng giả định của BA.
+- **Bước 3: Nhận phản hồi và Cập nhật (Process Responses):**
+  - Khi nhận được câu trả lời từ khách hàng: Đọc kỹ để đảm bảo câu trả lời đã giải quyết triệt để câu hỏi. Nếu câu trả lời vẫn chưa rõ ràng, tiếp tục duy trì trạng thái "Open" và hỏi lại ở version tiếp theo.
+  - Nếu đã rõ ràng: Đánh dấu "Resolved" và cập nhật thông tin đó trực tiếp vào tài liệu phân tích hiện tại (`Kết quả phân tích(n).md`).
+  - Ghi nhận lịch sử thay đổi để Dev/Test nắm được lý do thay đổi logic.
+
+## 4. Checklist kiểm tra (Checklist for Verification)
+- [ ] Mỗi câu hỏi có chỉ rõ phần màn hình/tính năng liên quan không?
+- [ ] Câu hỏi có sử dụng từ ngữ trung lập, không mang tính áp đặt ý kiến chủ quan của BA không?
+- [ ] Có đưa ra các phương án gợi ý (Option A, Option B...) cho các vấn đề phức tạp để khách hàng dễ lựa chọn không?
+- [ ] Các thuật ngữ viết tắt trong câu hỏi có được giải thích rõ không?
+- [ ] Đã cập nhật đúng và đầy đủ tất cả câu trả lời của khách hàng vào tài liệu phân tích chưa? (Không bỏ sót bất kỳ điểm chốt nào).
+
+## 5. Output mong đợi (Expected Output)
+- File danh sách câu hỏi Q&A định dạng markdown, cấu trúc thống nhất dựa theo `@skill-ba-qa-template-v1.md`, đặt tên theo chuẩn: `Tên chức năng_Q&A(m).md` trong thư mục `TÀI LIỆU/output/QA/`.
+- Tài liệu phân tích được cập nhật tương ứng với phiên bản mới tăng dần `(n+1)`.

package/custom/skills/ba-skills/skill-ba-template-phan-tich-ban-dau-v1.md

@@ -0,0 +1,30 @@
+# Skill: Template Phân Tích Ban Đầu - Phiên bản v1
+
+Mẫu tài liệu này được sử dụng để trình bày kết quả phân tích yêu cầu ban đầu sau khi bóc tách từ tài liệu thô.
+
+---
+
+# Tài liệu Phân Tích Yêu Cầu Ban Đầu: [Tên Chức Năng]
+
+## 1. Mục tiêu chức năng
+*Mô tả ngắn gọn chức năng này dùng để làm gì? Giải quyết nhu cầu gì của doanh nghiệp hoặc người dùng?*
+
+## 2. Các tác nhân chính (Actors)
+*Liệt kê danh sách các tác nhân (User, Admin, Manager...) sẽ tương tác trực tiếp hoặc gián tiếp với chức năng.*
+
+## 3. Yêu cầu chức năng chi tiết (Functional Requirements)
+*Bóc tách chi tiết các tính năng nhỏ, các nút bấm, các hành động mà hệ thống phải xử lý.*
+- **Giao diện/Trường thông tin:** Liệt kê các trường dữ liệu cần hiển thị hoặc nhập liệu.
+- **Quy tắc nhập liệu sơ bộ:** Định dạng, bắt buộc hay không (Required/Optional).
+
+## 4. Yêu cầu phi chức năng (Non-Functional Requirements)
+*Các yêu cầu về bảo mật, hiệu suất, khả năng tương thích, hoặc giao diện UX/UI đặc thù.*
+
+## 5. Bảng Phân Tích Khoảng Trống & Giả Định (Gap & Assumption Analysis)
+
+| # | Tính năng/Luồng nghiệp vụ | Hiện trạng mô tả thô | Khoảng trống (Gap) / Sự mơ hồ phát hiện | Giả định của BA (Assumption) | Đề xuất giải pháp / Q&A ID tương ứng |
+| :-: | :--- | :--- | :--- | :--- | :--- |
+| 1 | *Ví dụ: Nhập Password* | *Mật khẩu được che giấu* | *Có nút show/hide mật khẩu hay không? Đăng nhập sai bao nhiêu lần thì khóa?* | *Mặc định không hiển thị nút show/hide. Cho phép nhập sai tối đa 5 lần.* | *Xem Q&A_01* |
+| 2 | | | | | |
+
+*Lưu ý: Bảng này là cơ sở quan trọng nhất để tạo ra danh sách câu hỏi Q&A chuẩn xác cho khách hàng.*

package/custom/skills/ba-skills/skill-ba-template-uc-v1.md

@@ -0,0 +1,83 @@
+# Skill: Template Đặc tả Use Case (Use Case Spec) - Phiên bản v1
+
+Cấu trúc chuẩn của một tài liệu đặc tả Use Case hoàn chỉnh dùng để chuyển giao cho Dev/Test.
+
+---
+
+# Tài liệu Đặc Tả Use Case: Chức năng [Tên Chức Năng]
+
+## 1. Thông tin chung (General Information)
+
+| Thuộc tính | Mô tả chi tiết |
+| :--- | :--- |
+| **Tên chức năng (Function Name)** | [Tên chức năng chính xác] |
+| **Mô tả (Description)** | [Tóm tắt mục đích và giá trị nghiệp vụ của chức năng] |
+| **Tác nhân (Actors)** | [Danh sách các tác nhân sử dụng hoặc bị tác động] |
+| **Tác nhân kích hoạt (Trigger)** | [Sự kiện kích hoạt luồng xử lý này] |
+| **Điều kiện tiên quyết (Pre-Conditions)** | [Các điều kiện hệ thống hoặc trạng thái dữ liệu bắt buộc phải có trước khi thực hiện] |
+| **Điều kiện sau xử lý (Post-Conditions)** | [Trạng thái của hệ thống và dữ liệu sau khi kết thúc thành công] |
+
+### Luồng xử lý chính (Main Flow)
+
+| Bước | Tác nhân (Actor Action) | Hệ thống (System Response) |
+| :-: | :--- | :--- |
+| 1 | Người dùng kích hoạt sự kiện... | Hệ thống hiển thị giao diện... |
+| 2 | Người dùng nhập các thông tin... | |
+| 3 | Người dùng nhấn nút... | Hệ thống kiểm tra và thực hiện... |
+| 4 | | Hệ thống thông báo thành công và chuyển hướng... |
+
+### Các luồng thay thế / ngoại lệ (Alternative / Exception Flows)
+
+- **Alternative Flow A: [Tên luồng thay thế]**
+  - Thực hiện từ bước [X] của Luồng chính:
+  - Các bước xử lý: ...
+- **Exception Flow B: [Tên luồng lỗi]**
+  - Thực hiện khi xảy ra lỗi: ...
+  - Các bước xử lý: ...
+
+---
+
+## 2. Mô tả màn hình (Screen Description)
+*Nhúng code HTML của màn hình prototype hoặc ảnh chụp mockup tại đây:*
+
+```html
+<!-- Dán code HTML/CSS prototype ở đây -->
+```
+
+---
+
+## 3. Mô tả thành phần giao diện (UI Components Description)
+
+| # | Tên Component | Loại Component | Cho phép sửa | Bắt buộc | Giá trị mặc định | Quy tắc định dạng & Giới hạn dữ liệu | Mô tả hành vi & tương tác |
+| :-: | :--- | :--- | :-: | :-: | :--- | :--- | :--- |
+| 1 | `ログインID` | Textbox | Yes | Yes | None | Độ dài: 3-20 ký tự. Chỉ chữ và số. Không chứa khoảng trắng. | Ô nhập tên tài khoản của người dùng. |
+| 2 | `ログイン` | Button | N/A | N/A | N/A | N/A | Nhấn để gửi thông tin đăng nhập lên hệ thống. |
+| 3 | | | | | | | |
+
+---
+
+## 4. Sơ đồ luồng hoạt động (Activity Flow Diagram)
+*Sử dụng biểu đồ Mermaid để trực quan hóa quy trình xử lý.*
+
+```mermaid
+graph TD
+    %% Viết mã nguồn Mermaid tại đây
+```
+
+---
+
+## 5. Quy tắc nghiệp vụ (Business Rules)
+
+### BR1: Quy tắc kiểm tra dữ liệu đầu vào (Validation Rules)
+*Định nghĩa các lỗi khi người dùng nhập dữ liệu sai hoặc để trống.*
+- **[BR1.1] Trống dữ liệu bắt buộc:** Nếu bất kỳ trường bắt buộc nào bị trống khi nhấn nút thực thi:
+  - Hệ thống dừng xử lý.
+  - Hiển thị lỗi tương ứng: `[Tên thông báo lỗi]` dưới ô nhập liệu bị trống.
+- **[BR1.2] Định dạng dữ liệu không hợp lệ:** ...
+
+### BR2: Quy tắc lưu trữ dữ liệu (Saving Rules)
+*Định nghĩa cách dữ liệu được ghi nhận vào cơ sở dữ liệu.*
+- **[BR2.1]** Hệ thống ghi nhận thời gian đăng nhập vào bảng `user_logs` với các trường: `user_id`, `login_time`, `status`.
+
+### BR3: Quy tắc phân quyền & Bảo mật (Authorization & Security Rules)
+- **[BR3.1]** Sau 5 lần nhập sai mật khẩu liên tiếp, tài khoản tự động bị khóa trong 30 phút.

package/custom/skills/ba-skills/skill-ba-ve-luong-mermaid-v1.md

@@ -0,0 +1,35 @@
+# Skill: Vẽ luồng hoạt động bằng Mermaid (Mermaid Charting) - Phiên bản v1
+
+## 1. Mục đích (Purpose)
+Kỹ năng này giúp BA chuyển đổi các đặc tả luồng nghiệp vụ văn bản (Main flow, Alternative flows, Exception flows) thành một sơ đồ hoạt động trực quan (Activity Diagram) sử dụng mã nguồn Mermaid. Sơ đồ này giúp lập trình viên nắm bắt luồng đi tổng thể của hệ thống một cách tức thì và giúp kiểm thử viên xác minh các nhánh rẽ của kịch bản.
+
+## 2. Kiến thức cần có (Prerequisite Knowledge)
+- **Cấu trúc biểu đồ Flowchart trong Mermaid:**
+  - Khai báo hướng biểu đồ: Dùng `graph TD` (Top-Down - từ trên xuống) hoặc `graph LR` (Left-to-Right - từ trái sang phải). Đối với quy trình nghiệp vụ phần mềm, khuyến nghị dùng `graph TD`.
+  - **Ký pháp hình khối chuẩn:**
+    - Khởi đầu/Kết thúc (Start/End): Dùng hình elip/bo góc `([Bắt đầu / Trang chủ])`.
+    - Hành động/Xử lý (Process/Action): Dùng hình chữ nhật `[Hành động của Actor hoặc xử lý của System]`.
+    - Điểm quyết định/Rẽ nhánh (Decision): Dùng hình thoi `{Điều kiện kiểm tra}`.
+    - Hiển thị thông tin/Thông báo lỗi: Dùng hình chữ nhật bo góc hoặc hình bình hành.
+  - **Liên kết nhánh (Arrows & Labels):** Sử dụng `-->|Nhãn nhánh rẽ|` để nối các khối và đặt tên cho các đường đi (ví dụ: `-->|Hợp lệ|`, `-->|Không hợp lệ|`).
+
+## 3. Quy trình thực hiện (Step-by-step Process)
+- **Bước 1: Xác định điểm bắt đầu và kết thúc:**
+  Điểm bắt đầu thường là trigger của Use Case (ví dụ: Người dùng nhấn nút mở trang, hoặc vào link URL). Điểm kết thúc là các Post-conditions (thành công hoặc dừng luồng lỗi).
+- **Bước 2: Vẽ luồng chính trước (Happy Path):**
+  Nối các bước xử lý bình thường từ đầu đến cuối mà không có lỗi xảy ra. Sử dụng các mũi tên thẳng xuống.
+- **Bước 3: Thêm các điểm rẽ nhánh (Alternative/Exception branches):**
+  Tại các bước hệ thống kiểm tra thông tin, chèn các khối hình thoi `{Điều kiện}`. Vẽ nhánh thành công tiếp tục đi xuống luồng chính, và các nhánh lỗi quay ngược lại form nhập liệu hoặc đi tới kết thúc lỗi.
+- **Bước 4: Tinh chỉnh cú pháp Mermaid để tránh lỗi render:**
+  - Tránh sử dụng các ký tự đặc biệt như ngoặc đơn `()`, ngoặc vuông `[]`, dấu nháy kép bên trong nhãn của nút bấm trừ khi nhãn được bọc hoàn toàn trong dấu nháy kép. Ví dụ đúng: `A["Hiển thị thông báo (Lỗi 404)"]`.
+  - Đảm bảo mỗi khối có ID định danh độc nhất (ví dụ: `A`, `B`, `C`, `Step1`, `Check1`).
+
+## 4. Checklist kiểm tra (Checklist for Verification)
+- [ ] Biểu đồ có bắt đầu bằng `graph TD` không?
+- [ ] Tất cả các điểm quyết định (các câu lệnh IF/THEN hoặc kiểm tra hợp lệ) có sử dụng hình thoi `{}` không?
+- [ ] Các nhánh đi ra khỏi hình thoi có được gán nhãn rõ ràng (ví dụ: Đúng/Sai, Có/Không) không?
+- [ ] Có nhánh lỗi nào bị "treo" (không dẫn đi đâu) không? Mọi nhánh phải dẫn về một bước thao tác tiếp theo hoặc kết thúc luồng.
+- [ ] Nhãn của các khối chứa ký tự đặc biệt đã được bọc trong dấu nháy kép `""` chưa để tránh lỗi biên dịch Mermaid?
+
+## 5. Output mong đợi (Expected Output)
+- Một đoạn mã nguồn Mermaid hợp lệ, nằm trong khối ```mermaid và được nhúng trực tiếp vào Mục 4 của tài liệu Đặc tả Use Case.

package/custom/skills/ba-skills/skill-ba-viet-spec-uc-v1.md

@@ -0,0 +1,38 @@
+# Skill: Viết Đặc tả Use Case (Use Case Specification) - Phiên bản v1
+
+## 1. Mục đích (Purpose)
+Kỹ năng này giúp BA chuyển hóa toàn bộ các thông tin yêu cầu nghiệp vụ đã được thống nhất sau quá trình Q&A thành một tài liệu Đặc tả Use Case (Use Case Spec) hoàn chỉnh. Tài liệu này là "nguồn sự thật duy nhất" (Single Source of Truth) giúp đội ngũ Dev lập trình chính xác và đội ngũ Test thiết kế toàn bộ kịch bản kiểm thử (Test Cases/Scripts).
+
+## 2. Kiến thức cần có (Prerequisite Knowledge)
+- **Cấu trúc Use Case chuẩn:** Hiểu rõ các thành phần của một Use Case Spec bao gồm: Thông tin chung, Mô tả màn hình, Mô tả thành phần UI, Luồng hoạt động (Activity Flow) và Quy tắc nghiệp vụ (Business Rules).
+- **Cách mô tả Luồng xử lý (Flow):** 
+  - Phân biệt hành động của Tác nhân (Actor Action) và phản hồi của Hệ thống (System Response).
+  - Trình bày mạch lạc theo các bước đánh số thứ tự (1, 2, 3...).
+- **Tính liên kết logic:** Đảm bảo mã lỗi, thông báo lỗi trong Business Rules phải khớp với các mô tả thành phần UI và vị trí hiển thị lỗi trên Prototype.
+
+## 3. Quy trình thực hiện (Step-by-step Process)
+- **Bước 1: Điền thông tin chung (General Information):**
+  Xác định chính xác Function Name, Description, Actors, Trigger, Pre-Conditions, Main Flow tóm tắt, và Post-Conditions.
+- **Bước 2: Tích hợp thiết kế màn hình:**
+  Nhúng mã nguồn HTML/CSS (hoặc đường dẫn liên kết) của màn hình thiết kế tương ứng vào mục Screen Description.
+- **Bước 3: Mô tả các thành phần UI (UI Components):**
+  Lập bảng chi tiết tất cả các control trên giao diện (các input fields, buttons, links, labels). Đối với mỗi thành phần, cần làm rõ:
+    - Kiểu dữ liệu nhập vào (Text, Number, Date...).
+    - Độ dài giới hạn (Min/Max length).
+    - Tính bắt buộc (Mandatory: Yes/No).
+    - Giá trị mặc định (Default Value).
+    - Mô tả hành vi (Description).
+- **Bước 4: Thiết kế sơ đồ Mermaid (Activity Flow):**
+  Áp dụng kỹ năng `@skill-ba-ve-luong-mermaid-v1.md` để vẽ và nhúng biểu đồ Mermaid.
+- **Bước 5: Đặc tả Business Rules (Quy tắc nghiệp vụ):**
+  Áp dụng kỹ năng `@skill-ba-xay-dung-business-rules-v1.md` để viết chi tiết các điều kiện kiểm tra, validation logic và câu thông báo lỗi đi kèm.
+
+## 4. Checklist kiểm tra (Checklist for Verification)
+- [ ] Luồng đi (Flow) có mô tả rõ ràng sự tương tác qua lại giữa Actor và System chưa?
+- [ ] Bảng mô tả UI Components có bị bỏ sót bất kỳ thành phần nào trên prototype HTML không?
+- [ ] Các Business Rules (BR) đã được đánh mã số rõ ràng (BR1, BR2, BR3...) để dễ tham chiếu chưa?
+- [ ] Mọi trường hợp báo lỗi đều có câu thông báo lỗi (Error message) đi kèm chi tiết chưa?
+- [ ] Tài liệu có sử dụng định dạng markdown chuẩn và cấu trúc thống nhất theo mẫu `@skill-ba-template-uc-v1.md` chưa?
+
+## 5. Output mong đợi (Expected Output)
+- Một tài liệu đặc tả Use Case hoàn chỉnh định dạng markdown, đặt tên theo chuẩn: `Tên chức năng_UC.md` trong thư mục `TÀI LIỆU/output/UC/`.

package/custom/skills/ba-skills/skill-ba-xay-dung-business-rules-v1.md

@@ -0,0 +1,39 @@
+# Skill: Phân tích và Xây dựng Business Rules (Quy tắc nghiệp vụ) - Phiên bản v1
+
+## 1. Mục đích (Purpose)
+Kỹ năng này giúp BA bóc tách, chuẩn hóa và đặc tả các quy tắc nghiệp vụ (Business Rules - BR) của hệ thống một cách chặt chẽ nhất. Các quy tắc nghiệp vụ được định nghĩa chi tiết tại đây sẽ là căn cứ trực tiếp để lập trình viên viết code logic (backend/frontend) và kiểm thử viên viết các kịch bản kiểm thử (Test Cases), đảm bảo bao phủ toàn bộ các trường hợp biên và ngoại lệ.
+
+## 2. Kiến thức cần có (Prerequisite Knowledge)
+- **Các loại Business Rules phổ biến:**
+  - *Validation Rules (Quy tắc kiểm tra dữ liệu):* Bao gồm kiểm tra rỗng (Required), kiểm tra định dạng (Format - Regex, Email, số điện thoại), kiểm tra độ dài/giới hạn (Length/Range), và kiểm tra ràng buộc chéo giữa các trường (Dependency validation - ví dụ: Ngày kết thúc phải sau Ngày bắt đầu).
+  - *Processing/Calculation Rules (Quy tắc xử lý và tính toán):* Các công thức toán học, thuật toán phân chia logic (ví dụ: công thức tính thuế, logic tính điểm thưởng).
+  - *Database/Saving Rules (Quy tắc lưu trữ và ghi nhận dữ liệu):* Các hành động xảy ra trong DB sau khi nghiệp vụ hoàn thành (ví dụ: lưu vào bảng log hệ thống, cập nhật trạng thái đơn hàng từ Draft sang Pending).
+  - *Authorization & Security Rules (Quy tắc phân quyền và bảo mật):* Ai được phép thao tác? Khi nào tài khoản bị khóa?
+- **Cách phân tích Giá trị Biên (Boundary Value Analysis) & Phân vùng tương đương (Equivalence Partitioning):** Tư duy chia dữ liệu để phát hiện điểm thiếu logic (ví dụ: Quy định nhập từ 3-20 ký tự thì phải xác định rõ các biên 2, 3, 20, 21 ký tự sẽ xử lý thế nào).
+
+## 3. Quy trình thực hiện (Step-by-step Process)
+- **Bước 1: Xác định các điểm cần áp dụng Quy tắc nghiệp vụ:**
+  Duyệt qua danh sách các trường thông tin (Inputs) và các nút thao tác chính (Actions) trên giao diện.
+- **Bước 2: Phân loại và phân nhóm các Business Rules:**
+  Đặt mã định danh duy nhất cho từng quy tắc dưới định dạng: `[BR<Nhóm>.<Số thứ tự>]`
+  - Nhóm 1: Validation (ví dụ: `[BR1.1]`, `[BR1.2]`)
+  - Nhóm 2: Processing & Saving (ví dụ: `[BR2.1]`)
+  - Nhóm 3: Authorization & Security (ví dụ: `[BR3.1]`)
+- **Bước 3: Chi tiết hóa từng quy tắc nghiệp vụ:**
+  Mỗi quy tắc cần ghi rõ:
+    - **Điều kiện kích hoạt (Trigger/Condition):** Khi người dùng làm gì hoặc khi dữ liệu đạt trạng thái nào?
+    - **Logic kiểm tra (Logic/Calculation):** Hệ thống so sánh, tính toán như thế nào?
+    - **Kết quả trả về khi kiểm tra thất bại (Failure Action):** Hệ thống hiển thị câu thông báo lỗi (Error message) cụ thể là gì? Ở vị trí nào? Màu sắc ra sao?
+    - **Kết quả trả về khi kiểm tra thành công (Success Action):** Hệ thống lưu trữ vào bảng nào? Chuyển hướng đi đâu?
+- **Bước 4: Rà soát tính đầy đủ cùng Tester:**
+  Đảm bảo mọi lỗi phát sinh đều có thông báo lỗi tương ứng và không bị chồng chéo logic.
+
+## 4. Checklist kiểm tra (Checklist for Verification)
+- [ ] Tất cả các trường dữ liệu bắt buộc (Mandatory fields) đã có quy tắc xử lý khi để trống chưa?
+- [ ] Đã chỉ định chính xác vị trí hiển thị và nội dung chi tiết của các thông báo lỗi chưa? (Ví dụ: Hiển thị inline ngay dưới ô nhập liệu hay hiển thị popup cảnh báo?)
+- [ ] Đã làm rõ logic đối với các ký tự đặc biệt, khoảng trắng (space) và chữ hoa/chữ thường chưa?
+- [ ] Quy tắc lưu trữ đã chỉ ra các bảng cơ sở dữ liệu bị tác động trực tiếp chưa?
+- [ ] Phân quyền thao tác cho từng tác nhân (Actor) đã được mô tả rõ chưa?
+
+## 5. Output mong đợi (Expected Output)
+- Mục 5 (Business rules) của tài liệu đặc tả Use Case chứa danh sách các quy tắc nghiệp vụ được cấu trúc hóa rõ ràng, ký hiệu hóa khoa học theo chuẩn `[BR...]`, có kèm theo nội dung text thông báo lỗi chi tiết.

package/custom/skills/execute-flow/SKILL.md

@@ -71,6 +71,26 @@ Chờ tester trả lời rồi mới tiếp tục.
 
 Nếu nhiều màn hình khác repo → hỏi từng màn hình một.
 
+### Bước 1b: Đọc Source Code (nếu workspace có source repos)
+
+Chạy ngay sau khi xác định được `Repo`, trước khi extract TCs.
+
+Nếu workspace mở dạng parent folder chứa cả `ak docs` lẫn source code repos:
+
+1. **Nếu GitNexus MCP có sẵn** (`.mcp.json` có entry `gitnexus`):
+   - `gitnexus: query("tên màn hình {ScreenID}")` → tìm component, page, form liên quan
+   - `gitnexus: context("ComponentName")` → xem toàn bộ component/template
+2. **Nếu không có GitNexus**: đọc trực tiếp trong `{repo}/`:
+   - Component / Page / View của màn hình — tìm `data-testid`, `id`, `name` của các element
+   - Form / Input structure — hiểu hierarchy của DOM
+   - Route / path mapping — xác nhận URL path của màn hình
+3. Lưu lại thông tin để Gate 2 (Script Sync) sử dụng:
+   - Danh sách `data-testid` / `id` của các element tương tác
+   - Cấu trúc form (fieldset, section, tab nếu có)
+   - URL path chính xác của màn hình
+
+> Mục đích: Giúp `script-sync` (Gate 2) viết Playwright scripts với selectors chính xác hơn, giảm phụ thuộc vào browser snapshot khi app chưa chạy.
+
 ### Bước 2: Extract TCs từ Section 3
 
 Đọc tất cả rows trong các bảng Section 3.x, extract:
@@ -139,18 +159,16 @@ Nhận về: danh sách kết quả per TC.
 
 ### Hiển thị kết quả
 
-```
 ⏸️ GATE 2: SCRIPT SYNC COMPLETE
 
 Gen mới: {N} | Updated: {N} | Skipped: {N}
 Manual (Untest): {N} TCs
 Blocked: {N} TCs — xem lý do bên trên
 
-→ Review: ak-test/{repo}/scripts/{screenId}/{ScreenID}.spec.ts
+→ Review: [ak-test/{repo}/scripts/{screenId}/{ScreenID}.spec.ts](ak-test/{repo}/scripts/{screenId}/{ScreenID}.spec.ts)
 → Type APPROVED to run tests
 → Type SKIP: {TC_ID} để đánh dấu Pending và tiếp tục
 → Or provide feedback to fix scripts
-```
 
 Dừng. Chờ APPROVED.
 
@@ -287,26 +305,7 @@ Với mỗi TC failed, tạo `ak-test/{repo}/results/{screenId}/run-{N}/bugs/BUG
 
 BUG số: đếm file trong `bugs/` folder, +1. Format: `001`, `002`,...
 
-### Bước 6: Cập nhật TC file gốc
-
-Ghi kết quả vào các cột R1/R2 trong TC file:
-
-- R1 = lần chạy đầu tiên (run-1). Nếu R1 đã có giá trị → ghi vào R2.
-- R1 Tester = `AI-R1`, R2 Tester = `AI-R2`
-
-```markdown
-| AD10_001 | ... | ✅ Pass | {YYYY-MM-DD} | AI-R1 |   |   |   |
-| AD10_005 | ... | ❌ Fail | {YYYY-MM-DD} | AI-R1 |   |   |   |
-| AD10_023 | ... | ⏭️ Untest | - | - |   |   |   |
-```
-
-Cập nhật Section 2 — Test Execution Summary table:
-
-```markdown
-| Round {N} | {passed} | {failed} | {untest} | {pending} | {total} | {passed/total*100}% |
-```
-
-### Bước 7: Hiển thị Gate 3
+### Bước 6: Hiển thị Gate 3
 
 ```
 ⏸️ GATE 3: EXECUTION COMPLETE
@@ -341,8 +340,7 @@ Khi tester gõ `RETEST: AD10_005, AD10_008`:
    ```
 3. Xác định run number mới (run-{N+1})
 4. Tổ chức evidence vào `run-{N+1}/` (không xóa run cũ)
-5. Cập nhật R2 columns trong TC file
-6. Cập nhật bug status:
+5. Cập nhật bug status:
    - TC pass sau retest → ghi `RESOLVED` vào bug file: `**Status:** ✅ Resolved`
    - TC vẫn fail → ghi `**Retest {N}:** Still OPEN` vào bug file
 
@@ -362,11 +360,7 @@ Chỉ chạy sau Gate 3 APPROVED.
 
 Đọc `bugs/BUG-*.md` trong run folder: phân loại severity + status (Open/Resolved).
 
-### Bước 2: Cập nhật Section 2 trong TC file
-
-Cập nhật bảng Test Execution Summary với số liệu từ R1 và R2.
-
-### Bước 3: Sinh testreport.md
+### Bước 2: Sinh testreport.md
 
 Tạo `ak-test/{repo}/results/{screenId}/run-{N}/testreport.md` theo template chuẩn:
 
@@ -402,7 +396,7 @@ Tạo `ak-test/{repo}/results/{screenId}/run-{N}/testreport.md` theo template ch
 - Còn Critical hoặc High Open → No-go
 - Chỉ còn Medium/Low Open → Conditional go
 
-### Bước 4: Bug logging flow
+### Bước 3: Bug logging flow
 
 Hỏi từng bug theo thứ tự severity (Critical → High → Medium → Low):
 
@@ -423,9 +417,8 @@ Nếu tester gõ `Y`:
 
 Nếu `n` hoặc `SKIP-BUG`: ghi `Not logged` trong testreport.md Bug Summary.
 
-### Bước 5: Hiển thị Gate 4
+### Bước 4: Hiển thị Gate 4
 
-```
 ⏸️ GATE 4: REPORT READY
 
 Overall: {Pass / Fail / Conditional}
@@ -433,10 +426,9 @@ Passed: {N}/{total} | % hoàn thành: {N}%
 Bugs logged to Jira: {N}/{total bugs}
 Recommendation: {Go / No-go / Conditional go}
 
-→ Review: ak-test/{repo}/results/{screenId}/run-{N}/testreport.md
+→ Review: [ak-test/{repo}/results/{screenId}/run-{N}/testreport.md](ak-test/{repo}/results/{screenId}/run-{N}/testreport.md)
 → Type APPROVED to sign off
 → Type NO-GO: {reason} to reject release
-```
 
 Dừng. Chờ APPROVED hoặc NO-GO.
 
@@ -473,7 +465,6 @@ SKIP-BUG: BUG-{NNN}                   # bỏ qua không log bug này
 
 - ✅ Dừng ở mỗi gate, chờ APPROVED trước khi proceed
 - ✅ `run-{N}` không bao giờ bị xóa hay overwrite — luôn tạo folder mới
-- ✅ R1/R2 trong TC file gốc được cập nhật sau mỗi lần chạy
 - ✅ Hỏi từng bug một — không auto-log toàn bộ
 - ❌ Không lấy expected result từ PR/code — chỉ từ TC file
 - ❌ Không skip gate kể cả khi "chỉ có 1 TC"

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

@@ -0,0 +1,119 @@
+---
+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 — Prepare Inline Review & Output Document
+
+When generating the output for a gate (e.g. `requirement.md` or `plan.md`), follow these steps:
+
+### Step 1: Ensure review directories and comments database exist
+
+1. Always create the directory `.aiflow/review/` if it doesn't exist.
+2. Check if `.aiflow/review/comments-[ticket-id].json` exists (where `[ticket-id]` comes from `.aiflow/context/current.json` → `ticketId` field).
+3. If the JSON file does not exist, initialize it by writing an empty array `[]` (or `{ "comments": [] }`) to it. This ensures that the CLI verification commands do not fail due to a missing file when there are no comments.
+
+### Step 2: Write the gate output file
+Write the gate output file (e.g. `plan/[ticket-id]/requirement.md`, `plan/[ticket-id]/plan.md`, or `docs/ak-[project]/...`) as specified by the gate instructions.
+
+### Step 3: Display gate pause message
+
+Instruct the user to review the generated document. Tell them that they can hover over any line and add inline comments in VS Code using the native commenting UI, or edit the file to add standard HTML comments `<!-- comment -->` if they are not using the VS Code extension.
+
+Display in chat:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+⏸️  GATE [N] PAUSED — REVIEW REQUIRED
+
+📋 Open in VS Code: [path/to/generated/file.md](path/to/generated/file.md)
+
+  • Review the generated document content directly.
+  • Hover over any line to add specific comments (inline review).
+  • Mark comments as "Resolved" in VS Code once addressed.
+  • Type APPROVED when done.
+
+⚠️  APPROVED will not be accepted until all inline comments are resolved.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+---
+
+## Mode 2: VERIFY — Check Comments and Checklist on APPROVED
+
+When the developer types `APPROVED`, run this check:
+
+### Step 1: Run CLI check
+
+```bash
+ak review check --gate [N] --ticket [ticket-id]
+```
+
+### Step 2: Interpret result
+
+**Exit code 0 — all checked & resolved:**
+- Gate proceeds normally
+- Run telemetry: `ak gate [N] approved --ticket [ticket-id]`
+- Continue to next gate
+
+**Exit code 1 — file missing:**
+- AI response: "The review session files weren't found. Let me prepare them."
+- Re-run Mode 1 (initialize `comments-[ticket-id].json` and output file) and display pause message.
+
+**Exit code 1 — items with comments (need revision):**
+If the CLI reports unresolved comments, the AI must:
+1. Read the unresolved comments returned by the CLI (which include file path, line number, and comment text).
+2. Read the source file at those line numbers to understand the context.
+3. Update the specific sections of the document to address the comments.
+4. Tell the user what was updated, ask them to mark the comment thread as resolved in VS Code, and type `APPROVED`.
+
+---
+
+## Mandatory Rules
+
+- ❌ **NEVER** accept `APPROVED` without first running `ak review check`
+- ✅ **ALWAYS** ensure `.aiflow/review/` directory exists (use `mkdir -p`)
+- ✅ **ALWAYS** initialize `.aiflow/review/comments-[ticket-id].json` with `[]` if not present when starting a gate pause.
+- ✅ **ALWAYS** use the ticket ID from `.aiflow/context/current.json` in the file name
+- ✅ **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
 ```