把当前对话中已确定的需求和技术取舍整理成规格说明，交给项目配置的记录工具。
安装与准备
在项目目录的终端执行以下命令，安装后在 Claude Code 中输入下方提示。这里选择项目内的可编辑文件安装。
npx skills@latest add mattpocock/skills --skill to-spec --skill setup-matt-pocock-skills --agent claude-code
使用 Codex 时，把安装命令最后的 claude-code 换成 codex，对话里把 /to-spec 换成 $to-spec。如果使用完整的 Claude Code 插件，则选择 /mattpocock-skills:to-spec，不要再重复安装文件版本。
若按上面命令安装了 Claude Code 文件版，在 Agent 对话中输入 /setup-matt-pocock-skills；这不是终端命令。Claude Code 插件版从斜杠菜单选同名 Skill；Codex 文件版输入 $setup-matt-pocock-skills。按提示选 GitHub、GitLab 或本地 Markdown 记录位置；Linear 等其他跟踪器需要描述实际写入流程。首次配置完成后检查仓库里的 docs/agents/issue-tracker.md 与 docs/agents/domain.md，确认跟踪器、文档位置和领域资料路径正确；只有装了 triage 时才应看到 docs/agents/triage-labels.md。若这些文件没有生成，先完成配置，不要直接调用 to-spec。之后回到已讨论需求的同一会话，列出仍未决定的事项。
第一次使用
把下面的场景和路径替换成你的项目情况，在 Agent 对话里输入：
/to-spec
把刚才确认的团队购买方案整理成规格。第一版支持管理员分配席位，不支持转售。请先确认测试边界，再写入我们配置的本地记录位置，未决定的退款细则单列。
怎样推进任务
保留已决定内容的边界
它不重新主持完整访谈，因此要确保关键讨论仍在上下文里。检查问题陈述、目标用户和第一版范围是否明确。遇到尚未决定的退款规则，应作为未决问题记录，不能因为模板需要完整就让 Agent 自行补出规则。
确认将来如何验收
在写正文前，它会提出测试边界。团队席位例子可以围绕管理员分配、学习者获得权限和重复分配处理来讨论，优先复用已有接口。要求描述实际可观察结果，让下一轮开发知道完成意味着什么。
审阅规格并保存
按问题、方案、用户故事、实现决定、测试决定和范围外事项检查文档。实现部分记录已确定接口与约束，避免大段可能过期的文件路径。选择远程跟踪器时，输出会进入对应项目；本地模式则形成项目文档。
完成后检查什么
试着把规格交给一个没有参与聊天的人：他能否解释要解决什么、哪些事情不做以及怎样验收？确认文档地址和未决项之后，再用 to-tickets 拆分工作。如果有自动轮询 ready-for-agent 标签的代理，要避免它把母规格当作一张可独立实现的票：在轮询规则中明确排除母规格，或等 to-tickets 拆完后移除母规格的该标签，只让代理领取已拆开的任务。
常见问题
为什么没有继续追问产品需求？ 它的目标是总结已有讨论；需求还模糊时先用 grill-with-docs。
旧教程中的 to-prd 呢？ 当前名称是 to-spec。
能保证规格没有遗漏吗？ 仍需对照你实际确认过的范围审阅，尤其是例外情况。
拆票时规格正文被截断？ 远程跟踪器可能没有把很长的规格全文返回给 Agent。生成规格后，先留在同一会话运行 to-tickets，避免在两步之间主动清空或压缩对话；这样拆票可以使用刚生成的完整内容。若已经换了会话，先核对读回内容是否完整，不要拿截断部分或摘要当整份规格继续拆票。[5]
先判断需不需要一份规格
如果需求已经明确，而且改动能在一位 Agent 的一个会话里完成，直接实现通常更省事。to-spec 适合工作需要跨会话交接、会继续拆票时使用；它整理的是前面讨论中已决定的内容，不会替你重新发现需求。开始前配置好项目的记录位置，并把还未决定的退款、例外或权限问题单独列出，避免模板空格诱使 Agent 自行补规则。
正式写入前，先看它提出的测试边界：管理员分配席位、学习者获得访问和重复分配分别在哪里观察？哪些验收能复用现有接口？再读范围外条目是否真的记录了被拒绝的功能，而不是“以后再说”的套话。保存后拿规格交给没参与讨论的人，看他能否说清目标、决定、未决项和验收。若只得到漂亮的章节结构，却找不到真实选择和可观察行为，还不适合继续拆票。
为跨会话的活动日志留一份决定记录
假设团队已经讨论好要增加可搜索的账户活动日志，而实现会分几个会话。可以输入：“用 to-spec 把我们刚确认的活动日志需求写成规格：管理员可按时间和操作者筛选；第一版不支持导出。先确认从列表或 API 哪个边界验收更合适；保留‘日志保留多久’为未决项，不替我定期限。”接着审阅文档里是否真的写出了这三项选择。
如果 Agent 又从零问“谁是用户”，说明前置讨论可能不在当前上下文，先补回已决定内容，而不是让 to-spec 重新采访。若规格突然加入实时推送或审计合规承诺，删掉未讨论的范围。保存到已配置的记录位置后，把地址交给新会话试读：它应该知道做什么、暂不做什么，以及哪些问题必须回到你这里确认。
让测试决策留在后续任务里
写完规格后，检查“Testing Decisions”能否被后续实施者直接找到：哪些行为要在什么边界验证，现有测试入口在哪，哪些条件还未决定。社区有人追踪 to-spec → to-tickets → implement 时发现，规格里谈好的测试边界没有对应任务字段，接手 Agent 只读任务便容易丢掉约定。把测试决策写成可引用的规格小节，并在拆任务时要求每张相关任务明确引用它；进入实施前随机抽一张票检查链接与验收是否仍在。