Matt Pocock Skills：用 to-spec 写规格，再用 to-tickets 拆任务

需求已经聊清楚，交给 Agent 开工时却又要解释一遍：哪些行为必须保留，怎样判断完成，哪些改动不能碰。Matt Pocock 的 to-spec 和 to-tickets 分别处理规格整理与任务拆分，让这些约束留在下一步能读取的文档里。

当前工程 Skill 位于仓库的 skills/engineering/ 下。按旧教程寻找根目录里的 to-prd，容易找错入口；写规格可以先看 to-spec，拆任务再看 to-tickets。

先确定规格和任务放在哪里

这套工作流需要知道项目使用哪个任务跟踪器、哪些分流标签，以及领域术语和架构决策放在哪里。项目尚未配置这些信息时，官方入口是 setup-matt-pocock-skills。它会检查现有仓库，提出配置草案，经过用户确认后写入项目文档；任务可以使用实际跟踪器，也可以采用本地 Markdown。项目配置说明

先看清目标位置再运行后续流程，尤其是连接团队任务跟踪器的项目。生成一份文档与把它发布成团队任务，是不同的操作。

to-spec 接住已经讨论过的需求

to-spec 使用已有对话和代码库信息整理规格，不重新进行需求访谈。它会了解相关模块、项目术语和已有架构决策，整理用户要解决的问题、方案、用户故事、实现决定、测试方式及范围排除。

测试边界仍要与用户核对。这里的“测试缝”指能够验证外部行为的边界，例如调用一个已有服务接口，检查它返回的结果。项目已经有合适边界时，优先复用；不要为了写规格把每个内部函数都变成独立测试入口。

实现部分主要记录接口、数据结构和行为约束。当前文件要求避免容易过期的具体路径与代码片段，同时保留一个例外：如果原型中的片段比文字更准确地表达某个决定，可以留下与决定有关的部分。

假设要增加 CSV 导入，规格可以先回答：首行是不是表头，空单元格怎么处理，同一标识重复出现时覆盖还是拒绝，哪种错误会终止整批。这些是供团队选择的示例条件。没有确定的规则应该继续标为未决，不能让 Agent 为了补齐文档自行拍板。

to-tickets 把规格拆成能单独验证的任务

任务拆分以一条可演示的行为为单位，穿过必要的界面、接口、存储与测试层，并写清哪些任务会阻塞它。用户要先确认粒度和依赖关系，之后才发布到已配置的跟踪器。

沿用 CSV 导入的例子，可以先做“上传两条合法记录，预览并确认导入”，再做“重复标识按已确定规则处理”。每张任务都应交代怎样验证完成。只写“先改表，再做接口，最后做页面”，容易留下几张分别完成却无法一起使用的任务。

大范围机械重构有单独的处理方式。若一次共享字段改名会影响许多调用点，当前 to-tickets 文件建议先让新旧形式共存，再分批迁移，最后移除旧形式；不必强行把这种工作塞进普通功能切片。

开工前核对三件事

规格里有没有可观察的完成条件，任务的依赖是否真正阻塞开工，文档里的术语是否与现有项目一致。若其中一项还不清楚，先补那个缺口。把同一段模糊需求从聊天复制到规格，再复制到 ticket，并不会让它变得可执行。