@edupia-tutor/spec-driven-docs 0.14.6 → 0.14.8

package/core/skills/prd/SKILL.md

@@ -4,475 +4,16 @@ description: Sinh PRD từ một product definition, hoặc phân tích một PR
 
 # PRD Skills — Generate & Refine
 
-Skill này xử lý hai lệnh: `/generate-prd` để tạo PRD, và `/refine-prd` để phân tích PRD tìm gap.
-
----
+Skill này xử lý `/generate-prd` và `/refine-prd`. Để **không lệch logic/schema**, skill KHÔNG nhân bản — mỗi lệnh thực thi **y hệt** command tương ứng.
 
 ## /generate-prd — Sinh Product Requirements Document
 
-### Gate
-
-<!-- Directory: {paths.product_definitions_dir}/**/*.md -->
-# Gate — Quy trình vào chuẩn cho mọi lệnh
-
-Mọi lệnh PHẢI chạy gate này trước khi thực thi phần logic riêng của nó.
-
-## Bước 0 — Kiểm tra chế độ Sub-Agent
-
-Trước tiên, kiểm tra xem `$ARGUMENTS` có phải là payload JSON từ một orchestrator hay không:
-
-1. Thử parse `$ARGUMENTS` dưới dạng JSON.
-2. Nếu parse thành công **và** chứa `"_agent_mode": true`:
-   - **Bỏ qua hoàn toàn Bước 1, 2 và 3 của Gate này.**
-   - Đặt target file = `payload.target_file`
-   - Đặt loaded context = `payload.context` (KHÔNG chạy context-loader.md)
-   - Đặt phạm vi UC = `payload.uc_id` (chỉ xử lý UC này)
-   - Đặt line range = `payload.uc_section` (chỉ đọc đúng section đó của PRD)
-   - Đặt dimension = `payload.dimension` nếu có (lệnh review per-UC: chỉ review đúng lăng kính này)
-   - Đi thẳng tới phần logic riêng của lệnh.
-3. Nếu `$ARGUMENTS` không phải JSON hoặc không có `_agent_mode` → tiếp tục sang Bước 1 (chế độ thường).
-
-## Bước 0-B — Kiểm tra Model
-
-*Bỏ qua bước này nếu `_agent_mode: true` (sub-agent — orchestrator đã kiểm tra rồi).*
-
-Các lệnh sinh nội dung và review phức tạp đòi hỏi khả năng suy luận mạnh.
-Dùng model nhỏ hơn sẽ rủi ro: bỏ sót edge case, phân tích spec thiếu sót, vi phạm kiến trúc.
-
-Hiển thị và chờ phản hồi:
-
-```
-⚙️  MODEL CHECK
-──────────────────────────────────────────────────────────────────
-  Recommended  : claude-opus-4 (hoặc model Opus mới nhất)
-  Why needed   : Phân tích spec, review kiến trúc, sinh code đòi hỏi
-                 suy luận sâu. Model nhỏ hơn dễ bỏ sót edge case.
-
-  Cách đổi trong Claude Code:
-    • Settings → Model → chọn "claude-opus"
-    • hoặc: /model → chọn claude-opus
-
-  Đang chạy claude-opus?
-    Y — đúng, đang dùng claude-opus → tiếp tục
-    S — bỏ qua kiểm tra (tôi chấp nhận rủi ro chất lượng thấp hơn với model hiện tại)
-──────────────────────────────────────────────────────────────────
-```
-
-- "Y" → tiếp tục sang Bước 1.
-- "S" → tiếp tục sang Bước 1 (người dùng chấp nhận rủi ro, thêm ⚠️ vào report cuối).
-- "N" hoặc bất kỳ giá trị nào khác → **DỪNG.** Xuất: "Vui lòng chuyển sang claude-opus rồi chạy lại lệnh này."
-
-## Bước 1 — Xác định Target File
-
-1. Nếu `$ARGUMENTS` được cung cấp và trỏ tới một file tồn tại → dùng trực tiếp làm target.
-2. Nếu `$ARGUMENTS` là một **UC-ID / ticket ID / tên rút gọn** (không có path) → phân giải thành file bằng cách glob theo bố cục feature-package. `{prd-slug}` lúc này **chưa biết**, nên dùng wildcard `*` cho segment đó, và `**` đệ quy dưới `bdd/` để phủ hết các thư mục con theo platform (`bdd/web/`, `bdd/app/`, `bdd/system/`):
-   - **Lệnh BDD** (target là `.feature`): `{specs_dir}/{domain}/*/bdd/**/{UC-ID}*.feature` — hoặc `{specs_dir}/*/*/bdd/**/{UC-ID}*.feature` nếu domain cũng chưa biết. Nếu lệnh ngụ ý một platform/scope cụ thể (vd: system tech-doc cần BDD `system/`), ưu tiên kết quả trong thư mục con platform đó.
-   - **Lệnh PRD** (target là file PRD `{TICKET-ID}-{prd-slug}.md` — file `.md` duy nhất ở gốc feature folder, cạnh `bdd/`): `{specs_dir}/{domain}/*/{TICKET-ID}*.md` nếu biết TICKET-ID; nếu không, `{specs_dir}/{domain}/*/*.md` (khớp feature folder có id tương ứng), hoặc `{specs_dir}/*/*/*.md` nếu domain cũng chưa biết. *(Glob `*/*.md` ở cấp gốc folder chỉ khớp PRD — tech-docs/design-spec `.md` nằm sâu hơn trong thư mục con.)*
-   - **Lệnh tech-docs**: `{specs_dir}/{domain}/*/tech-docs/{UC-ID}*-tech-design*.md`.
-   - **Lệnh design-spec**: `{specs_dir}/{domain}/*/design-spec/{TICKET-ID}*.md`.
-
-   Khi một file khớp: đặt nó làm target **và** ghi lại `domain` + `prd_slug` từ path của nó (theo quy tắc trích xuất trong `context-loader.md` Bước 1 — `prd_slug` = segment đầu tiên sau `{specs_dir}/{domain}/`). Mọi path mà lệnh đọc/ghi về sau (BDD/tech-docs/design-spec/trace cùng cấp) đều dùng **`prd_slug` đã phân giải đó**, nên tất cả artifact nằm chung một feature package. Nếu nhiều file khớp (vd: nhiều platform), chọn theo platform/scope của lệnh hoặc liệt kê ra và hỏi.
-3. Nếu `$ARGUMENTS` rỗng hoặc không tìm thấy file khớp:
-   - Liệt kê các file trong thư mục liên quan của lệnh này (vd: `specs/*/*/*.md` — file PRD ở gốc mỗi feature folder — cho lệnh PRD, `specs/*/*/bdd/**/*.feature` cho lệnh BDD).
-   - Hiển thị danh sách cho người dùng và hỏi: "Bạn muốn làm việc với file nào? (Nhập số thứ tự hoặc tên file)"
-   - Chờ người dùng chọn rồi mới tiếp tục.
-
-## Bước 2 — Chạy Context Loader
-
-Nạp toàn bộ context của dự án bằng cách làm theo quy trình trong `steps/context-loader.md`.
-Lưu toàn bộ context đã nạp vào bộ nhớ để dùng xuyên suốt phiên làm việc của lệnh.
-
-## Bước 3 — CHECKPOINT
-
-Sau khi hoàn thành Bước 1 và 2, hiển thị bản tóm tắt và chờ xác nhận:
-
-```
-CHECKPOINT
------------
-Target     : {resolved file path}
-Project    : {project.name từ project-context.yaml}
-Tech stack : {language} / {framework}
-Module     : {module nếu có, else "not configured"}
-Domains    : {danh sách domain, ngăn cách bởi dấu phẩy}
-
-Tiếp tục? (Y/N)
-```
-
-Chờ người dùng trả lời rõ ràng "Y" hoặc "N" rồi mới tiếp tục.
-- "Y" → tiếp tục sang các bước riêng của lệnh bên dưới.
-- "N" → dừng lại và hỏi người dùng muốn thay đổi gì.
-
-
-### Quy tắc nội dung — chống jargon kỹ thuật *(áp dụng cho mọi PRD sinh ra)*
-
-**1. PRD platform-agnostic — chỉ mô tả WHAT (nghiệp vụ), KHÔNG mô tả HOW (kỹ thuật).**
-Viết AC / Business Rule / Business Logic theo *kết quả nghiệp vụ*, KHÔNG nhét chi tiết triển khai (API, JWT/token, endpoint, HTTP status, tên class/bảng/cột DB, query, spinner, animation…). Những thứ đó thuộc **Tech Docs** (kỹ thuật) hoặc **Design Spec** (giao diện).
-
-| ✅ Viết trong PRD (nghiệp vụ) | ❌ KHÔNG viết trong PRD |
-|---|---|
-| "Đăng nhập thành công → truy cập được tính năng" | "API trả về JWT token" ← Tech Docs |
-| "Sai mật khẩu 5 lần → khoá tài khoản 30 phút" | "Click button → hiện toast" ← Design Spec |
-| "Phiên hết hạn → yêu cầu xác thực lại" | "Hiển thị spinner khi loading" ← Design Spec |
-
-- Nếu PO đưa chi tiết UI (màu, layout, animation) → **nhắc**: *"Chi tiết UI này thuộc Design Spec, không thuộc PRD. Ghi nhận để tạo Design Spec sau."*
-- Enum/thuật ngữ kỹ thuật ĐÃ chuẩn hoá trong domain-knowledge (vd `userType`, `TYPE_1`) thì giữ nguyên gốc — đây là từ vựng nghiệp vụ, KHÔNG phải jargon triển khai.
-
-**2. Terminology — bám từ điển dự án.**
-- Thay mọi **banned term** bằng canonical term (xem `business-dictionary.md` § Banned Terms); ghi chú việc thay ở mục **Giả định AI**.
-- Status/Enum → lấy đúng giá trị trong `core-entities.md` (Enum Registry).
-- **Thuật ngữ MỚI**: nếu input PO có từ chưa có trong `business-dictionary.md` và lặp ≥2 lần → **DỪNG, hỏi PO** (nghĩa là gì / canonical term / có thêm vào từ điển không) trước khi tiếp tục.
-
-**3. Cross-reference bắt buộc.** Mọi chỗ nhắc TICKET-ID khác → inline link `[TICKET-ID](./file.md)` nếu file PRD tồn tại; không để plain text.
-
-### Generate
-
-Sinh PRD theo đúng cấu trúc chuẩn dưới đây (template canonical: `templates/prd.template.md`). Quy ước bắt buộc:
-
-- **Ngôn ngữ:** heading + nội dung viết tiếng Việt (giữ thuật ngữ kỹ thuật/Enum nguyên gốc).
-- **Tiêu đề file:** `# {TICKET}-{N} {Feature Name}` — KHÔNG thêm tiền tố "PRD —".
-- **Tên file ghi ra:** `specs/{domain}/{prd-slug}/{TICKET}-{prd-slug}.md` (vd `SEG01-segment-scoring-service.md` — KHÔNG đặt tên `prd.md`; bố cục feature-package — mọi artifact của feature nằm chung folder này, PRD là file `.md` duy nhất ở gốc folder).
-- **Business Rule:** đặt BÊN TRONG từng Use Case (không gom thành mục phẳng), bảng 3 cột `ID | Business Rule | Business Logic`; ID theo dạng `{TICKET}-{N}-UC{n}-BR{m}` (đánh số BR liên tục xuyên suốt các UC, không reset mỗi UC).
-- **Acceptance Criteria:** danh sách phẳng `**AC{n}:**`, văn xuôi — KHÔNG ép Given/When/Then.
-- **Liên kết:** trỏ tới PRD/tài liệu liên quan bằng link tương đối; trỏ `core-entities` / `business-dictionary` ở mục Tài liệu tham khảo.
-- **Giả định AI:** nếu phát hiện độ vênh/giả định chưa được PO chốt → liệt kê thành `Q1…Qn` để PO xác nhận; nếu mọi thứ đã rõ từ product-definition → ghi "Không có — toàn bộ nội dung đã được PO xác nhận".
-
-Template (cấu trúc đầu ra — single-source từ `templates/prd.template.md`):
-
-````markdown
-# {TICKET}-{N} {Feature Name}
-
-<!--
-  Template này được sử dụng bởi workflow /generate-prd.
-  AI Agent sẽ điền các section dựa trên input từ PO.
-  Các placeholder {…} cần được thay thế bằng nội dung thực tế.
-
-  FORMAT CHUẨN: Business Rule = bảng 3 cột
-  ID | Business Rule | Business Logic (KHÔNG tách Business Logic ra khối riêng).
-
-  TERMINOLOGY:
-  - Tuân thủ 100% từ điển project: specs/domain-knowledge/business-dictionary.md
-    (KHÔNG dùng từ điển của project khác). Thay banned term bằng canonical term;
-    nếu phát hiện banned term trong input PO → thay + ghi chú trong "Giả định AI".
-  - Status/Enum values → tham chiếu core-entities.md (Enum Registry).
-
-  CROSS-REFERENCE (BẮT BUỘC): Bất kỳ chỗ nào nhắc đến một tính năng/ticket khác
-    (pre-condition, business rule, giả định, AC, hay bất kỳ section nào) → PHẢI gắn inline link:
-      [TICKET-ID khác](../{prd-slug-khác}/{TICKET-ID-khác}-{prd-slug-khác}.md)
-    Không để TICKET-ID dạng plain text nếu tồn tại file PRD tương ứng. (Mỗi PRD nằm trong feature-package riêng nên link trỏ sang folder anh em `../{prd-slug-khác}/`.)
-    Ngoài ra, ghi rõ quan hệ phụ thuộc trong "Tài liệu tham khảo" ở Appendix.
-
-  NEW TERM DETECTION: Nếu input PO xuất hiện thuật ngữ CHƯA CÓ trong business-dictionary.md
-    và lặp lại ≥ 2 lần → DỪNG lại, hỏi PO confirm trước khi tiếp tục:
-      + Thuật ngữ đó nghĩa gì trong ngữ cảnh hệ thống?
-      + English term chuẩn nên dùng là gì?
-      + Có cần bổ sung vào business-dictionary.md không?
-    Sau khi PO confirm → cập nhật business-dictionary.md (nếu PO đồng ý) rồi mới tiếp tục.
-
-  NUMBERING:
-  - UC ID: {TICKET}-{N}-UC{n}  (n bắt đầu từ 1, tăng theo từng use case)
-  - BR ID: {TICKET}-{N}-UC{n}-BR{m}  (m tăng LIÊN TỤC xuyên suốt PRD, KHÔNG reset mỗi UC)
--->
-
----
-
-## Metadata
-
-| Field         | Value                                    |
-|---------------|------------------------------------------|
-| **PRD ID**    | {TICKET}-{N}                             |
-| **Version**   | 1.0                                      |
-| **Status**    | draft                                    |
-| **Author**    | AI-assisted                              |
-| **PO**        | {tên PO}                                 |
-| **Domain**    | {domain}                                 |
-| **Created**   | {date}                                   |
-| **Updated**   | {date}                                   |
-| **Ticket**    | {TICKET}-{N}{ — nếu PO có link tracker thật, thêm bên cạnh: `{TICKET}-{N} ([Jira]({tracker_url}))`} |
-| **API Source** | *(để trống nếu greenfield — chỉ điền `existing` khi PRD bọc một API đã chạy production)* |
-
----
-
-# Feature
-
-**{Feature Name}**
-
-{Đoạn mô tả tổng quan: feature làm gì, cho ai, giải quyết vấn đề gì — lấy từ product-definition.}
-
----
-
-# 1. Tổng quan
-
-## a. User Story
-
-- **Là một (As a)** {persona}
-- **Tôi muốn (I want to)** {action}
-- **Để (So that)** {benefit}
-
-## b. Phạm vi
-
-**In Scope**
-- {hạng mục trong phạm vi 1}
-- {hạng mục trong phạm vi 2}
-
-**Out of Scope** *(chỉ thêm khi có ranh giới cần nói rõ)*
-- {hạng mục ngoài phạm vi + lý do / chủ sở hữu}
-
-## c. Phụ thuộc liên service *(mức nghiệp vụ — KHÔNG mô tả API/event/kỹ thuật)*
-
-> Kế thừa từ Product Definition Phase 1 ("Phụ thuộc liên service"). Nếu contract do đối tác phát triển song song (xem `API Source`), ghi phụ thuộc partner vào đây.
-
-- {Cần {dữ liệu/năng lực} từ {feature/team/partner} — vì {lý do nghiệp vụ}} — hoặc "Không có"
-
----
-
-# 2. Acceptance Criteria
-
-> Mỗi AC kế thừa liên kết "Bắt nguồn từ BR" của Product Definition (Phase 6), remap sang BR ID của PRD. Vì BR ID đã chứa số UC nên ref BR truy ngược được tới đúng UC.
-
-**AC1:** {Tiêu chí nghiệm thu, văn xuôi, kiểm chứng được.} _(BR: {TICKET}-{N}-UC{n}-BR{m})_
-
-**AC2:** {…} _(BR: {TICKET}-{N}-UC{n}-BR{m})_
-
----
-
-# 3. Use Case
-
-#### {TICKET}-{N}-UC1: {Tên use case}
-
-**Actor:** {actor}
+→ **Đọc và tuân theo `commands/generate-prd.md`** với cùng `$ARGUMENTS`.
 
-**Description:** {mô tả luồng}
-
-**Pre-condition:**
-- {điều kiện trước 1}
-
-**Post-condition:**
-- {kết quả sau 1}
-
-**AC liên quan:** AC{x}, AC{y}  *(các AC mà UC này thoả — phải đúng bằng tập AC có ref BR trỏ về UC này ở §2)*
-
-**Business Rule**
-
-| ID | Business Rule | Business Logic |
-|----|---------------|----------------|
-| {TICKET}-{N}-UC1-BR1 | {luật ngắn gọn} | - {logic chi tiết, xuống dòng bằng `<br/>`}<br/>- {…} |
-| {TICKET}-{N}-UC1-BR2 | {…} | - {…} |
-
----
-
-#### {TICKET}-{N}-UC2: {Tên use case}
-
-{lặp cấu trúc UC như trên; BR đánh số tiếp tục BR3, BR4…}
-
----
-
-# 4. UI/UX Guidelines
-
-## a. User Flow
-
-```mermaid
-flowchart TD
-    START(["{điểm bắt đầu}"]) --> A{"{điểm quyết định}"}
-    A -->|{nhánh}| B["{bước}"]
-```
-
-## b. Wireframe
-
-### Screen 1: {Tên màn}
-
-| Thành phần | Chi tiết |
-|------------|----------|
-| **Screen** | {tên/ngữ cảnh màn} |
-| **Components** | - {thành phần 1}<br/>- {thành phần 2} |
-| **Actions** | - {hành động 1 → kết quả}<br/>- {hành động 2 → kết quả} |
-
----
-
-### Screen 2: {Tên màn}
-
-{lặp bảng như trên cho từng màn}
-
----
-
-# Appendix
-
-## Input gốc từ PO
-
-> {Trích nguyên văn input/ghi chú gốc của PO + đường dẫn product-definition nguồn.}
-
-## Tài liệu tham khảo
-
-- [{TICKET liên quan}](../{prd-slug-khác}/{TICKET-ID-khác}-{prd-slug-khác}.md) — {quan hệ: pre-condition / overlapping / related…}
-- Từ điển nghiệp vụ: `{path}/business-dictionary.md`
-- Domain knowledge: `{path}/{domain}.md`
-
-## Existing API Contract *(CHỈ brownfield — điền khi API Source = existing; greenfield BỎ QUA cả section này)*
-
-<!--
-  Chỉ dùng khi PRD bọc một API đã tồn tại trên hệ thống. PO ghi lại contract để:
-  - /generate-bdd (system) dùng trực tiếp làm input — không cần tổng hợp từ FE/App BDD;
-  - /generate-tech-docs chạy mode reverse-document (mô tả lại as-is, không design mới);
-  - /review-tech-docs bỏ qua cổng T7 cross-team sign-off (contract đã cố định).
-  Nếu greenfield (thiết kế mới) → xoá toàn bộ section này.
--->
-
-| Method | Path | Auth | Request | Response |
-|--------|------|------|---------|----------|
-| {GET/POST/PUT/DELETE} | {/api/v1/path} | {Bearer / none} | `{ field: type }` | `{ field: type }` |
-
-**Error responses:**
-
-| HTTP Status | Error Code | Khi nào xảy ra |
-|-------------|------------|----------------|
-| {4xx/5xx} | {ERR_CODE} | {condition} |
-
-## Giả định AI
-
-> {Giả định / độ vênh AI phát hiện khi đối chiếu product-definition với domain-knowledge — cần PO review. AI KHÔNG tự hoà giải.}
-
-- **Q1 — [AI DRAFT] {tiêu đề}:** {mô tả độ vênh + nguồn}. **Cần PO chốt {điều gì}.**
-
-_(Nếu không có độ vênh: ghi "Không có — toàn bộ nội dung đã được PO xác nhận qua Product Definition.")_
-
----
-
-# Change Log
-
-### v1.0 — {mô tả} ({date})
-
-| Mục | Thay đổi |
-|-----|----------|
-| — | Bản đầu — sinh từ product-definition. |
-
----
-
-<!--
-  NEXT STEPS:
-  Khi PRD được approve (status: approved), chạy:
-  /generate-bdd "specs/{domain}/{prd-slug}/{TICKET-ID}-{prd-slug}.md"
-  để sinh BDD feature specs từ PRD này.
--->
-
-````
-
-### Output
-
-```
-✅ Đã tạo PRD: specs/{domain}/{prd-slug}/{TICKET}-{prd-slug}.md
-Status: draft
-```
-
-# Report Footer — Định dạng output chuẩn cho mọi lệnh
-
-Mọi report của lệnh phải kết thúc bằng section footer chuẩn này.
-
-## Status Badge
-
-Chọn một theo kết quả:
-- `✅ Complete` — mọi bước thành công, không có vấn đề
-- `❌ Failed` — lệnh không hoàn thành được do lỗi chặn
-- `⚠️ Warnings` — hoàn thành nhưng có vấn đề không chặn, nên review lại
-
-## Output Artifacts
-
-Liệt kê mọi file được tạo hoặc sửa bởi lệnh này:
-```
-Output Artifacts:
-  {created|updated} {file-path} ({mô tả ngắn})
-  {created|updated} {file-path} ({mô tả ngắn})
-```
-
-Nếu không ghi file nào (vd: lệnh review hoặc phân tích) → ghi `Output Artifacts: none (read-only)`.
-
-## Pipeline Position
-
-In một sơ đồ pipeline một dòng, đánh dấu phase của lệnh HIỆN TẠI bằng `◀ bạn ở đây`,
-để người dùng luôn thấy lệnh này nằm ở đâu trong luồng end-to-end:
-
-```
-Discovery → PRD → [Design Spec] → BDD → Tech Design → Code → Dev Self-Check → QC → Trace Audit
-```
-
-Tìm lệnh hiện tại trong bảng phase dưới đây và đánh dấu **phase của nó** trong sơ đồ trên:
-
-| Phase | Commands |
-|-------|----------|
-| Discovery | `/define-product` |
-| PRD | `/generate-prd` · `/refine-prd` · `/review-context` (PRD) |
-| Design Spec | `/generate-design-spec` |
-| BDD | `/generate-bdd` · `/review-context` (BDD) |
-| Tech Design | `/generate-tech-docs` · `/map-testids` · `/review-tech-docs` |
-| Code | `/generate-code` · `/review-code` |
-| Dev Self-Check | `/dev-gen-test` · `/dev-run-test` · `/dev-smoke-test` |
-| QC | `/qc-analyze` · `/qc-plan` · `/qc-design-test` · `/qc-review` · `/qc-run-test` · `/qc-report` |
-| Trace Audit | `/validate-traces` |
-
-Với **lệnh review**, thêm vòng review 3 bước và đánh dấu bước hiện tại, vd:
-`Vòng review: [① phân tích ◀] → ② Review Board → ③ --resume`.
-
-**Lệnh xuyên suốt** (`/sync`, `/update-framework`, `/fix-bug`, `/debug`, `/learn`,
-`/report-bug`, `/propose-scenario`, `/generate-spec-manifest`) nằm ngoài pipeline tuyến tính —
-**bỏ hẳn dòng Pipeline** cho các lệnh này (đừng cố nhét chúng vào sơ đồ).
-
-## Gợi ý lệnh tiếp theo
-
-Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
-
-| Lệnh hiện tại           | Gợi ý lệnh tiếp theo                          |
-|-------------------------|-----------------------------------------------|
-| /setup-ai-first         | `/define-product` để bắt đầu feature đầu tiên |
-| /define-product         | `/generate-prd {product-definition-file}`     |
-| /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
-| /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
-| /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
-| /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
-| /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |
-| /qc-analyze             | `/qc-plan {UC-ID}` (xử lý các gap blocker 🔴 trước) |
-| /qc-plan                | `/qc-design-test {UC-ID}`                     |
-| /qc-design-test         | `/qc-review {UC-ID}` (review test-case)       |
-| /qc-review (test-case)  | `/qc-run-test {UC-ID}` nếu APPROVED; sửa TC nếu NEEDS_FIX |
-| /qc-run-test            | `/qc-report {UC-ID}` rồi `/qc-review {UC-ID}` (review script) |
-| /qc-review (script)     | `/qc-report {UC-ID}` rồi tạo PR nếu APPROVED |
-| /qc-report              | `/validate-traces {UC-ID}` để làm mới Living Docs (qc_status) |
-| /generate-tech-docs     | `/review-tech-docs {tech-design-file}`        |
-| /review-tech-docs       | `/generate-code {feature-file}` nếu APPROVED; sửa doc nếu NEEDS_FIX |
-| /generate-code          | Lần gen đầu → `/review-code {UC-ID}`; gen lại → `/dev-gen-test {UC-ID}` |
-| /dev-gen-test         | `/dev-run-test {UC-ID}`                          |
-| /dev-run-test (passing)    | `/review-code {UC-ID}`                        |
-| /dev-run-test (failing)    | `/fix-bug {ticket-id}` hoặc `/debug {error}`    |
-| /review-code            | `/dev-smoke-test {UC-ID}` hoặc tạo PR            |
-| /dev-smoke-test             | Tạo PR và link tới ticket                  |
-| /validate-traces        | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/dev-gen-test {UC-ID}`; tất cả OK → tạo PR |
-| /fix-bug                | Tạo PR và link tới ticket                  |
-| /debug                  | `/fix-bug {ticket-id}` nếu cần sửa          |
-| /report-bug             | Gửi cho dev (`/fix-bug {BUG-ID}`); nếu thiếu coverage → `/propose-scenario {UC-ID}` |
-| /propose-scenario       | Báo PO/Dev review proposal trong `feedback/bdd-proposals/` |
-| /learn                  | Tiếp tục làm việc — lesson áp dụng ở lệnh kế tiếp |
-| /sync                   | `/validate-traces` để xem độ phủ đầy đủ; xử lý mọi `📥 tester feedback` được nêu |
-| /update-framework       | Review `git diff .agent/`, commit; `/sync` để đồng bộ nội dung dự án |
-
-Định dạng footer như sau:
-```
----
-Status   : {badge}
-{khối Output Artifacts}
-Pipeline : Discovery → PRD → [BDD ◀ bạn ở đây] → Tech Design → Code → Dev Self-Check → QC → Trace Audit
-           (lệnh review) Vòng review: [① phân tích ◀] → ② Review Board → ③ --resume
-Next     : {lệnh gợi ý kèm ví dụ tham số}
-```
-*(Bỏ dòng `Pipeline` cho các lệnh xuyên suốt liệt kê ở trên.)*
-
-
----
+Command lo: guard discovery completed · phân giải API Source (existing/greenfield/partner) · Terminology Map · map §1c "Phụ thuộc liên service" + §4b Wireframe · slug kế thừa · template canonical (`templates/prd.template.md`) · Change Log rolling-window.
 
 ## /refine-prd — Phân tích PRD qua 4 lăng kính review
 
-Lệnh này thực thi **y hệt** `commands/refine-prd.md` — không nhân bản logic ở đây để tránh lệch schema findings.
-
-`commands/refine-prd.md` bao gồm:
-- Phân tích PRD bằng 4 lăng kính **fan-out đa sub-agent** (QA / DEV / SA / PO) + vòng completeness-critic (1 lần chạy ra đủ finding).
-- Ghi findings YAML với **schema đầy đủ** (`uc_id`, `quote`, `auto_fixable`) — bắt buộc cho source-jump và nút "Apply to PRD" của Review Board.
-- **Resume Mode** (`--resume`): áp dụng findings đã accept → bump version → ghi changelog → reset `draft`.
-
 → **Đọc và tuân theo `commands/refine-prd.md`** với cùng `$ARGUMENTS`.
+
+Command lo: 4 lăng kính fan-out đa sub-agent + completeness-critic (findings đầy đủ 1 lần chạy) · schema findings đầy đủ (`uc_id`, `quote`, `auto_fixable`) cho Review Board · Resume Mode (apply → bump version → reset draft → changelog).