Brian
cf54f4d76d
* refactor(bmm): move sprint-planning and sprint-status to plan/ They sit at the plan/ship boundary and their outputs are planning artifacts of the dev cycle; next commit makes sprint-planning the readiness gate, which is plan-side work. * refactor(bmm): fold readiness gate into sprint-planning, retire check-implementation-readiness The old skill was 1,154 lines of legacy numbered-step ceremony whose document discovery hardcoded filename globs (*prd*, *ux*, *epic*) that miss what current skills produce (SPEC.md, DESIGN.md) and still treated retired sharded docs as first-class. Sprint-planning now opens with a lean readiness gate: generic artifact discovery by content, forward/back traceability, PASS/CONCERNS/FAIL, stop on FAIL with findings. The IR trigger on John's and Winston's menus dispatches sprint-planning, so 'check implementation readiness' still works everywhere it used to. * refactor(bmm): modernize sprint-planning with deterministic script core SKILL.md drops the legacy XML step dialect for the product-brief style (~100 lines, uv run, headless contract). New scripts/sprint_plan.py owns the mechanical work — epic parsing, key derivation, ordering, preserve- never-downgrade merge, story-file detection, action_items carry-over, atomic writes, drift checks — with 11 tests wired in as test:sprint-planning. Judgment stays with the LLM: epic discovery, the readiness gate, and reconciling script-reported orphans and unparsed headings. checklist.md retired (the script performs that checklist); sprint-status-template.yaml is the single source for the status vocabulary. Output stays byte-compatible with build's sprint sync and retrospective's tooling. * refactor(bmm): fold sprint-status into sprint-planning's status view sprint_plan.py gains a status subcommand: counts (legacy values mapped), risk flags, open action items, and a priority-ordered next-action recommendation — the old skill's inference-driven summary, computed deterministically and covered by 9 new tests. bmad-sprint-status becomes a v6-shims husk that forwards with status-view intent and a deprecation notice; its dead data/validate modes had zero callers and are gone. If a hand-edited status file defeats the script, the skill falls back to reading it directly and summarizing by best judgment. New explanation page docs/explanation/sprint-planning.md covers the consolidated skill; workflow maps and references updated across all languages. * docs: changelog entries for skill reorg and sprint consolidation * fix(bmm): harden sprint_plan.py per review; add validate/fix intents with full progressive disclosure Review fixes (PR #2659 findings, bot + internal review): - Normalize legacy v6 statuses (drafted/contexted) on every read — merged by meaning and reported, never treated as illegal or reset - dropped_orphans carry their old status; transplant renames via --set - project_key/tracking_system/story_location preserved from the existing file unless overridden; refresh round-trips custom keys and user comments - Hardened write path: dump-to-bytes, fsync, permission-preserving atomic write inside the guarded block, explicit checks (no asserts), atomic restore - JSON-only argparse (errors and -h emit JSON); unicode-aware slugs with hash fallback; fenced code blocks ignored when parsing epics - Odd retro keys, date-typed stamps, and non-mapping YAML report cleanly instead of crashing; unparseable timestamps warn instead of silently disabling the staleness check; malformed action items flagged, not dropped - Dead check subcommand removed; generate --dry-run reports drift/in_sync - test:sprint-planning wired into quality and CI (was test-only) - Retro tests use a vendored template fixture (PATH-05); repo-level test-template-sync.js keeps it byte-identical to the source; template example timestamps and story_location fixed; header block pinned to the template by test New capability: - validate subcommand + reference: structural validation, never writes - fix flow: evidence-gathering subagents -> user-confirmed state table -> generate --fresh --set writes a pristine file (the one path allowed to downgrade); universal script-failure fallback to inference for every intent - SKILL.md is now a lean router: gate, tracking, status, fix, and validate each load as progressive-disclosure references Docs: explanation page gains Repair section; workflow-map and getting-started across all five languages mention the status view; headless payload nests under 'report' to avoid the status key collision; changelog updated. Test suite grows 20 -> 37; retro suite 91/91; docs build and validators green. * docs: mention repair in sprint-planning explanation description
7.5 KiB
title, description, sidebar
| title | description | sidebar | ||
|---|---|---|---|---|
| Sơ đồ workflow | Tài liệu trực quan về các giai đoạn, quy trình và đầu ra của BMad Method |
|
BMad Method (BMM) là một module trong hệ sinh thái BMad, tập trung vào các thực hành tốt nhất của kỹ nghệ ngữ cảnh và lập kế hoạch. AI agent hoạt động hiệu quả nhất khi có ngữ cảnh rõ ràng và có cấu trúc. Hệ thống BMM xây dựng ngữ cảnh đó theo tiến trình qua 4 giai đoạn riêng biệt. Mỗi giai đoạn, cùng với nhiều quy trình tùy chọn bên trong nó, tạo ra các tài liệu làm đầu vào cho giai đoạn kế tiếp, nhờ vậy agent luôn biết phải xây gì và vì sao.
Lý do và các khái niệm nền tảng ở đây đến từ các phương pháp Agile đã được áp dụng rất thành công trong toàn ngành như một khung tư duy.
Nếu có lúc nào bạn không chắc nên làm gì, skill bmad-help sẽ giúp bạn giữ đúng hướng hoặc biết bước tiếp theo. Bạn vẫn có thể dùng trang này để tham chiếu, nhưng bmad-help mang tính tương tác đầy đủ và nhanh hơn nhiều nếu bạn đã cài BMad Method. Ngoài ra, nếu bạn đang dùng thêm các module mở rộng BMad Method hoặc các module bổ sung khác, bmad-help cũng sẽ mở rộng theo để biết mọi thứ đang có sẵn và đưa ra lời khuyên tốt nhất tại thời điểm đó.
Lưu ý quan trọng cuối cùng: mọi quy trình dưới đây đều có thể chạy trực tiếp bằng công cụ bạn chọn thông qua skill, hoặc bằng cách nạp agent trước rồi chọn mục tương ứng trong menu agent.
Giai đoạn 1: Phân tích (tùy chọn)
Khám phá không gian vấn đề và xác nhận ý tưởng trước khi cam kết đi vào lập kế hoạch. Tìm hiểu từng công cụ làm gì và nên dùng khi nào.
| Quy trình | Mục đích | Tạo ra |
|---|---|---|
bmad-brainstorming |
Động não ý tưởng dự án với sự điều phối của người dẫn dắt brainstorming | brainstorming-report.md |
bmad-deep-recon |
Xác thực giả định hoặc lựa chọn giữa các phương án — soạn prompt cho công cụ nghiên cứu chuyên sâu của bạn, xử lý báo cáo của nó, hoặc nghiên cứu ngay tại đây; thị trường, miền nghiệp vụ, kỹ thuật, cạnh tranh, tiếng nói người dùng, học thuật; đã kiểm chứng, có trích dẫn, có thể làm mới | Báo cáo hoặc bản tóm tắt nghiên cứu + bản tóm tắt HTML tùy chọn |
bmad-product-brief |
Ghi lại tầm nhìn chiến lược — phù hợp nhất khi concept của bạn đã rõ | product-brief.md |
bmad-prfaq |
Working Backwards — stress-test và rèn sắc concept sản phẩm của bạn | prfaq-{project}.md |
Giai đoạn 2: Lập kế hoạch
Xác định cần xây gì và xây cho ai.
| Quy trình | Mục đích | Tạo ra |
|---|---|---|
bmad-prd |
Xác định yêu cầu (FR/NFR) | PRD.md |
bmad-ux |
Thiết kế trải nghiệm người dùng khi UX là yếu tố quan trọng | DESIGN.md, EXPERIENCE.md |
bmad-spec |
Chưng cất mọi đầu vào ý định (brief, PRD, bản ghi, ghi chú) thành hợp đồng SPEC.md súc tích + các tệp đi kèm — chốt CÁI GÌ trước CÁCH LÀM |
SPEC.md + tệp đi kèm trong {output_folder}/specs/spec-{slug}/ |
Giai đoạn 3: Định hình giải pháp
Quyết định cách xây và chia nhỏ công việc thành các story.
| Quy trình | Mục đích | Tạo ra |
|---|---|---|
bmad-architecture |
Làm rõ các quyết định kỹ thuật | architecture.md kèm ADR |
bmad-create-epics-and-stories |
Phân rã yêu cầu thành các phần việc có thể triển khai | Các file epic chứa các story |
bmad-sprint-planning |
Cổng kiểm tra mức độ sẵn sàng trước khi triển khai, sau đó theo dõi story và xem trạng thái sprint | PASS/CONCERNS/FAIL + sprint-status.yaml |
Giai đoạn 4: Triển khai
Mọi đầu vào triển khai đều hội tụ vào bmad-build. Workflow này nhận ý định trực tiếp, issue, đặc tả hoặc story đã lập kế hoạch, rồi chọn mức làm rõ, lập kế hoạch, triển khai và review phù hợp.
| Quy trình | Mục đích | Tạo ra |
|---|---|---|
bmad-build |
Biến ý định trực tiếp hoặc story đã lập kế hoạch thành mã nguồn đã triển khai và review | spec-*.md + mã nguồn |
bmad-code-review |
Kiểm tra chất lượng phần triển khai | Được duyệt hoặc yêu cầu thay đổi |
bmad-correct-course |
Xử lý thay đổi lớn giữa sprint | Kế hoạch cập nhật hoặc định tuyến lại |
bmad-retrospective |
Review sau khi hoàn tất epic | Bài học rút ra |
Đầu vào trực tiếp và đã lập kế hoạch
Công việc rõ ràng có thể đi thẳng vào bmad-build. Sáng kiến lớn hơn có thể chuẩn bị PRD, UX, kiến trúc, epic, story, kiểm tra mức sẵn sàng và kế hoạch sprint trước. Các artifact này bổ sung ngữ cảnh, không chọn một workflow triển khai khác.
Quản lý ngữ cảnh
Mỗi tài liệu sẽ trở thành ngữ cảnh cho giai đoạn tiếp theo. PRD cho architect biết những ràng buộc nào quan trọng. Tài liệu kiến trúc chỉ cho dev agent những mẫu cần tuân theo. File story cung cấp ngữ cảnh tập trung và đầy đủ cho việc triển khai. Nếu không có cấu trúc này, agent sẽ đưa ra quyết định thiếu nhất quán.
Bối cảnh dự án
:::tip[Khuyến nghị]
Hãy tạo project-context.md để bảo đảm AI agent tuân theo quy tắc và sở thích của dự án. File này hoạt động như một bản hiến pháp cho dự án của bạn, nó dẫn dắt các quyết định triển khai xuyên suốt mọi quy trình. File tùy chọn này có thể được tạo ở cuối bước tạo kiến trúc, hoặc cũng có thể được sinh trong dự án hiện hữu để ghi lại những điều quan trọng cần giữ đồng bộ với quy ước đang có.
:::
Cách tạo:
- Thủ công — Tạo
_bmad-output/project-context.mdvới stack công nghệ và các quy tắc triển khai của bạn - Tự sinh — Chạy
bmad-generate-project-contextđể sinh tự động từ architecture hoặc codebase