关于 bmad-tech-spec
bmad-tech-spec 是 BMAD Planning & Orchestrator 插件中的 Quick Flow 规划技能，为小型、范围明确的变更编写或检查一份集中的 tech-spec.md。它面向需求清晰、故事数量较少的工作，将产品缘由、技术方案和故事清单整合在一起。
主要功能
- 01创建、更新或验证 tech-spec.md
- 02整理问题、方案和项目范围
- 03编写带 MoSCoW 标记的功能需求
- 04记录技术方案、依赖与风险
- 05将测试内容限定为规划策略
- 06记录重要决策并提供后续故事步骤
适用场景
- 01为小型功能编写 Quick Flow 规格
- 02修订现有技术规格并记录变更
- 03在拆分故事前检查规格完整性
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/bmad-tech-spec确认已加载。
附带文件templates/tech-spec.template.md
详细介绍
BMAD Tech Spec — Quick Flow
此技能用于为 Quick Flow 工作生成精简的 tech-spec.md：适用于规模较小、范围明确的功能或变更，故事数量在 1-15 个之间。它将产品依据、技术方案和故事待办列表整合到一份轻量文档中，省去大型工作流所需的独立 PRD 和架构文档。
工作流指引
- 1-15 个故事、单个团队、需求明确 → Quick Flow（此技能）
- 10-50+ 个故事、涉及多个关注点或范围不确定 → 先使用 bmad-prd，再使用 bmad-architecture
- 30+ 个故事、跨组织，涉及安全/合规/DevOps 维度 → Enterprise 工作流
工作流
第 1 步 — 确认意图
询问用户（或根据上下文推断）以下三种意图中哪一种适用：
| 意图 | 适用情况 |
|---|---|
| 创建 | 尚不存在 tech-spec.md |
| 更新 | 修改现有规范中的范围、需求或方案 |
| 验证 | 在进入故事编写阶段前，检查草稿规范是否符合 BMAD 完整性要求 |
第 2 步 — 收集上下文
对于创建，通过交互或从现有项目文件中收集：
- 问题与解决方案 — 我们要解决什么问题，以及如何解决？
- 范围 — 哪些内容在范围内？哪些内容明确不在范围内？
- 功能需求 — 编号列出，并标注 MoSCoW 优先级（MUST / SHOULD / COULD）
- 非功能需求 — 与项目相关的性能、安全性、无障碍目标；省略不适用的模板内容
- 技术方案 — 技术栈、关键组件、数据模型草图、API 接口（如有）
- 故事列表 — 高层级待办事项；scrum-master 技能会将其整理为完整的故事文件
- 依赖项与风险 — 第三方库、外部服务、已知的不确定因素
- 决策日志条目 — 本次对话中做出的、应记录在
bmad-output/decision-log.md中的选择
如果存在 bmad-output/project-context.md，请加载该文件——它是项目章程，未经记录决策不得与之冲突。
对于更新，先阅读现有的 bmad-output/tech-spec.md，再进行有针对性的修改，并在决策日志中记录变更内容。
对于验证，阅读现有规范，并根据下方验证清单部分中的清单进行检查并汇报结果。
第 3 步 — 起草或修订
使用位于以下路径的模板：
${CLAUDE_PLUGIN_ROOT}/skills/bmad-tech-spec/templates/tech-spec.template.md
填写每个章节。确实不适用的章节可以省略（例如，纯 CLI 工具无需 API 设计），并在正文中注明省略原因。不要留下未替换的 {{placeholders}}。
规范中的测试策略仅用于规划——说明应测试什么以及原因。不要编写测试代码。不要将覆盖率数字设为强制目标；应将其作为开发团队的参考建议。
第 4 步 — 写入输出
写入 bmad-output/tech-spec.md（如果设置了 outputFolder 用户配置，则遵循该配置）。
如果有决策日志条目，将其追加到 bmad-output/decision-log.md（如果文件不存在，则创建文件，并使用格式：## [YYYY-MM-DD] <title> /
**Decision:** ... /
**Rationale:** ...）。
第 5 步 — 确认后续步骤
写入后，告知用户：
- 该规范是 Quick Flow 的规划文档。下一步是创建故事。
- 使用 bmad-epics-and-stories，根据规范中的故事列表整理故事。
- 如果本次对话中范围已扩大到约 15 个故事以上，建议在继续之前切换到 BMad Method 工作流（bmad-prd + bmad-architecture）。
验证清单
当意图为 验证 时，请报告每项的通过／失败状态：
- 问题陈述清晰且具体
- 解决方案有描述，且不包含实现代码
- 所有功能需求均已编号并标注 MoSCoW 优先级
- 非功能需求中至少包含一项性能或安全要求（如适用）
- 技术方案指出所用技术栈并描述关键组件
- 存在故事列表，且每个故事标题均为单行、以行动为导向
- 故事数量为 1-15（超出时请标记）
- 不存在未替换的
{{placeholders}} - 测试部分仅描述策略（不包含可执行测试代码）
- 依赖项表列出版本或版本约束
- 风险表至少列出一项风险及其缓解措施
- 已为所有重大选择编写决策日志条目
- 没有内容指示开发 Agent 运行测试、lint、构建或部署
子 Agent 策略
此技能主要采用单线程方式（一次对话、一份文档）。并行处理并非必需，且仅限于信息收集：
- 如果用户需要并行调研（例如比较两种技术方案），请并行启动两个 WebSearch/WebFetch Agent，并在撰写规格说明前综合调研结果。
- 撰写时不要启动并行 Agent——规格说明是一份连贯的文档，必须一次性完成，以避免合并冲突。
属于 BMAD Planning & Orchestrator 插件的一部分——这是一个用于 BMAD Method 的 Claude Code harness，由 BMAD Code Organization 开发（https://github.com/bmad-code-org/BMAD-METHOD）。体现了
bmad-tech-spec的理念。所有方法论的功劳均归于 BMAD Code Organization。