用 aihero.dev 的 to-tickets 拆分工单时，先给一份已经确认好的需求规格，让助手逐条列清楚每个交付动作、验收标准和阻塞项。等你确认拆分结果没问题，再按仓库配置把工单存下来。下面是待办归档功能的完整练习输入，装了对应技能的仓库直接就能用。
用 to-tickets 拆工单需要准备什么？
提前准备好已经确认的需求规格，或者在当前会话里明确说清用户行为、功能范围和验收结果。操作前还要先给目标仓库配置好工单跟踪器。
打开你要用来练习的仓库里的编码助手，确认已经装了 to-tickets，而且通过 setup-matt-pocock-skills 把工单跟踪器设置成本地 Markdown 模式，再把下面这段需求发给助手。
给待办列表增加单条任务归档。归档后任务从默认列表隐藏，归档视图仍可看到该任务。未归档任务保持原状。本轮不做恢复、永久删除或批量归档。请先列出建议工单、验收条件和依赖，等我确认再写入。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
把输入规则和写入条件一起说清楚
你可以直接发本文给的示例需求，也可以先存成规格文件，再把文件路径发给助手。开始拆分前先确认 docs/agents/issue-tracker.md 配置的是本地 Markdown，别把练习生成的结果直接同步到团队的在线工单系统里。
怎么判断工单能独立验收？
每张工单对应一个能直接演示的用户操作。只有前一张工单的输出确实是当前工单的开工必要条件，才把它标记为阻塞项。
调用 to-tickets 之后，挨个检查每张工单能不能独立跑出可验证的结果。正常拆分逻辑是第一张做归档动作和默认列表过滤，第二张做归档视图。如果归档视图必须依赖第一张工单生成的归档状态，就标注好两者的阻塞关系。要是你的仓库里本来就已经有归档状态了，得重新核对一遍要不要加这条依赖。
实际生成的工单，每个条目都要有明确的交付内容和对应的阻塞项。
验收标准要写成可以直接落地检查的操作，比如新建两条任务，只归档其中一条，确认默认列表里还能看到另一条。这样你做完功能直接就能对照着核对结果，这些操作也可以直接转成测试用例。
逐张审阅交付与依赖
- 第一张先实现单条归档与默认列表过滤。准备两条测试任务，只归档其中一条，验证另一条仍正常显示。
- 第二张提供归档视图。检查已归档任务正常显示，普通任务不会混入归档视图。
- 确认第二张是否必须依赖第一张建立的归档状态。如果仓库原本已有归档状态，重新核对阻塞项设置是否合理。
本地 Markdown 工单保存在哪里？
选用本地跟踪器时，已批准的工单按依赖顺序分别写入 .scratch/<feature-slug>/issues/</feature-slug>。你可以逐个打开文件，核对每份文件的验收条件和阻塞编号是否正确。
确认拆分结果没问题之后，让助手保存到本地跟踪器。官方约定是一张工单一份文件，位于 .scratch/<feature-slug>/issues/</feature-slug>，前置工单排在前面。逐个打开文件，核对验收条件和阻塞编号。如果只得到一份合并清单，先确认初始化时选了本地 Markdown，再请助手按一张工单一份文件的规则重新保存。
检查实际目录和单张工单
批准后，让助手报告写入路径。使用本例的功能名时，可在仓库根目录执行下列命令查看文件，文件名由拆分结果决定，以实际产物为准。
ls -1 .scratch/task-archive/issues/
团队使用在线跟踪器时，同一份规格也可拆成多张工单。之前作者的案例里，#643 和 #644 都关联父规格 #642。
打开第一张文件，确认写有交付行为、阻塞项和可以逐条检查的验收条件。再打开第二张核对阻塞编号是否指向实际存在的文件。如果目录不存在，先查看助手是否还在等你批准，或是否用了不同的功能名。
