Bấm một dòng trong bảng để xem câu lệnh của skill đó.
| Lệnh | Nhóm | Dùng khi nào | Cần gì trước | Đẻ ra file gì |
|---|---|---|---|---|
/prd | 01 Sản phẩm | Định hình cả sản phẩm: tầm nhìn, người dùng, giá trị, rồi bóc ra Feature Map. | Ý tưởng sản phẩm | docs/_product/prd.md |
/roadmap | 01 Sản phẩm | Xếp ưu tiên Feature Map thành Now / Next / Later hoặc chia theo quý. | /prd | docs/_product/roadmap.md |
/discover | 01 Sản phẩm | Một feature còn phân vân: điều tra nhu cầu + đối thủ rồi khuyến nghị build / skip. | Feature Map (khuyến khích) | docs/_research/{date}-{slug}.md |
/brainstorm | 02 Làm rõ | Có ý tưởng thô cho một feature, cần phỏng vấn làm rõ trước khi viết tài liệu. | Một câu mô tả ý tưởng | docs/{feature}/brainstorms/{idea}.md |
/meet | 02 Làm rõ | Có transcript hoặc ghi chú họp, cần biến thành biên bản có decision / action / RAID. | Transcript hoặc note thô | docs/meetings/{date}-{type}-{slug}.md |
/urd | 03 Đặc tả | Ghi rõ người dùng là ai, cần gì, hành trình ra sao, thế nào là thành công. | /brainstorm | docs/{feature}/{feature}-urd.md |
/brd | 03 Đặc tả | Ghi lý do kinh doanh, mục tiêu SMART, ROI, stakeholder, rủi ro. | /brainstorm hoặc /urd | docs/{feature}/{feature}-brd.md |
/prd-epic | 03 Đặc tả | Chốt phạm vi một feature: capability P0/P1/P2, luồng chính, kế hoạch release. | /urd hoặc /brd | docs/{feature}/{feature}-prd.md |
/srs | 03 Đặc tả | Tài liệu lõi. Kỹ thuật hoá scope thành FR / NFR / Business Rule / bảng mã lỗi. | /prd-epic (mềm) | docs/{feature}/srs/{feature}-spec.md |
/update-overview | 03 Đặc tả | Quản lý 6 tài liệu dùng chung cấp dự án: thuật ngữ, quy ước, môi trường, bối cảnh. | Có ít nhất một feature | docs/_shared/ |
/sequence | 04 Sơ đồ | Vẽ trình tự trao đổi giữa các hệ thống trong một luồng (login, checkout, webhook). | /srs | docs/{feature}/srs/{feature}-flows.md |
/activity | 04 Sơ đồ | Vẽ luồng xử lý có nhiều nhánh quyết định, bằng Mermaid nhúng thẳng vào file. | /srs | docs/{feature}/srs/{feature}-flows.md |
/activity-swimlane | 04 Sơ đồ | Quy trình đa vai trò cần lane thẳng cột thật - PlantUML, không phải subgraph giả. | /srs hoặc /usecase | docs/{feature}/srs/{feature}-{slug}-swimlane.puml |
/bpmn | 04 Sơ đồ | Cần BPMN 2.0 chuẩn OMG để import Camunda / Bizagi (approval, onboarding, refund). | /usecase hoặc /srs | docs/{feature}/bpmn/{process}.bpmn |
/state | 04 Sơ đồ | Một đối tượng có nhiều trạng thái và chuyển đổi (Account, Order, Subscription). | /srs | docs/{feature}/srs/{feature}-states.md |
/erd | 04 Sơ đồ | Mô hình dữ liệu nghiệp vụ, Mermaid nhúng inline. Bản gốc của họ ERD. | /srs | docs/{feature}/srs/{feature}-erd.md |
/d2-erd | 04 Sơ đồ | Cùng ERD nhưng vẽ đẹp bằng D2, file ảnh riêng để đưa vào slide. | /erd | docs/{feature}/d2-erd/{feature}.d2 |
/d2-activity | 04 Sơ đồ | Activity nhiều nhánh mà Mermaid dàn xấu - D2 layout ELK gọn hơn. | /srs | docs/{feature}/d2/{slug}.d2 |
/d2-architect | 04 Sơ đồ | Sơ đồ kiến trúc hệ thống: component, service, DB lồng nhau. | /srs | docs/{feature}/d2-architect/{slug}.d2 |
/dbdiagram | 04 Sơ đồ | Tầng gần dev nhất: schema DBML với kiểu DB thật, enum, index. | /erd | docs/{feature}/dbdiagram/{feature}.dbml |
/usecase-diagram | 04 Sơ đồ | Sơ đồ tổng quan actor và use case để chốt phạm vi bằng hình. | /usecase | docs/{feature}/usecases/{feature}-usecase-diagram.svg |
/user-flow | 05 Màn hình | Chạy đầu tiên trong nhóm màn hình. Chia feature thành các flow, phủ happy / error / edge. | /srs | docs/{feature}/srs/{feature}-userflow.md |
/wireframe-ascii | 05 Màn hình | Phác màn bằng ký tự, gộp theo flow, kèm bảng mô tả 5 cột dùng chung. | /user-flow | docs/{feature}/ascii-wireframe/{flow}.md |
/wireframe-html | 05 Màn hình | Cùng màn đó nhưng render element HTML thật, đen trắng, mở bằng trình duyệt. | /user-flow | docs/{feature}/html-wireframe/{flow}.html |
/figma | 05 Màn hình | Vẽ thật lên Figma qua MCP, tuân design token. Cần cài Reqwise Figma MCP. | /wireframe-ascii | File trên Figma |
/prototype-html | 05 Màn hình | Bậc cao nhất: một file HTML bấm được như app thật, giữ state, có lớp góp ý. | /user-flow + /wireframe-ascii | docs/{feature}/html-design/{feature}-prototype.html |
/prototype-next | 05 Màn hình | Prototype chạy được bằng Next.js, sinh code thật, tự build và smoke test. | /user-flow + /usecase | prototype/ |
/usecase | 06 Backlog & bàn giao | Viết use case chuẩn Cockburn: actor, tiền đề, luồng chính, nhánh mở rộng. | /srs (hoặc chạy chế độ khám phá) | docs/{feature}/usecases/uc-{slug}.md |
/userstory | 06 Backlog & bàn giao | Bóc FR / use case / màn hình thành user story đưa vào backlog. | /srs | docs/{feature}/userstories/us-{NNN}.md |
/ac | 06 Backlog & bàn giao | Viết, sửa hoặc soi lại Acceptance Criteria dạng Given / When / Then. | /userstory | Ghi thẳng vào us-{NNN}.md |
/jira | 06 Backlog & bàn giao | Đồng bộ hai chiều backlog với Jira Cloud. Không cờ = chỉ xem drift, an toàn. | /userstory + Atlassian MCP | Jira + docs/_shared/jira-map.md |
/confluence | 06 Backlog & bàn giao | Đồng bộ hai chiều tài liệu với Confluence Cloud. | Tài liệu + Atlassian MCP | Confluence page |
/export | 06 Backlog & bàn giao | Đóng gói tài liệu một feature gửi stakeholder: PDF, DOCX hoặc HTML. | Tài liệu đã duyệt | docs/exports/{date}-{slug}-package.pdf |
/userguide | 06 Backlog & bàn giao | Viết cẩm nang vận hành cho admin / CSKH, có thể tự chụp ảnh màn hình thật. | Tài liệu feature | docs/userguide/{feature}-userguide.html |
/preview | 06 Backlog & bàn giao | Gộp mọi file Markdown của một feature thành một trang HTML xem được. | Có tài liệu | docs/{feature}/{feature}-preview.html |
/api-assess | 07 Tích hợp API | Chưa chốt đối tác, hoặc còn cân nhắc tự làm hay mua. Scorecard rồi khuyến nghị. | Nhu cầu tích hợp | docs/{feature}/integration/api-assess.md |
/api-doc | 07 Tích hợp API | Đọc hiểu tài liệu API đối tác (OpenAPI / PDF / URL) thành doc nghiệp vụ. | Tài liệu API của đối tác | docs/{feature}/integration/api-summary.md |
/api-design | 07 Tích hợp API | Bước quan trọng nhất họ API: thiết kế cách các hệ thống phối hợp, retry, đối soát. | /api-doc + /srs | docs/{feature}/integration/api-design.md |
/api-map | 07 Tích hợp API | Bảng ánh xạ field ba tầng: API ↔ entity hệ thống ↔ field trên UI. | /api-design | docs/{feature}/integration/api-map.md |
/api-checklist | 07 Tích hợp API | Phỏng vấn discovery để ra outline kịch bản cần test, chưa cần data chi tiết. | /api-design | docs/{feature}/test/api/api-checklist.md |
/api-test | 07 Tích hợp API | Biến checklist thành file .bru chạy được bằng Bruno. Secret chỉ nằm trong .env. | /api-checklist | docs/{feature}/test/api/bruno/ |
/api-readiness | 07 Tích hợp API | Cổng go-live: cutover, feature flag, monitoring, rollback, bảng go / no-go. | /api-test | docs/{feature}/integration/api-readiness.md |
/test-checklist | 08 Kiểm thử | Outline kịch bản cần test để review trước, chưa viết test case đầy đủ. | /srs + /userstory | docs/{feature}/test/checklist/ |
/test-cases | 08 Kiểm thử | Sinh test case chi tiết 1:1 từ checklist. Bắt buộc có checklist trước. | /test-checklist | docs/{feature}/test/testcases/ |
/playwright-gen | 08 Kiểm thử | Codegen script Playwright .spec.ts chạy được từ test case UI. | /test-cases | docs/{feature}/test/e2e/ |
/gap | 09 Kiểm & bảo trì | Soi feature còn thiếu luồng nghiệp vụ gì: vào được trạng thái mà không ra được. | Tài liệu feature | docs/_shared/traceability.md |
/ask | 09 Kiểm & bảo trì | Hỏi thẳng nghiệp vụ này đang chạy thế nào. Trả lời ngay trong chat, không ghi file. | Tài liệu feature | Không ghi file |
/doc-drift | 09 Kiểm & bảo trì | Code dev có khớp tài liệu BA không. Ra một báo cáo, không tự sửa gì. | Tài liệu + đường dẫn source code | docs/reports/doc-drift/ |
/cr | 09 Kiểm & bảo trì | Sửa một thay đổi vào tài liệu đã có: phân tích tác động rồi mới áp dụng. | Tài liệu đã duyệt | docs/cr/CR-{id}.md |
/dashboard | 09 Kiểm & bảo trì | Xem toàn cảnh workspace: kanban, coverage, funnel, tài liệu quá hạn. | Có tài liệu | docs/_shared/dashboard.html |
/kg | 09 Kiểm & bảo trì | Dựng bản đồ liên hệ giữa mọi thứ trong tài liệu. Hạ tầng cho /gap, /cr, /dashboard. | Có tài liệu | docs/_shared/kg/graph.json |
/delegate | 09 Kiểm & bảo trì | San tải quota sang CLI AI khác (Codex, Gemini). Không đụng vào tài liệu. | - | Không ghi file |
/reverse-doc | 10 Dựng lại từ cái đã có | Dựng lại bộ SRS từ đống tài liệu rời rạc: docx, pdf, xlsx, ảnh chụp màn hình. | Tài liệu nguồn | docs/_reverse/{feature}/ |
/code-to-srs | 10 Dựng lại từ cái đã có | Dựng lại bộ SRS từ chính source code. Cái code khẳng định thì gắn nhãn chắc. | Đường dẫn repo | docs/_reverse/{feature}/ |
/reverse-preview | 10 Dựng lại từ cái đã có | Xem bộ SRS vừa dựng lại, giữ nguyên nhãn độ tin cậy và phần Gap / Open Question. | /reverse-doc hoặc /code-to-srs | docs/_reverse/{feature}/{feature}-reverse-preview.html |
code-explorer | - Skill nền | Skill nền, không gọi bằng lệnh. Map codebase lạ rồi gom thành feature nghiệp vụ. | Được /code-to-srs nạp | - |
stacks-reference | - Skill nền | Skill nền. Recipe bóc route / model / guard theo từng stack: Next, Nest, Django, Spring… | Được /code-to-srs nạp | - |
Skill trùng vai - chỉ giữ một
Có khá nhiều skill làm gần như cùng một việc, chỉ khác nhau ở độ đẹp của hình vẽ và độ gần với dev. Cài cả họ về là cách nhanh nhất để đốt token một cách vô ích.
Mô hình dữ liệu
/erd vẽ bằng Mermaid nhúng thẳng vào file, gọn nhẹ nên mặc định cứ dùng cái này. /d2-erd cho ra hình đẹp hơn, hợp khi bạn cần đưa vào slide. Còn /dbdiagram là bản gần dev nhất, vì nó có kiểu dữ liệu thật của database và cả index.
Luồng xử lý
/activity vẽ bằng Mermaid, đủ dùng cho phần lớn trường hợp. /d2-activity nhìn đẹp hơn khi luồng có nhiều nhánh. /activity-swimlane chỉ cần đến khi bạn muốn lane thẳng cột thật sự. Còn /bpmn thì chỉ nên dùng nếu phải import vào Camunda.
Màn hình
Độ chi tiết tăng dần theo thứ tự /wireframe-ascii → /wireframe-html → /figma → /prototype-html → /prototype-next. Bạn dừng lại ở bậc nào là tuỳ vào việc cần đưa cho ai xem.
Tài liệu đầu nguồn
/urd, /brd và /prd-epic chỉ nên viết nếu công ty bạn yêu cầu. Nhiều team đi thẳng từ /brainstorm sang /srs mà vẫn không thiếu gì cả.
PRD hai cấp
/prd là PRD của cả sản phẩm, bạn chỉ chạy một lần ở đầu dự án. Còn /prd-epic là scope của riêng một feature. Tên gọi gần giống nhau nhưng chúng nằm ở hai tầng khác hẳn.
Dựng ngược
/reverse-doc đọc các tài liệu rời rạc, còn /code-to-srs đọc thẳng source code. Hai skill này cùng một đích đến và chỉ khác nhau ở nguồn, nên bạn chọn theo thứ đang có sẵn trong tay.