把计划拆成贯穿必要层次的小任务，为每个任务写清验收条件和阻塞依赖。
安装与准备
先准备 Node.js 22.20.0 或更新版本，以及 npm/npx，这是当前 skills@latest 的运行要求。在项目目录的终端执行以下命令，安装后在 Claude Code 中输入下方提示。这里选择项目内的可编辑文件安装。
npx skills@latest add mattpocock/skills --skill to-tickets --skill setup-matt-pocock-skills --agent claude-code
使用 Codex 时，把安装命令最后的 claude-code 换成 codex，对话里把 /to-tickets 换成 $to-tickets。如果使用完整的 Claude Code 插件，则选择 /mattpocock-skills:to-tickets，不要再重复安装文件版本。
准备规格文件、问题链接或已充分讨论的对话。安装后，在同一项目的 Agent 对话里运行 /setup-matt-pocock-skills；Codex 输入 $setup-matt-pocock-skills，完整 Claude Code 插件输入 /mattpocock-skills:setup-matt-pocock-skills。第一次可选择 Local Markdown，确认它展示的配置草稿后保存，再运行 to-tickets。
GitHub 模式需要安装并认证 gh，GitLab 模式需要安装并认证 glab；Linear 等其他跟踪器需说明实际工作流。若另行使用 triage，先安装它，setup 才会配置分拣标签。
第一次使用
把下面的场景和路径替换成你的项目情况，在 Agent 对话里输入：
/to-tickets specs/team-purchases.md
先展示任务拆分和阻塞关系。每个任务应该能演示一个完整行为，不要拆成“全部数据库”“全部接口”“全部页面”。确认后写到本地任务目录。
怎样推进任务
从可演示的行为切分
第一张任务可以让管理员分配一个席位并让学习者获得访问权限，这会穿过必要的数据、接口、页面和测试。后续再增加批量分配或回收席位。每张任务完成时都应有一个可独立说明的结果。
检查真实的阻塞关系
回收席位可能依赖分配流程，而更新帮助文案未必阻塞开发。逐张检查“Blocked by”，删除只是为了排出整齐顺序而添加的依赖。无阻塞任务可以并行进行，但必须具备各自的验收标准。
确认粒度后生成记录
它会先展示编号、交付行为和依赖，让你调整粒度。确认后，本地模式在 .scratch/<feature>/issues/ 下为每个任务写独立文件；远程跟踪器则按依赖顺序创建问题，支持原生阻塞关系时使用原生链接，否则在正文写明阻塞任务的编号。
完成后检查什么
每张任务都应有明确交付物、验收条件和阻塞项。挑一张没有前置依赖的任务，确认一个新的 Agent 只读它和引用规格就能开始，而不用猜测整套聊天背景。
远程模式还要逐张打开已创建的问题，检查正文与验收条件完整，并在跟踪器界面确认支持的原生阻塞关系确实建立；正文里的“Blocked by”文字不能代替原生关系。
如果输入是现有 GitHub 规格问题，也要确认新票出现在它的子问题列表中，单纯提及父问题不等于建立子问题关系。发现关系缺失时，让 Agent 为已有票补齐链接，并保留父问题的正文、标签和状态，不必重复创建任务。
常见问题
大型重命名怎么拆？ 跨仓库的机械改动可能不适合普通切片，当前流程允许先扩展新形式、分批迁移调用、最后删除旧形式。
会自动开始开发吗？ 生成任务后另行启动实现。
本地只得到一大篇文档？ 检查是否要求了每张任务一个文件，这才方便分派。
在发布任务前做一次拆分测验
对每张票问：“完成后能演示什么新行为？”如果答案只是“数据库表建好”或“接口都写完”，它缺少用户可观察结果，应与相邻工作合并或改写成纵向切片。每张票要能让一个新会话独立完成：写清输入、预期结果、验收方式、阻塞项和引用的规格，不要把易过期的具体行号当成主要说明。先展示编号列表供你调粒度，再写进跟踪器。
阻塞关系也要经得起追问：回收席位确实依赖分配能力，但帮助文案未必需要等它完成。第一张可开工的票应没有前置阻塞；无依赖的票才可能并行。若三行改动被拆成十几张票，多半是选错了工具或切得过细；能在一个会话完成的改动可以直接实现。跨仓库的大范围机械迁移是例外，可以先扩展新形式、分批迁移，再删除旧形式，别硬把它伪装成普通功能切片。
用通知偏好检验纵向切片
假设规格要求用户分别控制邮件和应用内通知，可以输入：“用 to-tickets 将通知偏好拆成可单独演示的任务。第一张票让用户关闭邮件提醒并在重新登录后仍保持选择，穿过必要的持久化、接口、设置页和测试；先展示依赖图，确认后再写入跟踪器。”第二张票才扩展到应用内提醒，不要先写一张‘全部数据库’票。
检查每张票的验收：从基准提交运行时应能失败，完成后一个新会话应能演示新行为。若某条依赖只是为了排成直线，就删掉；若规则变化横跨太多调用方无法保持每张票独立绿色，再讨论官方文档中的 expand–migrate–contract 例外。发布前先看清单，避免为很小的改动制造十几张任务。
逐条核对规格有没有落到任务
大规格拆票时加一道反向检查：把每条不可丢的需求、不变量和读写路径列在左边，右边填负责的任务与端到端验收。一个真实迁移案例中，初版 16 张票覆盖了生产任务和切换流程，却没有一张负责填充旧 API 读取的完整服务模型；单票检查通过，测试环境里部分页面仍是空的。对“保持原有行为”这样的要求，要指定读端验证，而不只验作业成功和数据行存在。任务发布到远程跟踪器后再读回正文，确认验收条件没有变成空白或占位符。