BMad：从意图到交付的控制面协议
BMad 是一种软件交付方法，其核心思想是：人类意图应被逐步澄清、记录、审查，并以持久上下文的形式传递给智能体，而不是在聊天中即兴发挥。此技能将该方法转化为任何智能体工具都能遵循的协议——无需安装官方 BMad。
核心循环：分类请求 → 压缩意图为契约 → 路由到最小安全路径 → 实现一个有界单元 → 分流式审查 → 将失败路由到歧义进入的层级 → 根据可观察的接受度控制自主性 → 从已完成工作中学习。
何时使用本技能
当变更请求、功能、错误报告、委托构建或多智能体项目需要以下内容时加载：
- 在实现之前捕获意图——一份契约，而非模糊印象；
- 决定工作所需的形式化程度；
- 持久化制品，使工作可在会话或智能体之间恢复；
- 对发现进行分流而非枚举的审查；
- 在边界不安全时安全停止的自主性。
工作分类（最小安全路径）
| 类别 | 形态 | 流程 |
|---|---|---|
| 直接 | 目标明确、局部更改、模式已建立、影响范围小 | 最小澄清后立即实现 |
| 有界 | 需要简短契约和计划的连贯更改 | 意图契约 → 计划 → 实现 → 审查 |
| 主动型 | 跨组件、多故事、高风险或战略不确定 | 分析 → 规划 → 解决方案 → 实现 → 学习 |
加载 references/classification.md 查看决策表、单问题规则和停止条件。
意图契约（五个字段）
对于有界或主动型工作，在实现前建立契约：
- Why（为什么）——成果及其重要性。
- Capabilities（能力）——系统必须能做什么。
- Constraints（约束）——技术、运营、法律、安全、隐私、时间、成本、组织边界。
- Non-goals（非目标）——明确排除在范围之外的内容。
- Success signal（成功信号）——如何知道结果可行且可接受。
如果某个字段存在实质歧义，提出一个高影响力的问题，给出推荐答案，然后等待决策。对于小改动，契约可以是对话中的五条要点；对于大工作，它将成为版本化的规范文件。
加载 references/spec.md 查看 SPEC 编写和状态词汇。模板：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 | 编写或恢复 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/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拥有 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 的商标）。较早的文章在名称扩展、智能体、文件名和命令上存在差异。安装官方工具时，以官方文档和已安装的源文件为准。此技能是对该方法作为工具无关协议的原创提炼；它不复制官方安装程序的内容。