关于 to-spec
to-spec 是一项将对话上下文和代码库理解整理为功能 spec 的 skill，不访谈用户。它会与用户确认测试 seam，并将 spec 发布到项目 issue tracker。
主要功能
- 01根据对话和仓库上下文起草 spec
- 02起草前探索代码库
- 03提出并确认测试 seam
- 04使用指定的 spec 模板
- 05发布时添加 ready-for-agent 标签
适用场景
- 01根据已有上下文记录功能需求
- 02确定功能测试的高层 seam
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/to-spec确认已加载。
附带文件agents/openai.yaml
详细介绍
来自项目 README这个 skill 使用当前 conversation context 和 codebase understanding 产出 spec。不要访谈用户，只综合你已经知道的内容。
Issue tracker 和 triage label vocabulary 应该已经提供给你；如果没有，请让用户运行 /setup-matt-pocock-skills。
流程
-
如果还没有探索 repo，先探索它以理解 codebase 当前状态。在 spec 中始终使用项目 domain glossary vocabulary，并遵守相关 ADRs。
-
草拟你准备在哪些 seams 上测试这个 feature。优先使用现有 seams，而不是新增 seams。使用尽可能高层的 seam。如果确实需要新增 seams，尽可能在最高层提出。
Seams 越少越好，理想数量是一个。与用户确认这些 seams 是否符合预期。
- 使用下面模板写 spec，并发布到项目 issue tracker。应用
ready-for-agenttriage label；不需要额外 triage。
Problem Statement
用户正在面对的问题，从用户视角描述。
Solution
问题的解决方案，从用户视角描述。
User Stories
一份很长的编号 user stories 列表。每条 user story 使用以下格式：
- As an , I want a , so that
这份 user stories 列表应该非常完整，覆盖 feature 的所有方面。
Implementation Decisions
已作出的 implementation decisions 列表。可以包括：
- 将 build/modify 的 modules
- 将 modify 的 module interfaces
- 来自 developer 的技术澄清
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
不要包含具体 file paths 或 code snippets。它们可能很快过时。
例外：如果 prototype 产出的 snippet 比 prose 更精确地编码了某个决策（state machine、reducer、schema、type shape），可以内联到相关 decision 中，并简短说明它来自 prototype。只保留决策密集部分，不要放完整 working demo。
Testing Decisions
已作出的 testing decisions 列表。包括：
- 什么是好测试的描述（只测试 external behavior，不测试 implementation details）
- 哪些 modules 会被测试
- 测试的 prior art（即 codebase 中类似类型的 tests）
Out of Scope
本 spec 范围外事项的描述。
Further Notes
关于 feature 的其他 notes。