sys-analysis-design/.claude/skills/ba-lifecycle/SKILL.md

name, description

name

description

ba-lifecycle

Điều phối công việc BA — khai báo project profile (loại sản phẩm × nền cũ/mới × mức nghiêm ngặt), xác định dự án đang ở giai đoạn nào, artifact nào đã có, gate nào đang chặn, và skill nào nên chạy tiếp. Dùng khi người dùng nói "bắt đầu làm BA", "tôi đang ở đâu", "quy trình BA thế nào", "cần làm gì tiếp", "review toàn bộ tài liệu BA", "dự án này thuộc loại nào", hoặc khi họ mô tả một việc BA mà chưa rõ thuộc giai đoạn nào. Cũng dùng để khởi tạo cấu trúc thư mục ba-output và file PROFILE cho một dự án mới.

BA Lifecycle — Router điều phối

Skill này không tự viết artifact nghiệp vụ. Việc của nó: đọc hiện trạng, chấm gate, rồi chỉ đúng skill giai đoạn để chạy. Viết tài liệu là việc của ba-1..5.

Bốn nguyên tắc bất di bất dịch

Áp dụng cho skill này và mọi skill ba-* khác. Khi một quy tắc chặn bạn, dừng và hỏi, đừng lách.

1. Không bịa yêu cầu. Thiếu thông tin ⇒ ghi OQ-nnn, không điền giá trị "hợp lý".
2. Không quyết định thay PO. Ưu tiên/scope/trade-off nghiệp vụ ⇒ trình phương án kèm khuyến nghị, để PO chốt.
3. Mọi phát biểu phải truy vết được về một RQ/BR/DEC/câu trả lời của stakeholder. Không nguồn ⇒ là giả định ⇒ phải ghi ASM-nn.
4. Không ghi đè tài liệu đã qua gate. Chỉ sửa qua CR-nnn kèm Change Log.

Bước 0 — Chốt input rồi dừng lại

Chưa được ghi file. Làm năm việc rồi dừng chờ người dùng trả lời:

1. Project và phạm vi — tên project, phạm vi đang hỏi (cả module hay một US).
2. Profile — đọc 00-index/PROFILE_<PROJECT>.md. Chưa có ⇒ suy ra ba trục PRODUCT · LIFECYCLE · RIGOR từ tài liệu hiện có, nêu rõ là suy đoán kèm lý do, rồi hỏi xác nhận. Chưa xác nhận thì mọi phép chấm gate ở Bước 2 dùng mặc định standard — nói rõ điều đó, đừng chấm im lặng.
3. Thư mục output — xác nhận ba-output/<PROJECT>/. Nếu đã tồn tại thư mục BA khác trong repo (.docs/output/, docs/ba/…), nêu ra và hỏi dùng cái nào. Không tự tạo cấu trúc song song với cái đã có.
4. Input đã tìm thấy — bảng File | Vai trò | Giai đoạn | Ngày sửa.
5. Hỏi xác nhận bốn điểm trên.

Bỏ qua bước dừng khi lệnh có chữ go / chạy luôn.

Quy tắc bắt buộc đã nạp

Đọc trước khi làm bất cứ việc gì:

• references/domain-profiles.md — ba trục PRODUCT × LIFECYCLE × RIGOR và hệ quả
• references/workflow.md — định nghĩa 5 gate, tiêu chí pass theo từng mức, người duyệt
• references/artifact-map.md — artifact nào thuộc giai đoạn nào, tên file, version
• references/writing-rules.md — 13 quy tắc viết tài liệu BA

Thực hiện

Bước 1 — Quét hiện trạng

find ba-output/<PROJECT> -name "*.md" -newermt "1970-01-01" | sort

Với mỗi file tìm được, đọc header (Version · Date · Status · Author) — không đọc toàn văn ở bước này. Phân loại theo references/artifact-map.md.

Không tìm thấy gì ⇒ project chưa khởi tạo, nhảy tới Bước 4 (khởi tạo).

Bước 2 — Chấm từng gate

Với mỗi gate G1→G5, chấm theo checklist trong references/workflow.md §2, đã điều chỉnh theo RIGOR trong profile: light áp checklist trừ bảng "Bớt ở light", strict cộng bảng "Thêm ở strict". Ghi mức đang chấm ngay đầu bảng pipeline.

Chấm thật: mở artifact và kiểm tra mục bắt buộc có nội dung hay chỉ là khung rỗng. Một file tồn tại nhưng các mục còn TBD ⇒ chưa đạt, không được đánh ✅.

Tiêu chí phụ thuộc PRODUCT: dòng "bảng field" và bốn dòng (screen) của G3 (UICONV tồn tại và có chữ ký Designer · WF phủ mọi SCR, C-id khớp hai chiều · WF §5 không còn lệch Tồn tại/Hành vi chưa quyết · WF ✏️ có Designer ký) chỉ áp cho PRODUCT = screen. Loại khác dùng tiêu chí ghi ở đầu file ba-3-specification/templates/srs-part2/<loại>.md. Khi chấm G3 cho screen, mở cả 00-index/UICONV_*.md và 03-specification/WF_*.md; ba dòng (screen · design) đọc 00-index/DS_*.md, 03-specification/design/DSPEC_*.md (§6 có kết quả design-check) và kiểm HIFI_*.html, FIGMA_*/ tồn tại. Chạy được node .claude/skills/ba-design/scripts/design-check.mjs … thì chép kết quả thật; không chạy được ⇒ ghi "chưa kiểm bằng máy", không đoán ✅.

Ba trạng thái, không có trạng thái thứ tư:

Ký hiệu	Nghĩa
✅	Đủ artifact, đủ nội dung, đã có chữ ký duyệt ghi trong header
🟠	Có artifact nhưng thiếu nội dung hoặc chưa duyệt — nêu đích danh thiếu gì
☐	Chưa bắt đầu

Bước 3 — Tìm cái đang chặn

Gate thấp nhất chưa ✅ chính là chỗ đang đứng. Liệt kê:

• Blocker cứng — artifact thiếu, gate chưa duyệt
• Blocker mềm — OQ-nnn chưa trả lời, CR-nnn chưa quyết, RISK-nn chưa có phương án

Quét open question tồn đọng trên toàn bộ artifact:

grep -rn "OQ-[0-9]\|TBD\|TODO\|❓" ba-output/<PROJECT> | head -50

OQ quá 5 ngày làm việc chưa trả lời ⇒ đánh dấu quá hạn và nêu tên người phải trả lời.

Bước 4 — Khởi tạo project mới (chỉ khi Bước 1 không thấy gì)

Tạo cấu trúc rỗng và hai file:

1. 00-index/PROFILE_<PROJECT>.md — theo mẫu references/domain-profiles.md §0, với ba trục đã được người dùng xác nhận ở Bước 0, kèm cột "Hệ quả đã áp dụng".
2. 00-index/INDEX_<PROJECT>.md — theo mẫu references/artifact-map.md §4.

Không tạo file rỗng cho các giai đoạn sau — file rỗng làm hỏng phép chấm gate ở Bước 2.

ba-output/<PROJECT>/{00-index,01-discovery,02-analysis,03-specification,04-delivery,05-post-release}

Bước 5 — Báo cáo và chỉ đường

In đúng bốn phần sau, không thêm:

① Bảng pipeline — mở đầu bằng một dòng profile, để người đọc biết đang chấm theo chuẩn nào:

Profile: screen · brownfield · standard   (từ PROFILE_<PROJECT>.md)

Profile là suy đoán chưa xác nhận ⇒ ghi (suy đoán — chưa xác nhận).

Gate	Giai đoạn	Artifact	Trạng thái	Thiếu gì

② Đang đứng ở đâu — một câu. Ví dụ: "US059 đã qua G2, SRS đang draft v0.3, chặn ở G3 vì thiếu bảng mã lỗi và 3 OQ chưa trả lời."

③ Việc tiếp theo — tối đa 3 việc, mỗi việc kèm skill để chạy:

1. Trả lời OQ-012, OQ-013 (chờ PO)          → /ba-4-delivery-support US059
2. Bổ sung bảng mã lỗi vào SRS §1.A.4       → /ba-3-specification US059
3. Chạy kiểm tra coverage trước khi trình G3 → /ba-traceability US059
4. (screen) Sinh DS/HIFI/FIGMA sau khi WF xong      → /ba-design US059 hifi

④ Cảnh báo — OQ quá hạn, artifact lệch version, US có trong backlog nhưng chưa có SRS, SRS tham chiếu BR không tồn tại, artifact khai profile khác với PROFILE_<PROJECT>.md. Không có gì thì ghi "Không có".

🔴 Cảnh báo riêng cần chủ động nêu: project khai RIGOR = light nhưng đã có người dùng thật ngoài nhóm làm ⇒ đề xuất nâng lên standard và chạy bù G1–G3 (references/workflow.md §2 — G5). POC mang theo mọi thiếu sót của nó vào sản phẩm thật là chuyện xảy ra thường xuyên.

Bẫy thường gặp

Đừng suy ra trạng thái từ tên file. SRS_US059_v1.0.md tồn tại không có nghĩa G3 đã qua — phải mở ra xem Status trong header và checklist gate.

Đừng gộp nhiều project vào một lần chạy. Mỗi lần chạy đúng một <PROJECT>. Người dùng hỏi về nhiều module ⇒ chạy lần lượt, báo cáo riêng.

Đừng nhảy cóc gate. Người dùng đòi viết SRS khi G2 chưa xong ⇒ nói rõ rủi ro (SRS sẽ phải viết lại khi backlog đổi), nêu phần nào của G2 còn thiếu, rồi vẫn làm nếu họ khẳng định lại — và ghi ngoại lệ đó vào Open Questions của SRS.

Đừng tự sửa artifact. Thấy lỗi trong SRS ⇒ báo cáo ở phần ④, không sửa. Sửa là việc của skill giai đoạn tương ứng.