关于 to-spec
to-spec 是用于编写软件规格说明的技能，面向需要明确目标、约束和实现意图的开发工作。它规定文档结构、决策梳理、质量检查和交接方式。
主要功能
- 01选择合适的规格类型
- 02梳理事实、决策与未知项
- 03记录约束与审批门槛
- 04定义可观察的验收结果
- 05按流程交接规格
适用场景
- 01为新功能明确目标与边界
- 02分析缺陷并整理验收条件
- 03记录架构决策和实施方案
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/to-spec确认已加载。
附带文件agents/openai.yaml
详细介绍
To Spec
负责：规格界定、决策、约束和实施意图。不负责序列化工单、安排工作、实现代码或决定验证声明。
默认值
除非用户或目标明确要求兼容性，否则应指定干净的目标状态。不要凭推断添加旧版别名、并行格式、垫片或迁移工作。仍需指出破坏性数据变更、外部契约变更和不可逆操作。
除非用户提供路径，否则保存到 docs/specs/<slug>.md。如果已有匹配的规格文档，则更新该文档，而不是创建重复文档。
每份已保存的规格文档都必须包含一个 ## Artifact Graph 章节，其中有稳定的 Artifact ID、Role: spec，以及且仅有 Standalone: true 或一个 Parent。对于有归属的规格文档，须在同一变更中更新归属方的反向 Children 或 Produces 链接。
每份已保存的规格文档还必须包含一个 ## Gates 章节，并在任何工作开始前敲定。首先搜索代码、配置和策略，查找可能阻止工作的限制（版本固定、累计预算、审批检查）。根据用户的表述或搜索结果填写每项门槛；否则直接写入默认值，不要询问：
- attempt：从开始工作到交接；
- budget、time 和 maximum attempts：均未设置；
- approvals：仅包含已获得的审批；工作所需但尚未获得的审批（合并、部署、发布、外部支出）标记为
open； - exact version：除非用户指定，否则为无；
- 已发现的现有阻碍，或“未发现”，并注明搜索范围。
仅当工作需要尚未获得的 open 审批，或发现的阻碍与请求冲突时，才向用户询问一次。本地编辑和测试无需审批。
Agent 自行设定的限制不属于门槛：绝不要因此停止工作或请求延长限制。open 门槛仅阻止依赖该门槛的工作。新一轮尝试从完整预算和时间开始；之前的尝试仍须记录，但不计入本轮。授权适用于工作，不适用于某个版本。
流程
- 选择最匹配的最小类型：
- feature：期望的行为和产品边界；
- decision：选项、决策、权衡和后果；
- diagnostic：证据、假设、根因和修复方向；
- architecture：组件、契约、状态和推出方案；
- bug analysis：观察到的行为／预期行为、复现、原因和验收标准。
- 根据用户决策、代码、当前文档、先前规格、工单和证据还原已知背景。若涉及外部库、API、CLI 或云服务契约，则获取最新的一手文档。
- 区分事实、决策、假设和未解决的问题。仅针对会实质改变目标的缺失决策提问。
- 按类型撰写简洁的章节。相关时应包含目标、非目标、当前和目标行为、语义不变量、外部契约、故障模式、安全／数据问题、备选方案、实施切片和验证策略。
- 一致使用项目领域术语，并链接证据，而不是复制大段源内容。
质量检查
- 验收结果可观察。
- 保留所有重要的外部行为，或明确说明其变更。
- 清楚呈现未知事项和需要人工决策的内容。
## Gates回答每项门槛，或标记为open；不得在工作开始后才首次发现门槛。- 实施计划有序，但不依赖脆弱的行号。
- 测试应区分单元、集成、系统、实时和手动测试需求，不得声称这些测试已经运行。
- 明确说明兼容性和迁移义务，不得想当然。
交接
如果用户要求可执行工单，则将规格文档路径和切片默认值交给 to-tickets。不要自行输出 YAML／前置元数据。
报告规格文档路径、类型、关键决策、未解决问题和建议的下一步。