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

package/README.md

@@ -70,6 +70,82 @@ PM writes ticket on Backlog/Jira
 
 ---
 
+## Execute Test Flow
+
+```
+aiflow execute PROJ-44  (or ./testcases.md  or  aiflow execute)
+        │
+        ▼
+⛩️ GATE 1 — Pre-flight & Work Plan           [AI + QA]
+  Parse TC file → verify ak-test/{repo}/ exists
+  Check BASE_URL env var + playwright.config.ts
+  Create execution work plan
+        │ Ready
+        ▼
+⛩️ GATE 2 — Script Sync                      [AI]
+  Hash-based TC↔script sync
+  Generate new / update changed / skip unchanged
+  Uses Playwright MCP for selectors — never fabricates
+        │ Scripts synced
+        ▼
+⛩️ GATE 3 — Execute & Evidence               [AI]
+  Run: npx playwright test
+  Organize evidence per run-{N}/: screenshots, trace.zip, result.md
+  Auto-draft bug files for failed TCs
+  Support RETEST: [TC_ID] loop
+        │ Tests done
+        ▼
+⛩️ GATE 4 — Report & Bug Logging             [AI + QA]
+  Generate testreport.md with Go/No-Go recommendation
+  Log each failed TC to Jira/Backlog — interactive confirm per bug
+        │
+        ▼
+       DONE
+```
+
+---
+
+## Execute Test Flow
+
+Flow độc lập cho QA — không cần chạy lại phân tích (Gates 1–2 của Development Flow).
+
+```
+QA nhận TC file (từ ticket hoặc file)
+        │
+        ▼
+⛩️ GATE 1 — Context & Work Plan              [AI + QA]
+  aiflow execute PROJ-44   →   claude
+  AI kiểm tra: MCP Playwright, ak-test/, BASE_URL, playwright.config.ts
+  AI parse TC file → extract TCs, phân loại Auto / Manual
+  AI xuất work plan + danh sách TCs cần thực thi
+        │ Work Plan ready
+        ▼
+⛩️ GATE 2 — Script Sync                      [AI]
+  Hash-based TC ↔ script sync
+  Gen mới TC chưa có script (Playwright MCP → selector DOM thật)
+  Cập nhật script đã thay đổi, bỏ qua script không đổi
+  Không fabricate selector — luôn lấy từ DOM thật
+        │ Scripts synced
+        ▼
+⛩️ GATE 3 — Execute & Evidence               [AI]
+  Chạy Playwright, tổ chức evidence theo run-{N}/
+  Cập nhật cột R1/R2 trong TC file
+  Tổng hợp kết quả pass/fail per TC
+        │ Tests done
+        ▼
+⛩️ GATE 4 — Report & Bug Logging             [AI + QA]
+  AI tạo: testreport.md
+  AI hỏi từng bug → QA xác nhận log lên Jira/Backlog
+  QA review → DONE
+        │
+        ▼
+       DONE
+```
+
+> **Entry points:** `aiflow execute PROJ-44` (từ ticket) · `aiflow execute ./testcases/AD10.md` (từ file) · `aiflow execute` (manual — AI hỏi TC file path)
+
+---
+
 ## Installation
 
 ```bash
@@ -454,6 +530,43 @@ Then run `aiflow update` or `aiflow sync-skills` to apply.
 
 > Summary of major changes per version. See full details in [CHANGELOG.md](docs/common/CHANGELOG.md).
 
+### v0.1.3 — 2026-06-18
+- **Execute Test Flow (4-Gate):** New `aiflow execute` command + `execute-flow` skill — Pre-flight → Script Sync → Execute & Evidence → Report & Bug Logging.
+- **`script-sync` skill:** Hash-based TC↔Playwright script sync — gen new, update changed, skip unchanged. Uses MCP browser tools for selectors, never fabricates.
+- **`ak execute` command** (`ak ex` alias): Standalone QA entry point — accepts ticket ID, TC file path, or interactive mode.
+- **▶️ Execute Test** added to `ak use` type selector; `taskType: "execute"` routes AI to execute-flow skill automatically.
+- **Playwright harness scaffold** (`ak scaffold playwright`): Creates full `ak-test/{repo}/` structure with config, fixtures, and page objects.
+- Fixes: `screenId` casing ambiguity, `--reporter` flag overriding config reporters, Gate 1 missing `playwright.config.ts` check.
+
+### v0.1.2 — 2026-06-13
+- **Testing Workflow (4-Gate):** New `taskType: "testing"` — Test Analysis → Test Planning → Test Execution → Test Report. AI auto-routes skill per gate.
+- **`python-ml` framework:** Supports scikit-learn / PyTorch / TensorFlow / MLflow / Wandb. Auto-detected from `requirements.txt` / `pyproject.toml`.
+- **Task type selector in `ak use`:** Interactive list after loading ticket — auto-detects and pre-selects task type.
+- **Critical fix — `update`/`init` not updating CLAUDE.md/GEMINI.md:** Fixed 3 compounding causes (`framework` singular vs. plural, missing `force: true`, per-file confirm dialogs).
+- **Backup before overwrite:** AI instruction files backed up to `.aiflow/bk/YYYY-MM-DD_HH-MM_<filename>` before any overwrite.
+- **`aiflow update` no longer wipes `.claude/`:** Now clears only `.claude/skills/`, preserving `settings.json` and hooks.
+
+### v0.1.1 — 2026-06-08
+- **Ubuntu/Linux clipboard in `ak prompt`:** Auto-detects display server (Wayland/X11) and package manager — offers to install clipboard tool if missing.
+- **`figma-to-component` image detection & export:** Scans node tree for image nodes, exports to `public/assets/figma/`, renders with `<Image>`/`<img>`.
+- **`figma-to-component` MCP pre-check (Step 0):** Verifies MCP connected before running; stops with setup instructions if not.
+- **`figma-to-component` CSS tooling detection:** Branches on Tailwind / CSS Modules / styled-components / vanilla CSS; maps Figma Styles/Variables to existing tokens.
+- **Critical fix — `figma-to-component` source/installed divergence:** Synced both copies to canonical version with correct tool names and 4-tier framework detection.
+
+### v0.1.3 — 2026-06-22
+
+**QA Automation Suite — End-to-end test execution với Playwright MCP**
+
+- New `aiflow execute` command with full 4-gate Execute Flow (pre-flight → script sync → run → report).
+- New skill suite for QA: `execute-flow`, `automation-testing`, `script-sync`, `generate-testcase`, `generate-test-report`, `log-bug`, `test-analysis`, `evidence-aggregation`, `retest-orchestration`, `coverage-check`.
+- Playwright harness template (`custom/harness/playwright/`) — pre-wired `playwright.config.ts`, `BasePage`, fixtures, và auth setup.
+- New `aiflow scaffold` command (`ak sc`) — tự động tạo cấu trúc `ak-test/{repo}/` từ template.
+- Hash-based TC↔script sync: chỉ gen/update script khi TC thay đổi, bỏ qua TC không đổi — không mất thời gian re-gen.
+- Selector lấy từ DOM thật qua Playwright MCP — không fabricate, không đoán.
+- ML framework support: `python-ml` template + 7 ML skills (`frame-ml-problem`, `explore-data`, `design-experiment`, `train-model`, `evaluate-model`, `improve-algorithm`, `deploy-model`).
+- New `pr-impact-analysis` skill — phân tích breaking changes của PR trước khi merge.
+- Deprecated `aiflow` CLI alias — dùng `ak` thay thế (warning hiện khi dùng `aiflow`).
+
 ### v0.1.0 — 2026-05-28
 - Multi-target `ak use` — load multiple tickets/files in a single call (primary + supplementary).
 - Auto link resolution — auto-fetch Backlog/Jira URLs found in the ticket description (capped at 5 links).

package/bin/aiflow.js

@@ -503,6 +503,53 @@ program
         }
     });
 
+// ── review ────────────────────────────────────────────────────
+const reviewCmd = program.command('review').description('Gate review file operations');
+
+reviewCmd
+    .command('check')
+    .description('Check review file state — called by AI before accepting APPROVED')
+    .requiredOption('-g, --gate <n>', 'gate number (string — supports sub-phases like 2a, 2b)')
+    .requiredOption('-t, --ticket <id>', 'ticket ID')
+    .action(async (opts) => {
+        const { checkReviewFile } = require('../scripts/review');
+        const result = await checkReviewFile(opts.gate, opts.ticket);
+
+        if (!result.exists) {
+            console.log(chalk.red(`\n  ✗ Review file not found for gate ${opts.gate}, ticket ${opts.ticket}`));
+            console.log(chalk.gray(`  Expected: .aiflow/review/gate-${opts.gate}-${opts.ticket}.md`));
+            console.log(chalk.yellow('  → Re-generate the review file before accepting APPROVED.\n'));
+            process.exit(1);
+        }
+
+        if (result.passed) {
+            console.log(chalk.green(`\n  ✅ All ${result.total} items checked — gate can proceed\n`));
+            process.exit(0);
+        }
+
+        const pendingCount = result.unchecked.length + result.commented.length;
+        console.log(chalk.red(`\n  ❌ Review incomplete — ${pendingCount} item(s) pending:\n`));
+
+        if (result.commented.length > 0) {
+            console.log(chalk.yellow('  Items with comments (need AI revision):'));
+            result.commented.forEach(({ item, comment }) => {
+                console.log(chalk.yellow(`    • ${item}`));
+                console.log(chalk.gray(`      Comment: "${comment}"`));
+            });
+            if (result.unchecked.length > 0) console.log('');
+        }
+
+        if (result.unchecked.length > 0) {
+            console.log(chalk.red('  Items unchecked (no comment — please check or add a comment):'));
+            result.unchecked.forEach(item => {
+                console.log(chalk.red(`    • ${item}`));
+            });
+        }
+
+        console.log(chalk.gray('\n  → Check all items in the review file, then type APPROVED again.\n'));
+        process.exit(1);
+    });
+
 // ── remove ────────────────────────────────────────────────────
 program
     .command('remove')
@@ -531,7 +578,7 @@ program
     .description('Manually synchronize AI Instruction files with local custom skills')
     .action(async () => {
         const projectDir = process.cwd();
-        const { setupFramework, AI_TOOL_FILES, ensureAiflowGitignored } = require('../scripts/init');
+        const { setupFramework, AI_TOOL_FILES, ensureAiflowGitignored, setupClaudeCommands } = require('../scripts/init');
         const fs = require('fs-extra');
         const path = require('path');
         const chalk = require('chalk');
@@ -551,6 +598,7 @@ program
         for (const fw of frameworks) {
             await setupFramework(projectDir, fw, frameworks.length > 1, selectedTools, { force: true });
         }
+        await setupClaudeCommands(projectDir);
         await ensureAiflowGitignored(projectDir);
         console.log(chalk.green('✨ Sync completed!'));
     });

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:
@@ -146,7 +166,7 @@ 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
@@ -433,7 +453,7 @@ 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
 ```