Hướng dẫn nội bộ · dành cho BA mới vào bộ kit
BA-Kit có tất cả 57 skill, nhưng bạn sẽ không dùng hết đâu — trên thực tế, mỗi người chỉ dùng đều đặn khoảng 5 đến 12 cái. Trang này giúp bạn tìm ra đúng nhóm hợp với công việc của mình, và hiểu chúng nối vào nhau như thế nào.
TAKHAI
Điểm khác biệt nằm ở chỗ một skill không chỉ là câu lệnh mà bạn gõ ra.
Một prompt chỉ là một lần bạn nhờ AI làm việc, xong là thôi. Còn một skill là cách bạn biến một việc lặp đi lặp lại thành quy trình dùng lại được nhiều lần.
Lấy ví dụ lúc bạn cần viết acceptance criteria. Một prompt ngắn thì chỉ bảo AI viết ra Given / When / Then là hết. Còn skill /ac thì biết thêm nhiều thứ khác: nó đang xử lý story nào, phải đọc SRS và business rule ở đâu, màn hình nào có liên quan, tách happy path với error case ra sao. Và quan trọng nhất, chỗ nào tài liệu chưa nói rõ thì nó ghi lại thành Open Question chứ không tự điền bừa.
Nói gọn lại, mỗi skill mang theo năm thứ sau đây:
Thứ đáng tiền nhất chính là cái thứ tư. Một AI chịu dừng lại để nói “chỗ này tài liệu chưa có, anh xác nhận giúp em” thì hữu ích hơn rất nhiều so với một AI viết trơn tru nhưng bịa mất một business rule quan trọng. Bạn cứ mở bất kỳ file SRS nào do /srs sinh ra rồi kéo xuống mục Open Questions, sẽ thấy ngay điều đó.
Bạn hãy hình dung một nhóm làm dự án nhỏ, trong đó mỗi thành phần đảm nhận một vai trò riêng.
| Thành phần | Là ai trong nhóm | Nằm ở đâu |
|---|---|---|
Skill | Bản quy trình cho một việc cụ thể | .claude/skills/<tên>/SKILL.md |
Agent | Người chuyên soi một góc nhìn khi review | .claude/agents/<tên>.md |
Rule | Nội quy ai cũng phải giữ, mọi lúc | .claude/rules/<tên>.md |
Hook | Việc tự chạy khi có sự kiện, không cần gọi | .claude/hooks/<tên>.sh |
Template | Khung file mẫu để skill điền nội dung vào | _templates/ |
docs/ | Nơi skill ghi ra — tài liệu thật của dự án | docs/{feature}/ |
Chỉ cần nhớ một câu này: .claude/ là nơi skill sống, nên bạn sửa ở đây mỗi khi muốn đổi cách làm việc. Còn docs/ là nơi skill ghi kết quả ra, và đó mới là sản phẩm bạn đem đi bàn giao.
Có sáu bước làm xương sống, cộng thêm bốn nhánh chỉ chạy khi bạn cần đến. Các bước được đánh số vì đây thật sự là một thứ tự, chứ không phải để cho đẹp: bước sau đọc lại chính những file mà bước trước đã sinh ra.
Nhóm này chỉ chạy một lần ở đầu dự án, lúc bạn còn phải quyết định làm gì trước làm gì sau. Nếu bạn đã được giao thẳng một feature cụ thể rồi thì cứ bỏ qua cả ba.
/prd/roadmap/discoverỞ bước này, AI sẽ phỏng vấn ngược lại bạn để đào cho rõ ý tưởng. Đây chính là chỗ nên chốt phạm vi, trước khi bạn bỏ công viết tài liệu.
/brainstorm/meet/srs là file trung tâm của cả bộ, bởi gần như mọi bước phía sau đều đọc lại từ nó. Còn /urd, /brd và /prd-epic thì chỉ nên viết khi công ty bạn thật sự yêu cầu.
/srs/urd/brd/prd-epicVới mỗi mục đích, bạn chỉ nên chọn đúng một loại sơ đồ. Đừng vẽ cả bốn kiểu cho cùng một nội dung, vì sau này sửa một chỗ là phải sửa lại cả bốn.
/usecase/sequence/activity/state/erd/bpmn/user-flow bắt buộc phải chạy đầu tiên, vì nó là nguồn chia flow dùng chung mà mọi skill wireframe phía sau đều đọc lại. Những skill còn lại xếp theo độ chi tiết tăng dần từ trái sang phải, và bạn dừng ở đâu là tuỳ vào việc cần đưa cho ai xem.
/user-flow/wireframe-ascii/wireframe-html/figma/prototype-htmlĐây là điểm kết của cả chuỗi. Nhưng bạn nhớ giúp rằng một story chưa có AC được xác nhận thì vẫn chưa đủ để dev nhận việc.
/userstory/ac/jira/export/previewBảy skill trong nhánh này chạy theo một thứ tự cố định, không đảo được. Nếu API là của chính dự án bạn chứ không phải của đối tác, bạn có thể bỏ qua hai bước đầu.
/api-assess/api-doc/api-design/api-map/api-checklist/api-test/api-readinessBạn bắt buộc phải có checklist trước rồi mới sinh được test case. Thứ tự này cố ý như vậy, để bạn kịp review kịch bản trước khi tốn công viết chi tiết từng ca.
/test-checklist/test-cases/playwright-genNhóm này không có chỗ cố định nào trong chuỗi. Bạn gọi chúng bất cứ lúc nào cần soi lại hoặc sửa tài liệu đã viết xong.
/gap/ask/cr/doc-drift/dashboard/kgTrường hợp này bạn vào chuỗi từ giữa: dựng lại bộ SRS từ những nguồn đang có trong tay, rồi chuyển sang /srs để hình thức hoá lại cho chuẩn.
/reverse-doc/code-to-srs/reverse-previewBạn tra theo tình huống mình đang đứng, chứ không phải theo tên skill.
| Bạn đang có | Bạn cần | Chạy |
|---|---|---|
| Một câu mô tả ý tưởng | Làm rõ thành thứ viết được | /brainstorm |
| Ý tưởng đã rõ | Đặc tả cho dev đọc | /srs |
| Bản ghi cuộc họp | Biên bản có decision và action | /meet |
| SRS đã duyệt | Chia màn hình để vẽ | /user-flow |
| Đã có user flow | Bản bấm được cho khách xem | /prototype-html |
| SRS đã duyệt | Backlog đưa dev | /userstory → /ac |
| Story đã có | Đẩy lên Jira | /jira |
| Tài liệu API đối tác | Hiểu và thiết kế tích hợp | /api-doc → /api-design |
| Feature đã viết xong | Soi còn thiếu luồng gì | /gap |
| Tài liệu người khác viết | Hiểu nghiệp vụ đang chạy thế nào | /ask |
| Yêu cầu thay đổi | Sửa tài liệu đã duyệt, có kiểm tác động | /cr |
| Code cũ, không tài liệu | Dựng lại SRS | /code-to-srs |
| Đống docx / pdf rời rạc | Gom thành bộ SRS chuẩn | /reverse-doc |
| Tài liệu đã xong | Gửi stakeholder | /export hoặc /preview |
Vẫn là một bộ skill đó, nhưng có tới ba cách ghép khác nhau, và cả ba đều đúng với hoàn cảnh của người dùng nó. Bạn để ý giúp một điều: không luồng nào dùng quá bảy skill.
/brainstorm→/srs→/user-flow→/wireframe-html→/userstory→/jiraMột BA làm dự án nội bộ. Công ty họ không yêu cầu URD, BRD hay PRD, nên cả ba đều được bỏ hẳn.
/prd→/roadmap→/brainstorm→/prd-epic→/srs→/userstoryMột Product Owner. Họ định hình cả sản phẩm trước, chia thành từng đợt, rồi mới đào sâu vào từng feature một.
/brainstorm→/user-flow→/prototype-html→khách duyệt→/srs→/userstoryMột BA làm dự án cho khách hàng. Họ dựng bản bấm được đưa khách chốt trước, rồi mới quay lại viết đặc tả.
Bạn gõ từ khoá để lọc, hoặc bấm vào một nhóm bất kỳ. Cột “cần gì trước” cho bạn biết skill sẽ đòi hỏi những gì ngay khi bạn gọi nó.
| 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/don-userflow | 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/don-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/don-wireframe | 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/don-prototype | 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 | — |
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.
/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.
/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.
Độ 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.
/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 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.
/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.
Workspace này chỉ cài nhánh màn hình, đặt tên với tiền tố don- để không lẫn với skill gốc.
| Lệnh ở đây | Skill gốc | Vai trò |
|---|---|---|
/don-userflow | user-flow | Chia flow, phủ happy / error / edge — chạy đầu tiên |
/don-wireframe-ascii | wireframe-ascii | Phác màn bằng ký tự, kèm bảng mô tả 5 cột |
/don-wireframe | wireframe-html | Wireframe HTML đen trắng, mở bằng trình duyệt |
/don-prototype | prototype-html | Prototype bấm được như app thật, có lớp góp ý |
/don-userflow→/don-wireframe-ascii→/don-wireframe→/don-prototypeCó ba chỗ đã được sửa so với bản gốc để bốn skill này chạy độc lập được. Thứ nhất, tên lệnh gọi chéo giữa chúng đã đổi sang tiền tố don-. Thứ hai, tham chiếu tới /figma được hạ xuống thành ghi chú, vì skill đó không nằm trong nhóm được cài. Thứ ba, bước truy vấn Knowledge Graph được thay bằng quét trực tiếp, cũng vì /kg không được cài.
Dù vậy, chúng vẫn cần thư mục docs/{feature}/ có sẵn tài liệu nghiệp vụ để đọc. Nếu bạn chưa có docs/design.md thì /don-prototype sẽ tự dùng bộ màu trung tính và báo lại cho bạn biết.
Bạn theo dõi một feature giả định đi hết bảy bước, để thấy rõ file bước sau đọc lại đúng những gì bước trước ghi ra. Đây là dữ liệu minh hoạ, không phải log chạy thật.
Giả sử phòng khám muốn bỏ việc ghi lịch bằng sổ tay. Ta gọi tính năng này là "Đặt lịch khám online" và chạy nó qua đúng bảy skill dưới đây — ba skill đầu là hàng chuỗi chính, bốn skill sau là nhánh màn hình đã cài trong workspace này (mục 07).
/brainstorm — làm rõ ý tưởng thôĐầu vào chỉ là một câu than phiền của lễ tân. AI phỏng vấn ngược để ép ra phạm vi và câu hỏi còn treo, thay vì tự đoán giúp.
## Vấn đề Lễ tân ghi lịch khám bằng sổ tay → trùng giờ bác sĩ trung bình 3 lần/tuần. ## Phạm vi đề xuất - Bệnh nhân tự chọn khung giờ trống theo bác sĩ - Lễ tân duyệt / từ chối trong 15 phút - Nhắc lịch qua SMS trước 1 giờ ## Open Question - Có cho đổi lịch sau khi đã duyệt không? — chưa có trong tài liệu gốc.
/srs — kỹ thuật hoá thành FR / NFR / ruleOpen Question ở bước 1 chưa được trả lời nên vẫn giữ nguyên, không bị AI tự điền thành "có" hay "không".
FR-03 Bệnh nhân chọn bác sĩ + khung giờ trống, không chọn được giờ đã đầy. FR-07 Lễ tân duyệt / từ chối trong 15 phút, quá hạn tự huỷ yêu cầu. NFR-02 Danh sách giờ trống phải tải dưới 800ms ở mạng 3G. BR-04 Một bệnh nhân chỉ giữ tối đa 1 lịch "chờ duyệt" cùng lúc. ERR-12 SLOT_TAKEN — khung giờ vừa bị người khác giữ trước.
/don-userflow — chia thành flow, phủ cả nhánh lỗiSkill này đọc lại đúng FR-03, FR-07 và ERR-12 ở trên để tách ra ba flow — không vẽ tràn lan ngoài phạm vi SRS.
Flow 1 · Happy — Chọn bác sĩ → chọn giờ trống → xác nhận → chờ duyệt Flow 2 · Error — Giờ vừa chọn bị người khác giữ trước (ERR-12 · SLOT_TAKEN) Flow 3 · Edge — Bệnh nhân huỷ lịch trước giờ hẹn 1 giờ
/don-wireframe-ascii — phác màn bằng ký tựVẫn Flow 1 ở trên, giờ được vẽ thành từng màn hình cụ thể, kèm bảng mô tả 5 cột (không hiện ở đây cho gọn).
+----------------------------------+ | < Đặt lịch khám Bước 2/3 | +----------------------------------+ | Bác sĩ: Nguyễn Thị H · Nội tổng | | Chọn ngày: [ 12 ][ 13 ][ 14 ] | | Khung giờ còn trống: | | 09:00 09:30 [10:00] 10:30 | +----------------------------------+ | [ Xác nhận ] | +----------------------------------+
/don-wireframe — render thành HTML thật, đen trắngCùng màn đó, giờ là element HTML mở được bằng trình duyệt — chưa có màu, chỉ để xem đúng bố cục và trạng thái nút.
<section class="slot-picker"> <h2>Chọn khung giờ trống</h2> <button data-t="09:00">09:00</button> <button data-t="10:00" aria-pressed="true">10:00</button> <button data-t="10:30" disabled>10:30 · đã đầy</button> </section>
/don-prototype — bấm được như app thậtBấm "10:00" thì nút chuyển trạng thái đã chọn và nhớ lại khi quay về bước trước — có lớp góp ý riêng để khách hàng comment thẳng lên từng màn.
state.slot = "10:00" // giữ khi back/forward giữa 3 bước onConfirm() → nếu slot bị SLOT_TAKEN → quay lại Flow 2 (mục 03)
/userstory + /ac — gói lại thành backlogBốn nguồn ở trên — FR, flow, wireframe, prototype — gộp lại thành một story có AC dạng Given / When / Then, sẵn sàng đưa dev.
US-014 — Là bệnh nhân, tôi muốn chọn khung giờ trống để đặt lịch khám
nhanh mà không cần gọi điện.
AC1 Given khung giờ đang trống, When bệnh nhân xác nhận,
Then trạng thái chuyển "Chờ lễ tân duyệt" và gửi SMS xác nhận.
AC2 Given khung giờ vừa bị giữ bởi người khác, When bệnh nhân xác nhận,
Then hệ thống báo lỗi SLOT_TAKEN và làm mới danh sách giờ trống.Vì sao đáng để ý: Open Question ở bước 01 không tự biến mất — nó theo cho tới tận SRS. Và ERR-12 sinh ra ở bước 02 xuất hiện lại nguyên vẹn ở cả flow, wireframe lẫn AC. Đó chính là "bước sau đọc lại file bước trước" nói ở mục 03, chứ không phải khẩu hiệu suông.
Đây là bốn thứ khiến người mới mất thời gian nhiều nhất.
1 · Đừng cài cả 57 skill. Mỗi lần bạn mở một phiên chat mới, mô tả của mọi skill đã cài đều được nạp vào để AI biết mình có những gì mà dùng. Cho nên nếu cài 30 skill mà chỉ dùng tới 8, nghĩa là bạn đang trả tiền cho 22 mô tả thừa, ở mọi phiên và suốt cả dự án. Tốt nhất bạn chỉ chọn khoảng 5 đến 12 cái thật sự khớp với công việc của mình.
2 · Copy skill thì phải copy cả những thứ nó cần. Một skill thường phụ thuộc vào vài rule, đôi khi thêm một agent, một template hoặc một script nữa. Nếu bạn copy thiếu, skill sẽ gãy giữa chừng, mà thường lại rơi đúng vào lúc nó đang ghi file dở dang.
3 · Cổng duyệt là tính năng, chứ không phải phiền toái. Skill sẽ dừng lại ở ba mức: cho bạn xem trước danh sách file sắp ghi, cho xem diff trước khi sửa một file đã có, và lặp lại tối đa ba vòng với những thứ mang tính sáng tạo như wireframe. Bạn nên đọc kỹ trước khi bấm đồng ý, bởi đây chính là chỗ bắt lỗi rẻ nhất trong cả quy trình.
4 · Input mơ hồ thì output cũng mơ hồ theo. Một rule chưa được ghi ở đâu cả thì AI hoàn toàn có thể điền vào bằng một giả định nghe rất hợp lý. Một sơ đồ đúng cú pháp vẫn có thể thiếu mất nhánh nghiệp vụ. Và /gap thì chỉ gợi ý những chỗ đáng nghi chứ không xác nhận được sự thật. Bộ kit này giúp bạn giảm việc lặp lại, nhưng nó không thay được quyền phán đoán của bạn.
BA-Kit chính chủ tại ai4ba.com — nhập mã TAKHAI nếu trang đang có ưu đãi.