specs-to-tickets

Specs → 工单

仅限人工操作。 只有在人类明确点名要求时，才开始执行。如果你是从其他 skill 跳转到这里的，请停止操作，并在运行任何步骤前取得明确确认。

这是 /decisions-to-specs 之后的流程。该 skill 已将 wayfinder 地图中的决策落实到仓库 spec 文件中，并在地图的 ## Specs settled 下记录了这些内容。此 skill 读取这些记录并生成实现工单——将每份 spec 交给 Matt 的 /to-tickets。

这是从规划转向构建的分界点：决策问题和 specs 已经处理完毕；从这里开始，流程是 tracer-bullet 工单 → /implement。

审批记录在跟踪器上。 第 2 步确认的范围和第 3 步确定的粒度由人类决定，而且会在本次会话结束时丢失。遵循 approval-policy skill：按其要求记录——在地图上记录本次运行的决策，在工单上记录某个切片的形态——不要把审批记录写进 spec 文件。

流程

1. 加载地图及其已确定的 specs

根据参数（issue URL 或编号）定位地图。读取 /decisions-to-specs 写入的 ## Specs settled 部分——其中列出了 spec 文件及其处置方式（new / updated / ADR）。

如果缺少该部分，请停止，并告知用户先运行 /decisions-to-specs <map>——目前没有已确定的 specs 可供拆分。

**完成条件：**已获取 spec 文件列表及其处置方式。

2. 确认要拆分的范围

向用户展示 spec 文件。默认集合 = 所有 new 和 updated spec。排除 ADR 条目——ADR 记录的是做出决策的原因，而不是可供构建的 spec；不会从中拆分出任何内容。创建任何工单之前，先确认要处理的集合。

**完成条件：**用户已批准要拆分的 specs。

3. 使用 /to-tickets 拆分每份 spec

首先，为整个流程一次性确定粒度。 /to-tickets 会在自己的第 3 步询问是遵循切片边界，还是以最小工单为目标；如果深入处理了五份 spec 后还要逐份询问，这一步就会变得无法使用。请在这里一次性向人类提问，然后将答案传入每次调用，避免重复询问。

对每份已批准的 spec，逐份运行 /to-tickets <spec-path>，并在调用中注明已确定的粒度。其余工作交由它自行完成——垂直 tracer-bullet 切片、阻塞依赖，以及发布到跟踪器（GitHub）。不要在这里重新实现其逻辑；此 skill 只负责将正确的 specs 传递给它。

/to-tickets 之所以设为 skill-callable，正是为了让此步骤能串联调用而不中断。直接串联调用；不要在此处内嵌转述其方法。

按 spec 和依赖顺序保留它创建的 issue 编号——下一步会用到这些编号。

**完成条件：**每份已批准的 spec 都已在跟踪器上生成工单，且所有切片都采用人类选定的同一粒度。

4. 将每张工单链接到地图，设为子 issue

/to-tickets 按设计不会处理父 issue，因此链接工作由此 skill 负责。阅读仓库的 issue 跟踪器文档（docs/agents/issue-tracker.md），查看 Wayfinding operations，了解此仓库如何将子 issue 链接到地图，并按其说明操作。若文档没有说明：

gh api --method POST repos/<owner>/<repo>/issues/<map>/sub_issues -F sub_issue_id=<ticket-db-id>

<ticket-db-id> 是工单的数字数据库 id（gh api repos/<owner>/<repo>/issues/<n> --jq .id），不是它的 #number。如果未启用子 issue，则改为在地图正文中使用任务列表，并在每张工单正文顶部添加 Part of #<map>。

按依赖顺序链接，先链接阻塞项，使地图的子 issue 列表按构建顺序排列。一个 issue 只能有一个父级：地图就是它的父级。/to-tickets 在工单之间设置的边属于依赖关系，应继续保持为依赖关系。

这些工单是地图的构建待办项，而不是 wayfinder 子项——它们带有 ready-for-agent，且不带任何 wayfinder:<type> 标签，以此确保 wayfinder 前沿只包含决策工作。

**完成条件：**第 3 步生成的每张工单都出现在地图的子 issue 列表中。

5. 将工单记录回地图

在地图正文末尾追加一个 ## Tickets 部分，按规格分组——每个规格后列出它生成的实现工单（名称 + 链接）。第 4 步中的子议题列表是实时链接；本部分补充该列表无法承载的规格分组信息，让地图完整指明从决策 → 规格 → 工单的路径。

## Tickets

- `src/<Package>/spec/<feature>.md` → #31, #32, #33
- `spec/<cross-cutting>.md` → #34, #35

完成标准： 地图列出了每个拆分规格对应的实现工单。

6. 报告

按规格列出创建的工单，并指出下一步是 /implement——每个工单使用全新上下文，优先处理阻塞项。提醒用户，这些实现工单就是构建待办列表；wayfinder 决策议题保持关闭，作为决策依据。

此步骤在流程中的位置

/wayfinder → 决策议题 → /decisions-to-specs → 规格文件 + ## Specs settled → /specs-to-tickets → 每个规格执行 /to-tickets → GitHub 实现工单 → /implement。