用途
该技能用于为某个功能编写或完善规格文档，输出到 docs/<slug>-spec.md。文档用于让评审者检查改动：说明要做什么、规则、接口、验收标准和不在范围内的事项。
输入
- 来自 on-the-spot 的决策（
.scratchpad/<slug>/interview-decisions.md）或对话中的决策； - 来自 domain-language 的术语（
.scratchpad/<slug>/domain-language.md），若该步骤运行过，则只使用这些术语； - 当前代码，使规格能写出真实的文件、路由和表；
- 功能所涉及代码的既有决策记录：新规则不得与已接受的 ADR 矛盾，除非有取代它的新 ADR；
- 来自分支的功能 slug（git-commit-organizer）。
输出与模板
输出 docs/<slug>-spec.md，使用 simplified-technical-language 的文档语言，并用 git-commit-organizer 提交。
模板包含：标题、TL;DR（plain-visual-docs 的通俗摘要）、状态（Draft/Approved/Implemented）、分支、日期、修订（n - 变更内容）、摘要、目标、领域语言（术语表与状态图）、架构、代码布局（带 + 和 ~ 的 ASCII 树）、技术栈新增、脚本、环境变量（名称、默认值、说明）、接口（路由、命令或公共 API；表格与 ASCII 树）、数据模型（SQL 或 schema、erDiagram）、业务规则（按区域分小节并配图）、已接受风险（用户接受的风险及原因）、验收标准、测试（层 → 标准表）、文档（需更新的文档）、不在范围内。不适用的章节可省略。
验收标准写法
- 按
AC-01、AC-02编号，用###按区域分组； - 每条采用固定形式：加粗的编号与标题，然后是 Given、When、Then 三行；
- 每个标准只描述一个可观察行为，包含测试可检查的状态码、消息和数据变化；
- 覆盖非正常路径：无效输入、缺少或过期凭据、缺少权限、限制、未知 ID；
- 每条标准必须映射到测试章节的某个测试层，或标注为手动并说明原因；
- 当规则定义某个值如何计算时，增加一条标准，确保所有展示该值或由其派生值的地方（如列表中的订单总额、详情、徽章颜色、导出）使用同一规则；
- 若功能读取数据，数据中出现的每种异常情况（空、重复、越界、混合单位）都应成为业务规则或列入不在范围内。
已接受风险
对功能涉及的每个删除或覆盖数据的操作，说明它现在会移除什么、执行者是否被警告。每条风险都要用命令验证后才算接受（例如风险与构建产物有关时，构建并启动应用），并把命令及结果写在风险旁边。没人运行过的风险只是假设，不是已接受风险。
不在范围内
列出讨论过但被排除的内容，以及读者可能预期的相近功能，防止范围蔓延。
模式
- Create：按决策写出完整规格；在聊天消息末尾列出所有自行决定的细节，供用户确认。
- Refine：应用评审发现（如 red-team-review 的魔鬼代言人任务）或对歧义的答复；同时修改规则、标准、风险和不在范围列表；增删标准后按顺序重新编号并更新所有引用（测试表、计划、图示）；递增修订号并说明变更。
- Visualize：用 plain-visual-docs 补充 TL;DR 和图示；可交给子代理，要求只改 TL;DR 和图示、报告绘图时发现的每个歧义、校验每个 Mermaid 块；提交前审查其 diff。
- Finish：报告前统计规格行数，并估算改动所需的代码与测试行数；若规格更长，只保留评审者检查改动所需的内容（TL;DR、接口、验收标准、不在范围内），删除其他章节以及重复决策、代码或其他文档的每一行；再次统计；若仍更长，用一行说明哪部分必须保留及原因。最后在聊天中报告路径、两个行数、标准数量、主要章节和需确认的默认值，并在进入计划前询问。
适用场景
适用于需要对功能规格进行结构化编写、评审与收敛的软件开发流程，尤其适合采用验收标准驱动测试、需要记录已接受风险和明确范围边界的项目。
限制
资料未说明该技能的具体运行环境、安装方式或命令行调用细节，暂未提供。