设想这个场景：你和 agent 已经把一个功能聊透了——面试做过、to-spec 把需求写成了 spec，
但这份 spec 明显一个会话做不完。这时候如果把整份 spec 直接扔给 implement，
它做到一半上下文窗口就满了，后半程会在迟钝的状态下硬撑。
to-tickets 就是为这一步准备的：它把一份已定稿的计划、spec、或者当前对话，
拆成一叠票（ticket，这个 skill 自己对产出的叫法；票发布出去之后，
就是工单系统里的一条条 issue），每张票是一条能独立演示的垂直切片，
并且每张票都声明清楚「哪些票不完成、我就不能开工」。
拆完会问你对不对，你点头之后才发布到配置好的工单系统。
学完这节课，你能说清它的五步流程、两种发布形态、宽重构（wide refactor）这个唯一的例外，
以及行为不对时该去改哪一段文本。
0001 把 22 个已发布 skill 分成三层：配置层（跑一次性的初始设置）、编排层（你手动启动的完整流程）、
纪律层（被反复调用的基本功）。to-tickets 属于编排层，
而且是主流程（main flow：想法 → 交付的那条默认路线）上承上启下的一环。
它的 docs 页面把主流程写成一条链：
grill-with-docs ──► to-spec ──► to-tickets ──► implement ──► code-review
面试并把想法聊透 落成正式 spec ★ 本课：拆成 每张票构建，内部
一叠带依赖 驱动 tdd，收尾跑
关系的票 code-review
它的上游是 to-spec：交给他一份已经定稿、带着长长一串 user story（用户故事，
以「作为某角色，我想要某功能，以便得到某好处」的格式写成的需求条目）的 spec，
这就是要切的原料。它的下游是 implement：每张票开一个干净会话去做。
所以 to-tickets 是「想」和「做」之间的闸门——在它之前，所有工作都在对话和文档层面；
在它之后，工作变成工单系统里一条条可以被领取执行的 issue。
有一个关键的上下文纪律来自 ask-matt 的路由文件，叫 context hygiene（上下文卫生）：
从 grill 到 spec 再到 tickets，这几步应该留在同一个不中断的上下文窗口里——
在 /to-tickets 跑完之前，不要压缩（compact）也不要清空会话，
因为面试、spec、拆票是在同一摊思考上层层累加的。
而 /to-tickets 正好是这条窗口的终点：之后每张票各开一个新会话去 implement。
换句话说，to-tickets 是原始窗口里跑的最后一步。
如果会话在拆票之前就逼近 smart zone（聪明区，大约 12 万 token 之内模型推理仍然敏锐，
超过就开始变钝），正确做法不是硬撑，而是先用 /handoff 把上下文移交到新会话，再继续拆票。
to-tickets 把一份定稿的计划变成一张依赖图：
节点是能独立演示的垂直切片，边是「谁挡着谁」。
它产出的是工单系统里的 artifact（产物），不是代码——它一行业务代码都不写，
但它决定了之后每一个 implement 会话拿到什么样的工作单。
地图：0001 系统地图（编排层、上下文纪律一节）· 主流程链：docs/engineering/to-tickets.md 的 Where it fits · 上下文卫生：ask-matt/SKILL.md 的 Context hygiene 一节
SKILL.md 的 frontmatter（文件头部两块 --- 之间的元数据区）里写着
disable-model-invocation: true，同目录的 agents/openai.yaml 里又写了
policy.allow_implicit_invocation: false——两道锁说的是同一件事：
这个 skill 只能由你亲手输入 /to-tickets 启动，AI 不被允许自作主张地加载它。
docs 页面说得很直白：「You invoke this by typing /to-tickets — the agent won't reach for it on its own.」
这个设计和它的上游 to-spec、下游 implement 一致——主流程上的编排层 skill
都是 user-invoked，每一步迈出去都由人拍板。
/to-tickets：
它就地取材，把当前对话里已经聊定的计划当原料。这是最常用的姿势，
因为 context hygiene 要求 grill → spec → tickets 待在同一个窗口里。
/to-tickets .scratch/feat/spec.md
或一个 issue 编号、一条 issue URL：
它会先去把那份 spec 或 issue 抓下来，通读正文和全部评论，再开始拆。
适合计划已经在工单系统里、而你换了个新会话的情况。
SKILL.md 正文第一段就声明：「The issue tracker and triage label vocabulary should have
been provided to you — run /setup-matt-pocock-skills if not.」
这里的 issue tracker（工单系统）指托管一个仓库全部 issue 的工具——
GitHub Issues、Linear、或者本地 .scratch/ 目录的 markdown 约定都算（这是 CONTEXT.md 定下的统一词汇）。
triage label（分拣标签）是贴在 issue 上的状态机标记，比如 ready-for-agent。
这两个配置由 0002 讲的 setup-matt-pocock-skills 写进仓库的 docs/agents/ 目录；
没跑过 setup，to-tickets 不知道把票发到哪、也不知道该打什么标签，它会停下来让你先去 setup。
| 情境 | 该用 to-tickets 吗 |
更该去哪 |
|---|---|---|
| 计划或 spec 已定稿，工程量明显超过一个会话 | 该——这正是它存在的理由 | — |
| 想法还在脑子里，没聊透、也没写成 spec | 不该，原料还不存在 | 先 grill-with-docs 面试，再 to-spec 落成 spec |
| 改动小到一张票、一个会话装得下 | 可以跳过——0001 的弹性组合表明说，spec 一张票装得下时甚至可以直接进 implement | implement 直接对着 spec 干 |
| 别人提的 bug 报告、外来 feature request 堆在工单系统里 | 不该——那是分拣原料，不是定稿计划 | triage（而且 to-tickets 产出的票禁止再送回去分拣，见第 8 节） |
| 一团迷雾级别的大工程，连「要做哪些决定」都还不清楚 | 不该——现在拆票为时过早 | wayfinder 先画决策地图；雾散后它在 to-spec 处并回主流程，然后才轮到 to-tickets |
| 不知道该走哪条流程 | 不该 | ask-matt |
权威原文：skills/engineering/to-tickets/SKILL.md 的 frontmatter 与开头两段 · 调用锁：agents/openai.yaml · 叙事版：docs/engineering/to-tickets.md （aihero.dev/skills-to-tickets）
这个 skill 不是词汇地板（那是 0004、0005 的角色），但它有一套自己的行话，
全部在 SKILL.md 和 docs 页面里有明确含义。第一次读可以慢一点——
后面每一节都在用这几个词。
| 术语 | 定义（按一手材料压缩成平实中文） | 为什么重要 |
|---|---|---|
| Tracer bullet（曳光弹） | 借自射击训练的比喻：曳光弹和普通子弹同一条弹道，但发着光，让你立刻看见弹道对不对。 在这个 skill 里，指一张票只做一条最窄但完整的功能路径， 从 schema（数据库结构）穿过 API 一直穿到 UI 和测试，做完马上能演示 | 它是「这张票能不能安全交给一个 agent 独立做」的判据： 能独立演示或验证，agent 拿到票就不需要再找你要上下文 |
| Vertical slice（垂直切片） | 一刀竖着切下去，切过所有集成分层（schema、API、UI、测试）的窄条。 反义词是 horizontal slice（水平切片）：把某一整层一次做完， 比如「先把所有 schema 改完」——水平切片在所有层落地之前，没有任何东西能用 | 整个 skill 就建立在这一次区分上（docs 原文： 「The whole skill turns on one distinction.」）。拆出水平切片是本 skill 最常见的跑偏 |
| Blocking edge（阻塞边） | 每张票声明的依赖关系：「哪几张票必须完成，我才能开工」。 把票看成节点、把这个声明看成箭头，全部票合在一起就是一张有向依赖图。 一张没有任何 blocker 的票可以立即开工 | docs 说「The blocking edges are the whole point」—— 边才是这套拆法的全部意义：有了边，同一份产物才能既支持串行手做、又支持多 agent 并行（见第 7 节） |
| Frontier（前沿） | 当前所有「挡着它的票全部已完成」的票的集合。依赖图每完成一张票， 前沿就向前推进一步。如果票与票是纯线性链条，前沿就是「最上面那张没做的」， 从上往下做即可 | 它是执行阶段的行动清单：不管人做还是 agent 做， 任何时候问「现在能干什么」，答案就是前沿 |
| Prefactor（预重构） | 拆票之前先做的准备性重构，出处是 Kent Beck 那句话： 「Make the change easy, then make the easy change」（先把改变变容易，再做这个容易的改变）。 to-tickets 在探索代码库时会主动找预重构机会，并把它排在所有功能票之前 | 预重构不排第一，后面的每张功能票都会在不友好的地形上施工， 工作量被逐个放大 |
| Wide refactor（宽重构）与 blast radius（爆炸半径） | 宽重构是「一个机械改动」（改列名、改共享符号的类型）， 它的爆炸半径——一次编辑会波及多少调用点——摊开在整个代码库上， 一次改动同时炸断几千处调用，任何垂直切片都不可能落地时保持 CI 绿。 它是垂直切片规则唯一的例外，走 expand–contract（见第 5 节） | 认错它会把拆票带进死胡同：硬把宽重构成 tracer bullet， 每张票落地时仓库都是红的，票与票之间失去「各自可验证」的性质 |
SKILL.md 从头到尾管产出叫 ticket。所以本课的约定是：
拆的过程中叫「票」（尊重 skill 原文），发布到工单系统之后，每一张票就是一条 issue——
本地 tracker 下是一个 markdown 文件，远程 tracker 下是一条带标签的 issue。两个词指同一批东西的两个阶段。
SKILL.md 的 Process 一节把整个 skill 写成五步。下面逐步拆开，
每一步标出它读什么、写什么、以及最容易跑偏的地方。
默认就地取材——用当前对话上下文里已有的东西。如果你启动时传了引用 （一个 spec 路径、一个 issue 编号或 URL），它会先去把那份材料抓下来， 通读正文和全部评论，而不是只看标题。这一步不写任何文件。
如果还没探索过代码库，先探索，目的有两个：
domain-modeling 维护的 CONTEXT.md），
并且尊重要动的那片区域里的 ADR（架构决策记录，一份记录某个难以逆转的决定及其理由的文档）。
票之后要交给一个全新会话的 agent 执行，行话统一，新 agent 才不用猜「这里说的 account 是哪个 account」。
这是核心步骤。SKILL.md 用一段 <vertical-slice-rules> 框死四条规则：
然后给每张票标上 blocking edges。没有 blocker 的票可以立即开工。 注意第三条和第 2 条的呼应：票的体积上限不是一个拍脑袋的「人天估算」， 而是「一个 fresh context window 装得下」——这套系统的度量衡本来就是围绕 agent 的上下文窗口设计的。
拆完之后不直接发布。它先把方案以编号列表摆给你看，每张票展示三样：
然后问你三个问题：
「Iterate until the user approves the breakdown.」——你批准之前，一张票都不会发出去。
这一步是整个人工闸口：拆票是个判断活，垂直还是水平、粒度粗细、边画得对不对，
只有你知道业务上哪条路径真的独立可演示。行为不对时如果发现它跳过反问直接发布，
改的就是 SKILL.md 这一节（见第 10 节）。
发布按 setup 配置的工单系统分两种形态，细节多，单独立一节讲——见第 6 节。 这里只记住一句话：票是同一份票，两种形态只差阻塞边的表示方法。
SKILL.md 用加粗字体标明：「Wide refactors are the exception to vertical slicing.」
一个宽重构是单一机械改动——给数据库列改名、给共享符号换类型——
它的爆炸半径（一次编辑会波及多少调用点）摊开在整个代码库上：
一次改动同时炸断几千处调用，没有任何垂直切片能在落地时保持绿。
硬把它塞进 tracer bullet，每张票合并时仓库都是红的，「各自可验证」就不成立了。
所以宽重构改走 expand–contract（先扩后收）三段式，每段都是票：
| 阶段 | 做什么 | 为什么 CI 能保持绿 | 阻塞关系 |
|---|---|---|---|
| Expand（扩） | 把新形态加在旧形态旁边，两者并存，什么都不删 | 旧形态还在，所有现有调用点不动 | 通常是链首，无 blocker |
| Migrate（迁） | 把调用点分批搬到新形态上，批次按爆炸半径划分——按包、按目录切，每批一张票 | 旧形态仍然存在，批与批之间仓库始终可编译、可测试 | 每张迁移票都被 expand 票阻塞 |
| Contract（收） | 确认没有任何调用者之后，删掉旧形态 | 此时删旧形态已是无风险操作 | 被每一张迁移票阻塞 |
还有一个兜底变体：如果连迁移批次都无法各自保持绿（批与批之间有交叉依赖）， 保留同样的顺序，但让所有迁移票共享一条 integration branch（集成分支）， 它们共同阻塞最后一张「integrate-and-verify」（集成并验证）票——绿的承诺只在最后那张票上兑现。 注意这不是放弃纪律，而是把「绿」的承诺从「每张票」降级为「最后一张票」， 并且用阻塞边把这个承诺显式写出来。
原文：SKILL.md 第 3 节的 wide-refactor 段落 · 叙事版：docs/engineering/to-tickets.md 的 The wide-refactor exception
第 2.3 节说过，发布目标由 setup-matt-pocock-skills 配置。
SKILL.md 第 5 步把两种情况分开写，但强调「the tickets are the same either way,
only the shape of the blocking edges changes」——票是同一份票，只有边的形状变。
配置成本地 tracker 时，每张票写成一个文件，落在
.scratch/<feature-slug>/issues/<NN>-<slug>.md，
从 01 开始按依赖顺序编号（blocker 在前），
每票一个文件，绝不合并成一个总文件。
每个文件用 SKILL.md 自带的 local-ticket-template：
# <NN> — <票标题>
**What to build:** 这张票交付后哪条端到端行为能工作——从用户视角写，
不是「先改 schema 再写 API」这种逐层实现清单。
**Blocked by:** 阻塞它的票的编号/标题，或 "None — can start immediately"。
**Status:** ready-for-agent
- [ ] 验收标准 1
- [ ] 验收标准 2
这个目录约定不是 to-tickets 自己发明的，而是 setup 生成的本地 tracker 规范
（issue-tracker-local.md）：一个功能一个目录、spec 放
.scratch/<feature-slug>/spec.md、issue 一票一文件、
分拣状态写成文件顶部附近的 Status: 行。
to-tickets 只是遵守这个规范往里写。
配置成真实 tracker 时，每张票发成一条 issue，同样按依赖顺序发（blocker 在前）——
顺序在这里有实际功能意义：先发出来的 issue 才有真实编号，
后面的票才能在「Blocked by」里引用这些真实标识符。
平台有原生 blocking / sub-issue（子 issue）关系就用原生的，没有就在正文里写 Blocked by 列表。
每条 issue 用 SKILL.md 自带的 issue-template：Parent（父 issue 引用，
原料本来就是一条 issue 时才写）、What to build、Acceptance criteria、Blocked by 四节。
发布时会打上 ready-for-agent 这个分拣角色（triage role）对应的标签，
除非你另外指示。按 setup 的标签映射文件，这个角色的含义是
「Fully specified, ready for an AFK agent」——规格完整，可以交给一个无人值守的 agent。
SKILL.md 给的理由是：这些票「agent-grabbable by construction」——
它们在构造方式上（垂直、可独立验证、带验收标准）就保证了 agent 可以直接领走做。
发布规则与两个模板：SKILL.md 第 5 步及
<local-ticket-template>、<issue-template> ·
本地目录规范：setup-matt-pocock-skills/issue-tracker-local.md ·
标签含义：setup-matt-pocock-skills/triage-labels.md
docs 页面有个标题叫「One artifact, two readings」，说的是这套拆法最漂亮的一个性质： 阻塞边活在票里，与介质无关；介质只决定「有没有东西能并行地消费这些边」。
| 读法 | 本地 markdown | 远程 tracker |
|---|---|---|
| 边的表示 | 每个文件里的 "Blocked by" 文本行 | 平台原生 blocking / sub-issue 链接 |
| 怎么执行 | 按编号从上往下，你手动逐票推进，人在回路里 | 前沿上的票可以被多个 agent 同时领走——阻塞链接是机器可读的 |
| 并行度 | 串行（一张做完领下一张） | 可以并行一支 fleet（小队）：几张无相互阻塞的票同时开工 |
docs 最后一句把职责划得很清：「to-tickets produces the artifact — how you run it (sequential by hand, or a parallel fleet) is up to you.」 拆票 skill 只负责把图造对；用一条线程串行走完，还是开一个 agent 舰队并行吃前沿，是执行阶段的自由。
SKILL.md 最后一行：「Work the frontier one ticket at a time with /implement,
clearing context between tickets.」每张票开一个全新会话跑 /implement，
票与票之间清空上下文——这正是第 4.3 节「每张票要装进一个 fresh context window」的另一半：
拆票时按新窗口的容量切，执行时真的给每张票一个新窗口。
| 动作 | 写到哪里 | 说明 |
|---|---|---|
| 本地 tracker 发布 | 新建 .scratch/<feature-slug>/issues/<NN>-<slug>.md 一批文件（目录不存在会创建） |
每票一个文件，从 01 按依赖顺序编号；文件顶部带 Status: ready-for-agent |
| 远程 tracker 发布 | 在 GitHub / Linear 上新建一批 issue | 按依赖顺序发；建原生 blocking / sub-issue 关系（平台支持时）；打 ready-for-agent 标签（除非另指示） |
| 父 issue（原料是已有 issue 时） | 不关闭、不修改 | SKILL.md 明文禁止；处置权留给你 |
| 业务代码 | 一行都不写 | 拆票是工单系统层面的操作；写代码是 implement 的事 |
| spec 文件 / CONTEXT.md / ADR | 不写 | spec 是上游 to-spec 的产物；领域词和决策记录是 domain-modeling 的阵地 |
/implement（它会内部驱动 /tdd 先写测试，
收尾跑 /code-review，然后提交）。票与票之间清上下文。
SKILL.md 的对应段落（见第 10 节），
而不只是手改这一次的产物。
/triage 分拣一遍。
ask-matt 明文说：triage 只处理「不是你创建的」外来 issue；
to-tickets 的票发布时就带着 ready-for-agent，生来就是 agent 可领的成品。
setup-matt-pocock-skills domain-modeling
（配置 tracker 与标签词汇） （提供领域术语表）
│ │
▼ ▼
grill-with-docs ──► to-spec ──► ┌───────── to-tickets ─────────┐
（面试聊透） （落成 spec） │ 读：对话 / spec / issue │
│ 写：工单系统里的一叠票 │
└──────────────┬───────────────┘
│ 每张票一个新会话
▼
implement（内部驱动 tdd，
收尾跑 code-review）| Skill | 启动 | 和 to-tickets 的关系 |
|---|---|---|
| setup-matt-pocock-skills | User | 硬前置。它生成的 docs/agents/* 告诉 to-tickets 票发到哪、目录怎么排、标签字符串是什么。没跑过 setup，to-tickets 会停下来让你先去跑。 |
| to-spec | User | 典型上游。交出定稿 spec（带着长长的 user story 列表）作为拆票原料。ask-matt 的主流程把它俩写成连续两步。 |
| grill-with-docs | User | 更上游。context hygiene 要求从它到 spec 到 tickets 保持在同一上下文窗口。 |
| implement | User | 唯一下游消费者。每票一个新会话；内部驱动 tdd、收尾 code-review。SKILL.md 最后一行把它点名为执行器。 |
| tdd / code-review | Model / User | 不直接被 to-tickets 调用——它们在 implement 会话内部起作用。to-tickets 只在「验收标准」一栏里为它们预埋检查点。 |
| domain-modeling | Model | 间接依赖。to-tickets 第 2 步要求票的标题描述用项目领域术语表、尊重 ADR——那套词由 domain-modeling 维护在 CONTEXT.md。 |
| handoff | User | 安全阀。会话在拆票前逼近 smart zone 时，先 handoff 到新窗口再继续，别在迟钝状态下拆。 |
| wayfinder | User | 迷雾工程的入口。雾散后它在 to-spec 处并回主流程，之后照样走 to-tickets → implement。注意 wayfinder 的 decision ticket 和这里的实现票是两种东西：前者装「待决定的问题」，后者装「待构建的切片」。 |
| triage | User | 明确互斥。triage 分拣外来 issue；to-tickets 的票生来 ready-for-agent，禁止回流分拣。 |
| ask-matt | User | 路由器。主流程第 3 步的「多会话构建？」分支把你导到这里；本课的所有流程定位以它为准。 |
这个 skill 没有 sibling 参考文件（不像 codebase-design 那样带 DEEPENING.md），
全部纪律都在一个 SKILL.md 里，所以微调入口非常集中。
先看症状落在哪一步，再改对应那一段。
| 症状 | 先查 / 先改 | 不要误改 |
|---|---|---|
| 拆出来的票是水平切片（「先做全部 schema」「再写全部 API」） | to-tickets/SKILL.md 第 3 节的 <vertical-slice-rules> 四条规则 |
implement 的正文（它只负责执行，管不了切片形状） |
| 没问你就直接把票发出去了 | SKILL.md 第 4 节「Quiz the user」——「Iterate until the user approves」这句是否还在 | ask-matt 的路由句（路由不管拆票质量） |
| 票里塞满文件路径和大段代码，两周就过时 | SKILL.md 末尾模板之后那段「avoid specific file paths…」及 prototype 例外 | to-spec 的模板（它有同款规则，但各管各的产物） |
| 宽重构被硬拆成垂直切片，每张票落地都是红的 | SKILL.md 第 3 节 wide-refactor 段落（expand–contract 三段与 integration branch 变体） | tdd 的红绿循环纪律（它不管票的拓扑） |
| 票被发到错误的地方、或 agent 说不知道发到哪 | setup 生成的 docs/agents/issue-tracker*.md（0001 的建议：先查配置层产物，通常不用动 to-tickets 本身） |
SKILL.md 的发布段落——路径约定本来就故意不写死在 skill 里 |
| 标签打错（打了别的、或你们 tracker 的标签名不同） | setup 生成的 docs/agents/triage-labels.md 右列映射；SKILL.md 只说角色名 ready-for-agent |
triage/SKILL.md（它消费同一张映射表，但不为 to-tickets 的标签负责） |
| 本地票文件合并成了一个总文件、或编号乱序 | SKILL.md 第 5 步「numbered from 01 in dependency order…never a single combined file」与 local-ticket-template | wayfinder 的 map.md 约定（那是决策地图，不是实现票） |
| 父 issue 被自动关掉或改写了 | SKILL.md 第 5 步「Do NOT close or modify any parent issue.」 | —（这是明文禁令，恢复它即可） |
| agent 不等你就自己启动 to-tickets | SKILL.md frontmatter 的 disable-model-invocation: true 与 agents/openai.yaml 的 allow_implicit_invocation: false |
plugin.json 的发布列表（它本来就已发布；问题是调用锁，不是可见性） |
| 路由层面出了问题（不知道该不该拆票） | ask-matt/SKILL.md 主流程第 3 步的「多会话构建？」分支 |
to-tickets 自己的描述字段（触发词归路由器管） |
先别往回翻表，凭记忆答。选项的长度刻意对齐，不会从版式泄题。答案以本课和 SKILL.md 的原文为准。
本课主一手材料（请打开原文读，不要只背本页摘要）：
skills/engineering/to-tickets/SKILL.md
—— 五步流程、垂直切片四规则、宽重构例外、两个发布模板、frontier 执行纪律。
…/agents/openai.yaml
—— 调用锁：allow_implicit_invocation: false。
docs/engineering/to-tickets.md
（aihero.dev/skills-to-tickets）
—— 给人看的叙事版：「一份产物两种读法」「垂直 vs 水平」「主流程位置」。
速查页（本课同步）： reference/to-tickets.html
导航： 上一课 0009 to-spec （把对话落成 spec——本课的原料来源）。 总览仍回 0001 系统地图； 前置配置见 0002 setup； 上下文桥见 0006 handoff。
建议下一课（0011）： 0011 implement——to-tickets 拆出来的每一张票， 都将在一个全新会话里由 implement 执行：它内部驱动 tdd 先写测试、收尾跑 code-review，然后提交。 和本课的交接点就一句话：票造得对（垂直、可独立验证、边画得准），implement 会话就能无人值守地跑完。
SKILL.md、docs 页面和 ask-matt 的原文，不会临场编造。
做完检索练习后，回复「练习结果 / 哪里卡住 / 开 0011 或先补 0009」，我们安排下一课。