bmad

BMad：从意图到交付的控制平面协议

BMad 是一种软件交付方法，基于一个理念：应逐步澄清、记录和审查人类意图，并将其作为持久上下文交接给 Agent，而不是临时在聊天中发挥。本技能将这种方法转化为任何 Agent 工具框架都能遵循的协议——无需安装官方 BMad 安装程序。

工作循环：分类请求 → 将意图压缩为契约 → 路由到最小安全路径 → 实现一个边界明确的单元 → 审查并进行分流 → 将失败路由到歧义产生的层级 → 依据可观察的验收标准设置自主性关卡 → 从已完成的工作中学习。

何时使用此技能

当变更请求、功能、Bug 报告、委托构建或多 Agent 史诗级任务需要以下内容时加载：

• 实施前捕获意图——要有契约，而非凭感觉；
• 决定这项工作值得采用多少流程；
• 持久化产物，以便跨会话或跨 Agent 恢复工作；
• 对审查结果进行分流，而非罗列噪声；
• 在边界不安全时安全地停止自主操作。

工作分类（最小安全路径）

类别	特征	流程
直接	目标明确、局部变更、模式成熟、影响范围小	最少澄清后立即实施
有界	连贯的变更，需要简短契约和计划	意图契约 → 计划 → 实施 → 审查
计划	跨组件、多故事、高风险或战略上存在不确定性	分析 → 规划 → 方案设计 → 实施 → 学习

加载 references/classification.md，查看决策表、单问题规则和停止条件。

意图契约（五个字段）

对于有界或计划类工作，应在实施前建立契约：

1. 原因 — 预期结果及其重要性。
2. 能力 — 系统必须能够做什么。
3. 约束 — 技术、运营、法律、安全、隐私、时间、成本和组织边界。
4. 非目标 — 明确不在范围内的内容。
5. 成功信号 — 如何判断结果有效且可接受。

如果某个字段存在实质性歧义，应提出一个高杠杆问题，给出建议答案，并等待决策。对于简单变更，契约可以是对话中的五条要点；对于较大的工作，则应成为带版本号的规范文件。

加载 references/spec.md，了解 SPEC 编写方式和状态术语。模板：templates/SPEC.md 和 templates/INTENT.md。

规范工作循环

1. 在提问前检查代码仓库和可用上下文。
2. 对工作分类，并说明建议的路径。
3. 建立或恢复意图契约；最多提出一个实质性问题。
4. 对非简单工作提出计划；在审批检查点等待。
5. 实施最小的连贯变更；先运行针对性测试，再进行更全面的检查。
6. 审查正确性、范围、安全性、回归问题和可维护性。
7. 修复属于此变更的问题；对于延期处理的问题，保留稳定 ID、编排器处置结论，以及接收任务／关闭证据。仅创建后续工单并不能解决问题。
8. 将审查绑定到确切的候选版本／内容和验收契约、已执行的检查／环境／结果／证据；相关变更后，作废受影响的审批。报告意图、行为、风险、问题关闭情况，并给出接受／返工／调查的选项。详见 references/review-and-failure-routing.md。

Spec 状态词汇

用于可恢复工作的机器可读状态：

状态	含义
draft	Spec 已存在，但尚未就绪
ready-for-dev	已通过就绪检查，可以开始实施
in-progress	正在实施
in-review	正在评审或分流
done	工作流已成功完成
blocked	无法在无人值守的情况下安全继续

blocked 是一种路由信号，而非失败：由更高层级的编排器、其他工作流或人工接手。使用 scripts/check-spec.py 以确定性方式验证 Spec。

失败路由

出现问题时，诊断失败发生的层级：

失败	路由
结果错误或问题错误	意图 / 分析
需求缺失或矛盾	契约 / 规划
技术方案冲突	架构
局部代码错误	实施
测试或评估不足	验证
无关的既存问题	明确延期处理
存在不安全的歧义	阻止并询问

如果真正的问题出在规范上，就不要继续打补丁修改代码。

自主执行门槛

只有满足以下所有条件，才允许自主执行：意图契约一致，验收标准可观察，边界明确，仓库可安全修改，测试或评估可运行，状态可持久化，升级处理方式已定义。自主工作期间：一次只进行一项连贯的变更；绝不扩展范围去做无关改进；未经授权，绝不合并、部署或更改外部系统；若意图存在缺口、能力缺失、破坏性歧义、验证失败或修复无法收敛，则停止。

参考文件

参考资料	何时加载
references/protocol.md	需要为 Agent 准备完整且可直接粘贴使用的操作协议时
references/classification.md	对请求进行分类或选择流程严谨程度时
references/spec.md	编写或恢复 SPEC / 意图契约时
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/release-intent-acceptance.md	根据意图评审集成后的发布，并分流预发布反馈时
references/adoption.md	渐进式采用协议或映射到 dark factory 时

模板

模板	用途
templates/SPEC.md	用于有界工作 / 计划工作的版本化机器契约
templates/INTENT.md	用于有界工作的轻量五字段契约
templates/STORY.md	一个有界、可分派的工作单元
templates/RELEASE-ACCEPTANCE.md	发布检查点、集成结果以及缺陷 / 意图 / 新范围的处置
templates/REVIEW.md	最终人工检查点：意图 → 行为 → 风险 → 验证

脚本

脚本	运行时机
scripts/check-spec.py	编写或编辑 Spec 后：验证五个字段和状态词汇（仅使用标准库，输出 --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 的多 Agent 审议；release-engineering 用于部署 关卡；kanban-guru 用于待办事项和任务分派策略。

何时不使用

• 问题本身尚未经过验证 → 使用 product-discovery。BMad 会压缩意图； 它不会确认问题是否真实存在。
• 尚未决定这项工作的价值有多大 → 先使用 product-shaping（投入意愿、 提案、押注）。BMad 从已明确的意图出发。
• 你需要将正式规范格式和阶段关卡作为工厂流水线 → spec-driven-development 负责 SPEC 格式和关卡机制；BMad 在其周围提供 控制平面协议。
• 你正在执行带有自身关卡的从问题到 PR 的交付流程 → 使用 neckbeard。 BMad 可与之配合；不要同时运行两个相互竞争的交付生命周期。
• 你需要独立评审 → 角色扮演并不代表独立。请使用 agent-council、 单独的评估器或 agent-evals-and-observability；切勿声称角色分离就等同于独立评审。
• 操作官方 BMad 安装程序／工具 → 此技能模拟该方法； 它不会安装或操作 bmad-method npm 包。

版本变更与归属

BMad 正在积极演进（官方代码仓库：bmadcode/bmad-method；BMAD™ 和 BMAD-METHOD™ 是 BMad Code, LLC 的商标）。较早的文章在名称扩展形式、 Agent、文件名和命令方面有所不同。安装官方工具时， 请以官方文档和已安装的源代码为准。此技能是对该方法的原创提炼，作为与框架无关的协议； 它不会复现官方安装程序的内容。