bmad-spec

BMAD 规格 — 五字段内核提炼器

功能： 接收杂乱、无结构或冗长的输入，生成精简的 SPEC.md 内核（最多五个字段），为所有下游规划工作流奠定基础。这是一项规划技能。它绝不编写应用代码、运行测试或构建任何内容。

产出内容

在配置的输出文件夹（默认为 bmad-output/）下生成一个文件：

bmad-output/
└── SPEC.md    # the five-field kernel

内核刻意保持精简——SPEC 不是 PRD、简介或架构文档，而是对正在构建什么以及为何构建的共同定义。每项下游技能（PRD、tech-spec、architecture）都会将其作为范围的事实依据。

五个字段

字段	用途
Problem（问题）	当前最棘手的问题，以及它为何重要
Capabilities（能力）	解决方案必须具备的能力（以结果为导向）
Constraints（约束）	不容协商的硬性限制（预算、技术、时间、合规性）
Non-Goals（非目标）	明确排除在范围之外的内容——防止范围蔓延和混淆
Success Metrics（成功指标）	用于确认问题已解决的可观察信号

有关带有指导和示例的精确模板，请参阅 templates/spec.template.md。

工作流

1. 接收

接受用户提供的任意内容：

• 粘贴的原始文本、笔记或转录内容
• 现有文件的路径（使用 Read 读取）
• 在聊天中进行的口头描述

如果输入超过几百字，继续处理前先简要确认已收到。不要要求用户重新整理格式——这是本技能的工作。

2. 提取（静默分析）

阅读输入，并找出各字段对应的信息：

• Problem（问题）： 描述了什么痛点、缺口或故障状态？谁会遇到？
• Capabilities（能力）： 要求实现哪些结果或能力？将功能改写为能力（“用户可以……”“系统支持……”）。
• Constraints（约束）： 哪些内容是固定的？查找预算数字、技术要求、截止日期、法规提及、团队规模限制。
• Non-Goals（非目标）： 输入中有哪些未提及的内容可能会让读者误以为已包含在内？明确排除了什么？哪些内容延期处理？
• Success Metrics（成功指标）： 怎样才算“完成”或“正常运行”？查找数字、可观察行为和阈值。

3. 起草并展示

起草全部五个字段的精简内容，并在写入磁盘前先在聊天中展示给用户。每个字段都要简洁：

• Problem：最多 2–5 句话。
• Capabilities：3–7 个要点，以结果为导向。
• Constraints：2–6 个要点，仅包含硬性限制。
• Non-Goals：2–6 个要点，清晰明确。
• Success Metrics：2–5 个要点，每项都包含可衡量的信号。

展示后，提出一个有针对性的问题：“在我写入 SPEC.md 之前，这里有什么需要修改的吗？”

4. 写入

用户确认（或修改）后，使用模板编写 SPEC.md：

${CLAUDE_PLUGIN_ROOT}/skills/bmad-spec/templates/spec.template.md

输出路径：<outputFolder>/SPEC.md（如果 bmad-output/config.yaml 存在，则读取该文件以查找配置的输出文件夹；否则使用 bmad-output/）。

在 bmad-output/decision-log.md 中追加一条新记录（如果文件不存在，则创建）：

## SPEC created — <ISO date>
- Source: <one-line description of the input, e.g. "stakeholder brain dump">
- Key scope decision: <the single most important Non-Goal or Constraint>

5. 交接

写入后，告知用户 SPEC 能解锁哪些后续工作：

• Quick Flow track → 交接给 bmad-tech-spec，将内核转化为可部署的规格。
• BMad Method / Enterprise track → 交接给 bmad-product-brief 或 PM 角色（bmad-prfaq），以编写完整 PRD。
• 如果尚无工作区，建议先运行 /bmad-planning-orchestrator:bmad-init 选择一条路径。

三种意图

• 创建 — 将新输入提炼为新的 SPEC.md（最常见的情况）。
• 更新 — 用户提供了新信息或更改了范围。读取现有的 SPEC.md，应用更改，提供差异摘要，确认后再 覆盖。将更改记录到 decision-log.md。
• 验证 — 根据五字段契约审查 SPEC.md：所有字段是否都存在且非空？问题是否是 一个连贯的陈述？能力是否以结果为导向（而非功能列表）？非目标是否明确无歧义？标记 所有缺漏，并提出修复建议。

提炼启发式

将杂乱输入映射到五个字段时，请遵循以下规则：

输入模式	映射到
“我们需要修复 / 用户在抱怨 / 它坏了”	问题
“它应该 / 用户可以 / 系统支持”	能力
“我们不能 / 没有预算 / 必须使用 / 截止日期前”	约束
“不在范围内 / 以后再做 / 不属于 v1 / 不会做”	非目标
“如果达到 X%，就会 / 我们会知道它有效，因为 / 目标”	成功指标

当某个约束听起来像愿望（例如，“我们希望在 Q3 完成”）时，将其移至非目标， 或标记为软性约束并注明其中的歧义。

当能力听起来像功能而非结果时，请改写：“添加 搜索栏” → “用户只需按 3 次键即可找到任何记录”。

当输入中没有成功指标时，请使用问题陈述推导代理指标：如果问题是“用户找不到 X”，则指标可以是“找到 X 所需时间缩短 Y%”。

护栏

• 精简是设计原则。 不要添加第六个字段。如果重要信息无法归入这五个字段， 请将其作为背景信息记录在文件头部，并引导用户在 PRD 或技术规格阶段补充。
• 不设计解决方案。 能力字段描述结果，而非实现方案。架构、技术栈和方法应在后续阶段确定。
• SPEC 中不得出现故事点、速度或燃尽图。
• 范围规则。 此技能的最终产物是 SPEC.md。它不会创建故事、编写代码或生成验收标准。将这些工作交给下游技能。

有关更全面的提炼模式和边缘情况，请参阅 REFERENCE.md。

---

属于 BMAD Planning & Orchestrator 插件 — 由 BMAD Code Organization 为 BMAD Method 提供的 Claude Code harness（https://github.com/bmad-code-org/BMAD-METHOD）。实现了 bmad-spec 的精神。所有方法论的致谢均归 BMAD Code Organization 所有。