1. 基本信息
| 项目 | 内容 |
|---|---|
| 名称 | to-spec-mattpocock-skills |
| 项目自述名称 | to-spec（作者仓库内子技能，无独立品牌名） |
| 作者/维护者 | Matt Pocock（个人开发者） |
| 来源链接 | https://github.com/mattpocock/skills/tree/main/skills/engineering/to-spec |
| 许可证 | MIT（GitHub API 获取） |
| GitHub Stars / Forks | 223,460 / 19,231（GitHub API；数字属整个 skills 合集仓库，不代表本技能自身热度） |
| 该技能自身安装量 | skills.sh 市场页面显示该技能单独安装 324.5K 次（网页抓取，专属本技能，非合集口径） |
| 最新版本 | 仓库最新 release v1.2.3（2026-08-06）；to-spec 子目录本身最近一次提交 2026-08-19 |
| 安装方式 | Claude Code 官方插件市场一条命令；或通用安装器 npx skills add 单独选装本技能 |
2. 功能介绍与亮点
把一段已经讨论清楚的对话直接合成一份正式的**功能规格（spec）**并发布到项目的工单追踪器——不做访谈、不追问，只对已有讨论做综合整理：
- 先梳理代码库现状与既有测试缝隙，优先复用已有缝隙，只在必要时才提议新缝隙，且尽量提到最高层，让改动面最小
- 规格模板结构固定：问题陈述、解决方案、大量按“作为某角色，我想要某功能，以便达成某收益”格式撰写的用户故事、实现决策（改哪些模块、接口如何变化、架构与 schema 决定）、测试决策（该测哪些外部行为而非实现细节）、明确排除范围、补充说明
- 刻意不写具体文件路径或代码片段（容易很快过时），除非某个原型已经产出了比散文更精确的决策载体（状态机、reducer、schema、类型形状），此时才原样内联并注明来自原型
- 生成后直接按配置好的追踪器发布，并打上
ready-for-agent标签，使其可以被后续的工单拆解与实现流程直接消费
3. 适用场景
固定分类：工程效率与代码质量
适用于团队或独立开发者已经在对话中把一个功能想清楚、需要把这些讨论沉淀成一份结构化、可追溯的正式规格文档的场景，尤其是多会话开发前需要先固化范围与决策、避免后续工单拆解时反复重新讨论的情况。受益人群为使用 Claude Code、Codex 等 agent 做日常开发、已经有明确追踪器与工单习惯的独立开发者与小团队工程师。
4. 跨 Agent 兼容性
| Agent | 结论 | 依据 |
|---|---|---|
| Claude Code | ✅ 原生支持 | 收录于官方插件市场，/plugin install mattpocock-skills 一条命令安装，随作者更新自动同步 |
| Codex | ✅ 原生支持 | 官方 README 明确通用安装器 npx skills@latest add 支持勾选 Codex 作为安装目标；原生 Codex 插件包装形式仍在路线图上 |
| OpenClaw | ⚠️ 需适配 | SKILL.md 遵循标准 Agent Skills 规范（YAML front matter + Markdown 正文），OpenClaw 有独立技能安装通道可处理此类标准格式技能，但未见该技能专门在 OpenClaw 上的验证记录 |
| Hermes Agent | ❓ 未验证 | 官方文档未提及 Hermes，也未找到第三方验证记录 |
5. 推荐理由
把“讨论清楚了”和“能落地执行的规格文档”之间那段容易漏掉细节、反复补问的整理工作固定成一套模板：用户故事、实现决策、测试决策三块分开写清楚，避免后续开发时才发现范围或验收标准没谈拢；刻意不写死代码片段的设计减少了规格过时的概率。该技能自身已有 30 余万次独立安装，第三方自动化安全审计三项全部通过，证据充分扎实。
6. 评分
| 维度 | 分数 | 说明 |
|---|---|---|
| 受欢迎程度 | 9 | skills.sh 市场显示该技能自身安装 32.45 万次；仓库 issue 区有 20 个 issue 标题直接提及 to-spec，来自十余个不同独立用户，涵盖缺陷报告与流程集成提案；独立技术博客有专文分析该技能所在的工作流 |
| 可用性 | 8 | 一条命令通过 Claude Code 官方插件市场安装，或用通用安装器单独选装；MIT 开源；子目录最近一次提交为 2026-08-19，维护频繁；核心综合流程开箱即用，若想把规格发布到真实追踪器则需先跑一次可选的前置配置技能，未配置时会明确提示而非报错 |
| 安全性 | 9 | 见下方检查清单 |
安全检查清单： ① Shell 命令：技能本身不内置可执行脚本，纯提示词/模板驱动，仅按用户配置的追踪器把规格发布为文件或调用追踪器命令，行为透明、范围明确 ② 联网外发：核心综合流程不联网；仅用户主动配置真实追踪器时才会外发请求，行为可选且透明 ③ 凭据处理：核心流程不要求任何凭据；发布到远程追踪器时的凭据由用户自有的追踪器 CLI 登录状态承担，技能本身不存储凭据 ④ 可疑指令：通读 SKILL.md 全文未发现夹带无关推广或隐蔽指令 ⑤ 作者信誉：Matt Pocock 为公开身份的 TypeScript 教育者与工具作者，无造假迹象 ⑥ License：MIT，明确 ⑦ 最近维护：2026-08-19 仍有提交，维护活跃；第三方自动化审计 Gen Agent Trust Hub、Socket、Snyk 三项均为通过
综合评分 = 三项均值 = 8.7
7. 跟同类 Skills 相比的优势
| 技能 | 定位 | 与本技能的差异 |
|---|---|---|
| idea-refine-addyosmani-agent-skills | 把早期模糊想法收敛成含 MVP 范围与假设清单的一页纸方案 | 解决的是“想法尚不清晰”这一更早期阶段，产出是轻量一页纸，不含用户故事、实现决策、测试决策等工程级结构 |
| Ruflo | 面向复杂多服务工程的多智能体编排框架，附带群体协作与持久记忆能力 | 定位是更重的整体编排框架，覆盖面广于单纯的规格撰写，学习与接入成本也更高 |
本技能的差异化在于专注“讨论已经清楚之后”这一个环节，把用户故事、实现决策、测试决策拆成三块结构化内容，且刻意避免写死代码片段以降低过时风险，是同类里少数把“综合而非访谈”作为设计前提的规格撰写技能。
8. 用户评价
- GitHub 用户 chrispatil（仓库 issue，标题涉及 to-spec/to-tickets 的产出边界）：指出 spec 阶段同时承担了“定义要做什么”与“定义如何验证”两件事，提出应更明确拆分，该 issue 有 5 条跟进讨论。
- GitHub 用户 gav-fyi：反馈路由技能 wayfinder 在某些路径下无法正确调用到 to-spec，属于流程集成层面的缺陷报告，有 2 条跟进讨论。
- 技术博客作者 alexrusin（个人博客文章，分析 mattpocock/skills 主流程）：将“先 to-spec 压缩讨论、再 to-tickets 切片”的组合定位为管理 agent 上下文窗口、避免大任务把模型推过清醒推理区间的关键纪律。
9. 其他补充
该技能是 Claude Code 官方插件市场 mattpocock-skills 插件包的一部分；作者同时维护一份技术 newsletter 持续更新该系列技能，仓库内附带完整 CHANGELOG 记录各版本变更。
10. 安装使用方式
- Claude Code：
claude plugins install mattpocock-skills，或会话内/plugin install mattpocock-skills（官方插件市场只读订阅，随作者更新自动同步） - Codex / 其他通用 Agent：
npx skills add https://github.com/mattpocock/skills --skill to-spec单独安装本技能；或npx skills@latest add mattpocock/skills安装整套后勾选 - 安装后：该技能需显式调用（
/to-spec），不会被模型自动触发；在已经把功能讨论清楚的对话上下文中直接触发即可生成规格；若要把规格发布到真实追踪器，建议先跑一次可选的前置配置技能，未配置时会自动提示
11. 注意事项
- 需要显式调用（
disable-model-invocation），不会被模型主动选用，需用户主动触发 - 设计前提是“讨论已经清楚”，不做访谈式追问；若上下文里的讨论本身不完整，产出的规格质量会直接受影响
- 发布到真实追踪器（GitHub/Linear 等）依赖用户自行配置好追踪器，未配置时仅能使用本地文件模式
- 在 OpenClaw 上未见专门验证记录，在 Hermes Agent 上未找到任何官方或第三方验证信息