BMad：意圖到交付的控制平面協定 是做什麼的？
BMad 是一種軟體交付方法，核心概念是：人類意圖應逐步澄清、記錄、審查，並以持久上下文的形式傳遞給代理，而非在對話中即興發揮。此技能將該方法轉化為任何代理框架都能遵循的協定 — 無需官方 BMad 安裝程式。
循環流程：分類請求 → 壓縮意圖為合約 → 路由至最小安全路徑 → 實施一個有限單元 → 審查為分類 → 路由失敗至歧義引入層 → 根據可觀察的接受度控制自主性 → 從已完成工作中學習。
何時使用此技能
當變更請求、功能、錯誤報告、委託建置或多代理史詩需要以下條件時載入：
- 實施前的意圖捕捉 — 一份合約，而非一種氛圍；
- 決定工作所需的形式化程度；
- 持久工件，使工作可在不同會話或代理間恢復；
- 對發現進行分類而非列舉雜訊的審查；
- 在邊界不安全時安全停止的自主性。
工作分類（最小安全路徑）
| 類別 | 特徵 | 流程 |
|---|---|---|
| 直接 | 目標明確、局部變更、既有模式、影響範圍小 | 最小澄清後直接實施 |
| 有限 | 需要簡短合約與計畫的連貫變更 | 意回合約 → 計畫 → 實施 → 審查 |
| 倡議 | 跨元件、多故事、高風險或策略不確定 | 分析 → 規劃 → 方案擬定 → 實施 → 學習 |
載入 references/classification.md 以取得決策表、單一問題規則與停止條件。
意回合約（五個欄位）
對於有限或倡議類工作，在實施前建立合約：
- 為何 — 成果及其重要性。
- 能力 — 系統必須能夠執行的功能。
- 限制 — 技術、營運、法律、安全、隱私、時間、成本、組織邊界。
- 非目標 — 明確排除在範圍之外的項目。
- 成功訊號 — 如何知道結果有效且可接受。
如果某個欄位存在實質模糊性，提出 一個 高槓桿問題，建議一個推薦答案，然後等待決策。對於微不足道的變更，合約可以是對話中的五個要點；對於較大的工作，則成為版本化的規格檔案。
載入 references/spec.md 以了解規格撰寫與狀態詞彙。範本：templates/SPEC.md 和 templates/INTENT.md。
標準循環
- 在詢問任何問題前，先檢查儲存庫與可用上下文。
- 分類工作；陳述建議的路由。
- 建立或恢復意回合約；最多提出一個實質問題。
- 對於非瑣碎的工作提出計畫；在審核檢查點等待。
- 實施最小的連貫變更；先執行聚焦測試，再進行更廣泛的檢查。
- 審查正確性、範圍、安全性、回歸、可維護性。
- 修復屬於本次變更的發現；明確延後無關的發現。
- 報告意圖、行為、檔案、風險、驗證、發現處理方式，以及接受/重做/調查的選擇。
規格狀態詞彙
用於可恢復工作的機器可讀狀態：
| 狀態 | 意義 |
|---|---|
draft | 規格存在但尚未就緒 |
ready-for-dev | 已通過就緒檢查；可開始實施 |
in-progress | 實施進行中 |
in-review | 審查或分類進行中 |
done | 工作流程成功完成 |
blocked | 無法安全地無人值守繼續 |
blocked 是路由訊號，而非失敗：由更高層的協調器、其他工作流程或人類接手。使用 scripts/check-spec.py 確定性驗證規格。
失敗路由
當出現問題時，診斷失敗進入的層級：
| 失敗 | 路由 |
|---|---|
| 錯誤成果或錯誤問題 | 意圖 / 分析 |
| 遺失或衝突的需求 | 合約 / 規劃 |
| 衝突的技術方法 | 架構 |
| 不正確的局部程式碼 | 實施 |
| 不足的測試或評估 | 驗證 |
| 無關的既有問題 | 明確延後 |
| 不安全的模糊性 | 阻塞並詢問 |
當規格才是真正問題時，不要持續修補程式碼。
自主性控制
僅在以下所有條件成立時才允許自主執行：意回合約連貫、接受度可觀察、邊界明確、儲存庫可安全修改、測試或評估可執行、持久狀態可寫入、升級路徑已定義。自主工作期間：一次只做一個連貫的變更；切勿因無關的改進而擴大範圍；未經授權絕不合併、部署或變更外部系統；遇到意圖缺口、缺失能力、破壞性模糊、驗證失敗或修復不收斂時立即停止。
參考檔案
| 參考 | 載入時機 |
|---|---|
| references/protocol.md | 需要供代理使用、可直接貼上的完整操作協定 |
| references/classification.md | 分類請求或選擇形式化深度 |
| references/spec.md | 撰寫或恢復規格 / 意回合約 |
| references/lifecycle.md | 將倡議執行通過所有四個階段 |
| references/project-context.md | 設定或審查儲存庫規則 (AGENTS.md) |
| references/review-and-failure-routing.md | 執行審查或診斷失敗 |
| references/autonomy.md | 設定或執行自主（Build Auto）工作 |
| references/party-mode.md | 審議、取捨、設計辯論、事後分析 |
| references/adoption.md | 逐步採用協定或對應到暗工廠 |
範本
| 範本 | 用途 |
|---|---|
| templates/SPEC.md | 有限/倡議工作的版本化機器合約 |
| templates/INTENT.md | 有限工作的輕量五欄位合約 |
| templates/STORY.md | 一個有限、可排程的工作單元 |
| templates/REVIEW.md | 最終人工檢查點：意圖 → 行為 → 風險 → 驗證 |
腳本
| 腳本 | 執行時機 |
|---|---|
| scripts/check-spec.py | 撰寫或編輯規格後：驗證五個欄位 + 狀態詞彙（僅標準函式庫，--json 輸出） |
路由至相鄰技能
- 上游（BMad 之前）：
product-discovery驗證問題是否真實；product-shaping設定胃口並產出提案；product-strategy和product-roadmapping-and-portfolio構建策略背景。 - 下游（BMad 期間）：
spec-driven-development用於正式規格/閘道管線；implementation-planning用於依賴感知的交付計畫；adr-authoring用於架構決策；software-architecture-analysis用於逆向工程現有程式碼庫。 - 執行與閘道：
neckbeard用於問題到 PR 的交付流程；verification-methodology用於接受證據；qa-methodology用於測試策略；agent-evals-and-observability用於獨立評估者；agent-council用於 Party-Mode 風格的多代理審議；release-engineering用於部署閘道；kanban-guru用於待辦事項與分派策略。
何時不使用
- 問題本身未經驗證 →
product-discovery。BMad 壓縮意圖；它不確定問題是否真實。 - 尚未決定工作值多少 → 先使用
product-shaping（胃口、提案、賭注）。BMad 從已放置的意圖開始。 - 你需要正式的規格格式加上階段閘道作為工廠管線 →
spec-driven-development擁有規格格式與閘道機制；BMad 提供圍繞它們的控制平面協定。 - 你正在執行具有自身閘道的問題到 PR 交付流程 →
neckbeard。BMad 與之互補；不要同時執行兩個競爭的交付生命週期。 - 你需要獨立審查 → 角色扮演並非獨立。使用
agent-council、獨立的評估者或agent-evals-and-observability；切勿聲稱角色分離就是獨立審查。 - 操作官方 BMad 安裝程式/工具 → 此技能模擬該方法；它不安裝或操作 bmad-method npm 套件。
版本漂移與歸屬
BMad 正在積極演進（官方儲存庫：bmadcode/bmad-method；BMAD™ 和 BMAD-METHOD™ 是 BMad Code, LLC 的商標）。較舊的文章在名稱擴展、代理、檔案名稱和命令上有所不同。安裝官方工具時，以官方文件和已安裝的原始碼為準。此技能是該方法作為與框架無關協定的原始提煉；它不複製官方安裝程式的內容。