用途
本技能用于启动一个 Beat 变更（change）并生成规格产物（spec artifacts）。适用场景包括：创建新的 Beat 变更并生成规格产物（proposal、gherkin、design.md）；为已有变更续写尚未完成的规格产物；选择要包含哪些规格产物（预设：Full、Standard、Minimal、Technical、Custom）。
不适用场景：拆解任务或创建执行计划（应使用 /beat:plan）；在提交前探索想法或思考问题（应使用 /beat:explore）；实现代码（应使用 /beat:apply）；审查或验证实现（应使用 /beat:verify）。
触发示例：“Design a user authentication feature”“Create a change for login”“Generate specs for X”。不应触发：“break down the tasks”“let me think about this”“implement the change”。
主要能力
- 创建或选择变更容器（beat/changes/<name>/，含 status.yaml 与 features/.gitkeep）。
- 按流水线顺序（proposal -> gherkin -> design）生成规格产物。
- 通过 AskUserQuestion 询问产物预设：Full（Proposal + Gherkin + Design）、Standard（Proposal + Gherkin）、Minimal（Gherkin only）、Technical（Proposal only）、Custom。
- 在写 gherkin 前执行 CONTEXT.md 四问检查，确保场景中使用的项目专有术语已在 beat/CONTEXT.md 中定义。
- 每个产物写完后执行四项规格自审（占位符 / 一致性 / 范围 / 歧义），就地修复。
- 写 design.md 时对每个 Key Decision 执行三条件 ADR 门（难以逆转 + 令人意外 + 真实权衡），满足时提议提升为 docs/adr/ 下的 ADR。
- 修改已有 feature 时先做冲突检查、备份 .orig、复制到 changes/ 并记录到 status.yaml。
- 提交变更目录及本次运行写入或修改的所有活文档文件。
使用方式
输入为 kebab-case 的变更名称，或对要构建内容的描述，也可以是已有变更名称以快进剩余产物。若未提供明确输入，会询问要构建什么。
前置技能（在继续前调用）：superpowers:using-git-worktrees（首次写文件前，MUST）、superpowers:brainstorming（创建 proposal 或 design 前，MUST）、mattpocock-skills:grill-with-docs（当 CONTEXT.md 歧义足够复杂时，OPTIONAL）。若前置技能未安装则跳过并继续，但绝不因主观判断不必要而跳过。
流程：选择或创建变更 -> 调用 using-git-worktrees -> 询问产物预设 -> 按需调用 brainstorming -> 创建并自审各产物 -> 提交产物 -> 展示摘要。
产物模式：Proposal 含 ## Why、## What Changes、## Impact；Gherkin 采用 SpecFlow 风格，标签 @happy-path/@error-handling/@edge-case，每个场景必须有测试层标签 @e2e 或 @behavior（默认 @behavior），用业务语言描述行为；Design 含 ## Approach、## Key Decisions、## Components。
提交时按文件名暂存，不要以目录形式暂存 docs/adr/。提交信息示例：“design(): add spec artifacts”。
适用场景
适合在 Beat 工作流中为大型、中型、小型功能或工具/基础设施/重构类变更准备规格文档，并希望以结构化方式管理术语表、ADR 与架构文档的团队。
限制
本技能不负责任务拆解、实现、探索与验证。若前置技能未安装，会以回退方式继续。ADR 提升、架构中心更新等建议均为可选，用户可拒绝。关于收费、价格、平台支持等信息，资料中暂未提供。