$npx -y skills add anhtester/codex-testing-kit --skill requirements-analyzerKỹ năng phân tích trang web/module và sinh ra tài liệu Yêu cầu (Requirements Document/User Stories) chuẩn mực.
| 1 | # Kỹ năng Phân tích Yêu cầu (Requirements Analyzer) |
| 2 | |
| 3 | Kỹ năng này hướng dẫn Codex chuyển đổi giao diện UI hoặc cấu trúc DOM/HTML của một trang web thành tài liệu yêu cầu rõ ràng, chi tiết cho QA, Tester và Developer. |
| 4 | |
| 5 | ## 1. Mục tiêu cốt lõi |
| 6 | - Xây dựng tài liệu yêu cầu bám sát thực tế hệ thống đang chạy. |
| 7 | - Đảm bảo tính nhất quán, tính bao quát cho cả Happy Path và Edge Cases (Trường hợp ngoại lệ/báo lỗi). |
| 8 | - Định dạng xuất ra một cách chuyên nghiệp (Sử dụng cấu trúc Artifact). |
| 9 | |
| 10 | ## 2. Quy trình trích xuất thông tin |
| 11 | Khi được yêu cầu tạo Requirements từ một trang web: |
| 12 | 1. **Phân tích Khung giao diện (Layout Analysis):** Xác định các phần Header, Footer, Sidebar, và Nội dung chính (Main Content). |
| 13 | 2. **Thu thập Form & Inputs:** |
| 14 | - Tìm tất cả các trường nhập liệu (`input`, `select`, `textarea`). |
| 15 | - Ghi nhận thuộc tính `type` (text, email, password, number), `required`, `maxlength`, `minlength`, `pattern`. |
| 16 | 3. **Thu thập Các nút tương tác (Buttons/Links/Actions):** |
| 17 | - Xác định chức năng của từng nút (Save, Submit, Cancel, Delete, Edit). |
| 18 | - Các cảnh báo, thông báo (Alerts, Toasts, Validation Messages) xuất hiện khi tương tác lỗi. |
| 19 | 4. **Trích xuất Luồng công việc (Workflows):** |
| 20 | - Sự phụ thuộc giữa các thành phần (VD: Nút Submit chỉ enable khi đã tích chọn Checkbox "Tôi đồng ý"). |
| 21 | |
| 22 | ## 3. Cấu trúc Tài liệu Yêu cầu Đầu ra (Output Format) |
| 23 | Tài liệu cần được format theo Markdown chuyên nghiệp hoặc lưu dưới dạng Artifact (`requirements_spec.md`). |
| 24 | |
| 25 | **Nội dung bắt buộc phải có:** |
| 26 | |
| 27 | ### 3.1. Tổng quan (Overview) |
| 28 | Mô tả tóm tắt tính năng và mục đích của trang web/module. |
| 29 | |
| 30 | ### 3.2. Yêu cầu Chức năng (Functional Requirements) |
| 31 | Chia thành các **User Stories** hoặc **Use Cases**: |
| 32 | - **Tên tính năng** (Ví dụ: Chức năng Đăng nhập) |
| 33 | - **Mô tả:** "Là một người dùng, tôi muốn... để có thể..." |
| 34 | - **Tiêu chí chấp nhận (Acceptance Criteria):** Ghi rõ các điều kiện cần thỏa mãn. |
| 35 | |
| 36 | ### 3.3. Đặc tả Trường Dữ liệu (Field Specifications) |
| 37 | Đây là phần cốt lõi dành cho Automation Tester: |
| 38 | * Dùng bảng Markdown (*Markdown Table*) để liệt kê: |
| 39 | - Tên Trường (Label) |
| 40 | - Loại (Type UI) |
| 41 | - Validation Rules (Bắt buộc / Mặc định / Giới hạn độ dài). |
| 42 | - Ghi chú (Notes). |
| 43 | |
| 44 | ### 3.4. Các luồng xử lý và Báo lỗi (Business Rules & Validations) |
| 45 | Liệt kê chi tiết các Validation Message mong đợi khi người dùng nhập sai dữ liệu. |
| 46 | |
| 47 | ## 4. Bắt buộc (Strict Rules) |
| 48 | - Luôn viết bằng **Tiếng Việt**. |
| 49 | - Không tự suy diễn các yêu cầu nghiệp vụ phức tạp nếu không có căn cứ từ UI. Nếu thiếu logic, hãy liệt kê chúng vào mục "Câu hỏi/Làm rõ với PO-User". |
| 50 | - Nếu có Playwright MCP, ưu tiên mở browser thật để screenshot/capture giao diện nếu cần. |