关于 spec
用于为单一连贯变更编写可直接实施的规格说明；根据提供的来源更新，或使用默认 Markdown 文件。它引导开发者和 Agent 澄清关键决策、制定验收检查，并在规划或实施前停止。
主要功能
- 01审阅需求与相关代码
- 02澄清影响重大的未决选择
- 03定义行为和技术设计
- 04为验收条件配套检查
- 05保留决策与交付状态
适用场景
- 01根据 GitHub issue 编写功能规格
- 02更新现有规格说明来源
- 03为行为和架构规则定义验证方式
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/spec确认已加载。
附带文件agents/openai.yaml
详细介绍
规格说明
为一项完整的变更编写一份可直接实施的规格说明。
规格说明就是任务单：其来源可以是 docs/<feature-slug>/spec.md、GitHub issue，或其他用户提供的文档。更新提供的来源；不要创建重复的任务单或文档。如果没有提供来源，则使用上述 Markdown 路径。只有在用户要求时才发布到跟踪系统。
流程
- 阅读请求、仓库说明、需求、架构和相关实现。沿用已确定的决策，并核实有关当前行为的说法。
- 明确预期结果和范围。对于可能改变行为、数据、接口、安全性、兼容性、运维、成本或验证方式的未决选择，向用户提问。可逆的局部实现细节留给实现阶段决定。
- 按照下方结构编写规格说明。说明相较当前行为的变更；引用共享需求和架构，而不是重复陈述。
- 检查新接手的 Agent 能否在不擅自决定重要事项的情况下完成实现。在相关情况下，梳理成功、拒绝、无效输入和部分失败的情形。
- 以规格说明可供评审为止。不要规划任务，也不要实施。
规格说明结构
预期结果和范围
说明问题、受影响的用户或调用方、预期结果、约束和非目标。
必需行为
描述输入、操作、可观察结果、权限、业务规则和故障恢复。引用适用的 REQ-n ID。在此确定该功能特有的产品细节。
技术设计
说明职责、接口、数据和执行顺序的变更。必要时使用具体类型、负载、状态表或图表消除歧义。
仅在变更涉及的情况下，说明架构变更、索引、迁移、事务边界、并发、重试、取消、安全性、兼容性、可观测性、推出和回滚。说明重要选择、理由及其代价。
指出任何必要的系统架构变更。不要悄然覆盖已接受的规则。交付前记录拟议的架构变更以供评审。
验收和验证
为每个可观察条件和受影响的架构规则配对一项检查。
| ID | 完成条件 | 检查方式 |
|---|---|---|
| AC-1 | 具体结果 | 命令、自动化场景或手动检查 |
保留现有的 AC-n、REQ-n 和 INV-n 引用。绝不重复使用或重新编号这些 ID。对于尚不存在的代码，不要编造可执行命令；应改为定义场景和预期结果。
未决事项
说明尚缺少的答案、有依据时建议的默认选项，以及这些事项是否会阻碍交付。若已无未决事项，填写“无”。不要用占位符掩盖未知事项。
生命周期
分别说明决策状态和交付状态。交付后，保留规格说明，作为功能决策和验收检查的记录。链接已交付的 PR 和验证证据，但不要声称未运行的检查已通过。记录交付期间作出的重要变更；不要删除其决策依据。在需求和架构文档中维护当前的产品与系统规则。
边界
一份规格说明可以拆分为多个任务和 PR。如果拆分有助于交付，请使用 /plan。对于小型且已确定的修复，可直接使用任务描述和检查项，无需正式规格说明。局部变更若不需要根目录文档，则不要强制要求添加这些文档。
返回内容
说明来源、主要决策及其权衡，并指出任何阻碍交付的问题。