用途：为一项连贯的变更编写一份可直接实施的规格说明（spec）。规格即工单，来源可以是 docs/<feature-slug>/spec.md、GitHub issue 或用户提供的文档；应更新已有来源，不另建重复工单或文档；未提供来源时使用上述 Markdown 路径；仅在要求时才发布到跟踪系统。
主要能力：先阅读请求、仓库说明、需求、架构与相关实现，复用已定决策并核实当前行为；界定结果与范围，对可能影响行为、数据、接口、安全、兼容性、运维、成本或验证的未决选择进行询问，可逆的本地机制留给实现。规格结构包括：结果与范围（问题、受影响用户或调用方、期望结果、约束与非目标）；必需行为（输入、动作、可观察结果、权限、业务规则、失败恢复，引用 REQ-n）；技术设计（职责、接口、数据、执行顺序，必要时给出具体类型、载荷、状态表或图；仅在影响变更时覆盖模式变更、索引、迁移、事务边界、并发、重试、取消、安全、兼容性、可观测性、发布与回滚，并说明重要选择、理由与代价；涉及系统架构变更须记录待评审）；验收与证明（每个可观察条件与架构规则配一项检查，含 ID、完成条件、检查方式，保留既有 AC-n、REQ-n、INV-n 引用，不复用或重编号，不为不存在的代码编造可执行命令）；未决决策（缺失答案、有依据的推荐默认值、是否阻塞交付，已定则写 None）；生命周期（分别说明决策状态与交付状态，交付后保留规格作为记录，链接已交付 PR 与证明，不声称未运行的检查通过，记录交付期间的重要变更）。
使用方式：按上述流程与结构撰写，完成后停在待评审状态，不规划任务也不实施。
适用场景：需要记录关键决策、影响行为或接口的单个功能或重大变更。
限制：一份规格可对应多个任务与 PR，拆分时可用 /plan；小而确定的修复可直接用任务描述与检查，无需正式规格；本地变更不必强制根文档。返回时报告来源、主要决策与权衡、以及任何阻塞性问题。