Khi nào dùng skill nào
BA-Kit là bộ skill cho Business Analyst chạy trên Claude Code, do ai4ba.com phát triển. Bộ 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.
- Tổng skill
- 57
- Gọi bằng lệnh
- 55
- Thường dùng
- 5–12
- Chạy trên
- Claude Code
BA-Kit là gì
Đ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:
- Bối cảnh — những tài liệu nào cần đọc trước khi bắt tay vào làm.
- Rule — những điều mà AI không được phép tự ý quyết định.
- Format đầu ra — file sinh ra trông như thế nào và được đặt ở đâu.
- Điểm hỏi lại — khi thiếu thông tin thì dừng lại hỏi bạn, thay vì đoán mò.
- Cổng duyệt — xin phép bạn trước khi ghi file, và kiểm lại một lượt trước khi đi tiếp.
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 đó.
Sáu thành phần
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.
Pipeline chính
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.
- 01bước xương sống
- Anhánh chỉ chạy khi cần
- /lệnhlệnh then chốt của bước
Sản phẩm — làm gì trước, làm gì sau
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/discoverLàm rõ — từ ý tưởng thô thành thứ có cấu trúc
Ở 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Đặc tả — chốt feature làm gì, luật ra sao
/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-epicDiễn đạt — sơ đồ và use case
Vớ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/bpmnMàn hình — từ nghiệp vụ ra giao diện
/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-htmlBàn giao — backlog cho dev, gói cho stakeholder
Đâ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/previewNhánh tích hợp API — khi phải nối hệ thống ngoài
Bả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-readinessNhánh kiểm thử
Bạ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-genChạy xen kẽ — kiểm và bảo trì
Nhó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/kgDự án cũ không có tài liệu — dựng ngược
Trườ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-previewKhi nào dùng cái gì
Bạ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 | /exporthoặc/preview |
Ba luồng thật của ba người thật
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-htmlkhá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ả.
Tra cứu 57 skill
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ó.
Hiển thị tất cả 57 skill
/prd01Sả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.
- Cần
Ý tưởng sản phẩm- Ra
docs/_product/prd.md
/roadmap01Sản phẩmXếp ưu tiên Feature Map thành Now / Next / Later hoặc chia theo quý.
- Cần
/prd- Ra
docs/_product/roadmap.md
/discover01Sản phẩmMột feature còn phân vân: điều tra nhu cầu + đối thủ rồi khuyến nghị build / skip.
- Cần
Feature Map (khuyến khích)- Ra
docs/_research/{date}-{slug}.md
/brainstorm02Là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.
- Cần
Một câu mô tả ý tưởng- Ra
docs/{feature}/brainstorms/{idea}.md
/meet02Làm rõCó transcript hoặc ghi chú họp, cần biến thành biên bản có decision / action / RAID.
- Cần
Transcript hoặc note thô- Ra
docs/meetings/{date}-{type}-{slug}.md
/urd03Đặ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.
- Cần
/brainstorm- Ra
docs/{feature}/{feature}-urd.md
/brd03Đặc tảGhi lý do kinh doanh, mục tiêu SMART, ROI, stakeholder, rủi ro.
- Cần
/brainstorm hoặc /urd- Ra
docs/{feature}/{feature}-brd.md
/prd-epic03Đặc tảChốt phạm vi một feature: capability P0/P1/P2, luồng chính, kế hoạch release.
- Cần
/urd hoặc /brd- Ra
docs/{feature}/{feature}-prd.md
/srs03Đặc tảTài liệu lõi. Kỹ thuật hoá scope thành FR / NFR / Business Rule / bảng mã lỗi.
- Cần
/prd-epic (mềm)- Ra
docs/{feature}/srs/{feature}-spec.md
/update-overview03Đặ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ần
Có ít nhất một feature- Ra
docs/_shared/
/sequence04Sơ đồVẽ trình tự trao đổi giữa các hệ thống trong một luồng (login, checkout, webhook).
- Cần
/srs- Ra
docs/{feature}/srs/{feature}-flows.md
/activity04Sơ đồVẽ luồng xử lý có nhiều nhánh quyết định, bằng Mermaid nhúng thẳng vào file.
- Cần
/srs- Ra
docs/{feature}/srs/{feature}-flows.md
/activity-swimlane04Sơ đồQuy trình đa vai trò cần lane thẳng cột thật — PlantUML, không phải subgraph giả.
- Cần
/srs hoặc /usecase- Ra
docs/{feature}/srs/{feature}-{slug}-swimlane.puml
/bpmn04Sơ đồCần BPMN 2.0 chuẩn OMG để import Camunda / Bizagi (approval, onboarding, refund).
- Cần
/usecase hoặc /srs- Ra
docs/{feature}/bpmn/{process}.bpmn
/state04Sơ đồMột đối tượng có nhiều trạng thái và chuyển đổi (Account, Order, Subscription).
- Cần
/srs- Ra
docs/{feature}/srs/{feature}-states.md
/erd04Sơ đồMô hình dữ liệu nghiệp vụ, Mermaid nhúng inline. Bản gốc của họ ERD.
- Cần
/srs- Ra
docs/{feature}/srs/{feature}-erd.md
/d2-erd04Sơ đồCùng ERD nhưng vẽ đẹp bằng D2, file ảnh riêng để đưa vào slide.
- Cần
/erd- Ra
docs/{feature}/d2-erd/{feature}.d2
/d2-activity04Sơ đồActivity nhiều nhánh mà Mermaid dàn xấu — D2 layout ELK gọn hơn.
- Cần
/srs- Ra
docs/{feature}/d2/{slug}.d2
/d2-architect04Sơ đồSơ đồ kiến trúc hệ thống: component, service, DB lồng nhau.
- Cần
/srs- Ra
docs/{feature}/d2-architect/{slug}.d2
/dbdiagram04Sơ đồTầng gần dev nhất: schema DBML với kiểu DB thật, enum, index.
- Cần
/erd- Ra
docs/{feature}/dbdiagram/{feature}.dbml
/usecase-diagram04Sơ đồSơ đồ tổng quan actor và use case để chốt phạm vi bằng hình.
- Cần
/usecase- Ra
docs/{feature}/usecases/{feature}-usecase-diagram.svg
/user-flow05Màn hìnhChạy đầu tiên trong nhóm màn hình. Chia feature thành các flow, phủ happy / error / edge.
- Cần
/srs- Ra
docs/{feature}/srs/{feature}-userflow.md
/wireframe-ascii05Màn hìnhPhác màn bằng ký tự, gộp theo flow, kèm bảng mô tả 5 cột dùng chung.
- Cần
/user-flow- Ra
docs/{feature}/ascii-wireframe/{flow}.md
/wireframe-html05Màn hìnhCùng màn đó nhưng render element HTML thật, đen trắng, mở bằng trình duyệt.
- Cần
/user-flow- Ra
docs/{feature}/html-wireframe/{flow}.html
/figma05Màn hìnhVẽ thật lên Figma qua MCP, tuân design token. Cần cài Reqwise Figma MCP.
- Cần
/wireframe-ascii- Ra
File trên Figma
/prototype-html05Màn hìnhBậc cao nhất: một file HTML bấm được như app thật, giữ state, có lớp góp ý.
- Cần
/user-flow + /wireframe-ascii- Ra
docs/{feature}/html-design/{feature}-prototype.html
/prototype-next05Màn hìnhPrototype chạy được bằng Next.js, sinh code thật, tự build và smoke test.
- Cần
/user-flow + /usecase- Ra
prototype/
/usecase06Backlog & bàn giaoViết use case chuẩn Cockburn: actor, tiền đề, luồng chính, nhánh mở rộng.
- Cần
/srs (hoặc chạy chế độ khám phá)- Ra
docs/{feature}/usecases/uc-{slug}.md
/userstory06Backlog & bàn giaoBóc FR / use case / màn hình thành user story đưa vào backlog.
- Cần
/srs- Ra
docs/{feature}/userstories/us-{NNN}.md
/ac06Backlog & bàn giaoViết, sửa hoặc soi lại Acceptance Criteria dạng Given / When / Then.
- Cần
/userstory- Ra
Ghi thẳng vào us-{NNN}.md
/jira06Backlog & bàn giaoĐồng bộ hai chiều backlog với Jira Cloud. Không cờ = chỉ xem drift, an toàn.
- Cần
/userstory + Atlassian MCP- Ra
Jira + docs/_shared/jira-map.md
/confluence06Backlog & bàn giaoĐồng bộ hai chiều tài liệu với Confluence Cloud.
- Cần
Tài liệu + Atlassian MCP- Ra
Confluence page
/export06Backlog & bàn giaoĐóng gói tài liệu một feature gửi stakeholder: PDF, DOCX hoặc HTML.
- Cần
Tài liệu đã duyệt- Ra
docs/exports/{date}-{slug}-package.pdf
/userguide06Backlog & bàn giaoViết cẩm nang vận hành cho admin / CSKH, có thể tự chụp ảnh màn hình thật.
- Cần
Tài liệu feature- Ra
docs/userguide/{feature}-userguide.html
/preview06Backlog & bàn giaoGộp mọi file Markdown của một feature thành một trang HTML xem được.
- Cần
Có tài liệu- Ra
docs/{feature}/{feature}-preview.html
/api-assess07Tích hợp APIChư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ị.
- Cần
Nhu cầu tích hợp- Ra
docs/{feature}/integration/api-assess.md
/api-doc07Tích hợp APIĐọc hiểu tài liệu API đối tác (OpenAPI / PDF / URL) thành doc nghiệp vụ.
- Cần
Tài liệu API của đối tác- Ra
docs/{feature}/integration/api-summary.md
/api-design07Tích hợp APIBướ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.
- Cần
/api-doc + /srs- Ra
docs/{feature}/integration/api-design.md
/api-map07Tích hợp APIBảng ánh xạ field ba tầng: API ↔ entity hệ thống ↔ field trên UI.
- Cần
/api-design- Ra
docs/{feature}/integration/api-map.md
/api-checklist07Tích hợp APIPhỏng vấn discovery để ra outline kịch bản cần test, chưa cần data chi tiết.
- Cần
/api-design- Ra
docs/{feature}/test/api/api-checklist.md
/api-test07Tích hợp APIBiến checklist thành file .bru chạy được bằng Bruno. Secret chỉ nằm trong .env.
- Cần
/api-checklist- Ra
docs/{feature}/test/api/bruno/
/api-readiness07Tích hợp APICổng go-live: cutover, feature flag, monitoring, rollback, bảng go / no-go.
- Cần
/api-test- Ra
docs/{feature}/integration/api-readiness.md
/test-checklist08Kiểm thửOutline kịch bản cần test để review trước, chưa viết test case đầy đủ.
- Cần
/srs + /userstory- Ra
docs/{feature}/test/checklist/
/test-cases08Kiểm thửSinh test case chi tiết 1:1 từ checklist. Bắt buộc có checklist trước.
- Cần
/test-checklist- Ra
docs/{feature}/test/testcases/
/playwright-gen08Kiểm thửCodegen script Playwright .spec.ts chạy được từ test case UI.
- Cần
/test-cases- Ra
docs/{feature}/test/e2e/
/gap09Kiể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.
- Cần
Tài liệu feature- Ra
docs/_shared/traceability.md
/ask09Kiể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.
- Cần
Tài liệu feature- Ra
Không ghi file
/doc-drift09Kiể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ì.
- Cần
Tài liệu + đường dẫn source code- Ra
docs/reports/doc-drift/
/cr09Kiể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.
- Cần
Tài liệu đã duyệt- Ra
docs/cr/CR-{id}.md
/dashboard09Kiểm & bảo trìXem toàn cảnh workspace: kanban, coverage, funnel, tài liệu quá hạn.
- Cần
Có tài liệu- Ra
docs/_shared/dashboard.html
/kg09Kiể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ần
Có tài liệu- Ra
docs/_shared/kg/graph.json
/delegate09Kiểm & bảo trìSan tải quota sang CLI AI khác (Codex, Gemini). Không đụng vào tài liệu.
- Cần
—- Ra
Không ghi file
/reverse-doc10Dự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.
- Cần
Tài liệu nguồn- Ra
docs/_reverse/{feature}/
/code-to-srs10Dự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.
- Cần
Đường dẫn repo- Ra
docs/_reverse/{feature}/
/reverse-preview10Dự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.
- Cần
/reverse-doc hoặc /code-to-srs- Ra
docs/_reverse/{feature}/{feature}-reverse-preview.html
code-explorer—Skill nềnSkill nền, không gọi bằng lệnh. Map codebase lạ rồi gom thành feature nghiệp vụ.
- Cần
Được /code-to-srs nạp- Ra
—
stacks-reference—Skill nềnSkill nền. Recipe bóc route / model / guard theo từng stack: Next, Nest, Django, Spring…
- Cần
Được /code-to-srs nạp- Ra
—
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.
Cạm bẫy
Đây là bốn thứ khiến người mới mất thời gian nhiều nhất.
- 01
Đừ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.
- 02
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.
- 03
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.
- 04
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à
/gapthì 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.
Bắt đầu với năm skill
Đừng cài cả bộ. Luồng dưới đây là cách ghép gọn nhất cho một BA làm dự án nội bộ — đủ đi từ ý tưởng tới backlog, và bạn thêm skill khác khi thật sự cần.
/brainstorm/srs/user-flow/wireframe-html/userstory