to-tickets

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# 拆成 Tickets

把计划、spec 或对话拆成一组 **tickets** —— tracer-bullet 垂直切片，每张声明会 **block** 它的那些 tickets。

Issue tracker 和分诊标签词汇本应已提供给你——若没有，运行 `/setup-matt-pocock-skills`。

## 流程

### 1. 收集上下文

从对话上下文里已有的内容出发。若用户以参数传入引用（spec 路径、issue 编号或 URL），拉取并阅读其完整正文和 comments。

### 2. 探索代码库（可选）

若尚未探索代码库，先探索以了解代码当前状态。Ticket 标题和描述应使用项目领域词汇表中的用语，并尊重你所触及区域的 ADRs。

寻找预先重构代码以使实现更容易的机会。"Make the change easy, then make the easy change."

### 3. 起草垂直切片

把工作拆成 **tracer bullet** tickets。

<vertical-slice-rules>

- 每个切片切出一条窄但完整的路径，穿过每一层（schema、API、UI、tests）——垂直，不是某一层的水平切片
- 完成的切片本身可演示或可验证
- 每个切片的体量适合装进单个全新的 context window
- 任何预先重构应先做

</vertical-slice-rules>

给每张 ticket 其 **blocking edges** —— 必须先完成才能开始的其他 tickets。没有 blockers 的 ticket 可以立即开始。

**宽重构是垂直切片的例外。** **宽重构** 是一次机械变更——重命名一列、给共享符号改类型——其 **blast radius** 扇过整个代码库，一次编辑会同时弄碎成千上万个调用点，没有任何垂直切片能落地变绿。不要硬塞进一颗 tracer bullet；按 **expand–contract** 排序。先 expand：在旧形态旁加入新形态，这样什么都不会碎。然后按 blast radius 分批迁移调用点（按 package、按目录），每批是自己的一张 ticket，被 expand 阻塞，因为旧形态仍在，所以批与批之间 CI 保持绿。最后 contract：一旦没有调用者，删除旧形态，这张 ticket 被每一批 migrate 阻塞。若连各批也无法单独保持绿，仍保持该序列，但让它们共享一条集成分支，全都阻塞最后一张 integrate-and-verify ticket——只在那里承诺绿。

### 4. 向用户提问

把提议的拆分以编号列表呈现。对每张 ticket，展示：

- **Title**：简短描述名
- **Blocked by**：哪些其他 tickets（若有）必须先完成
- **What it delivers**：这张 ticket 让端到端行为中的哪部分能工作

问用户：

- 粒度感觉对吗？（太粗 / 太细）
- 阻塞边是否正确——每张 ticket 是否只依赖真正卡住它的 tickets？
- 是否应合并或进一步拆分某些 tickets？

迭代直到用户批准该拆分。

### 5. 把 tickets 发布到已配置的 tracker

发布已批准的 tickets。**如何发布**取决于 `/setup-matt-pocock-skills` 配置的 tracker——tickets 本身一样，只是阻塞边的形态不同：

- **本地文件** → 在 `.scratch/<feature-slug>/issues/<NN>-<slug>.md` 下每个 ticket 写一个文件，从 `01` 起按依赖顺序编号（blockers 在前）。每个文件的 "Blocked by" 列出它所依赖的编号/标题。使用下面的按 ticket 文件模板——一个文件一张 ticket，绝不要做成单个合并文件。
- **真实 issue tracker（GitHub、Linear、…）** → 按依赖顺序（blockers 在前）为每张 ticket 发布一个 issue，以便每张 ticket 的阻塞边能引用真实标识符。平台有原生 blocking / sub-issue 关系就用它；否则把每张 ticket 的 "Blocked by" 设为阻塞它的 issues。除非另有指示，打上 `ready-for-agent` 分诊标签——这些 tickets 构造上就可被 agent 领取。

处理 **frontier**：blockers 都已完成的任何 ticket。对纯线性链来说就是从上到下。

不要关闭或修改任何父 issue。

<local-ticket-template>

# <NN> — <Ticket title>

**What to build:** 从用户视角看，这张 ticket 让哪段端到端行为真正能工作——不是一层一层的实现清单。

**Blocked by:** 卡住这张 ticket 的那些 tickets 的编号/标题，或 "None — can start immediately"。

**Status:** ready-for-agent

- [ ] 验收标准 1
- [ ] 验收标准 2

</local-ticket-template>

<issue-template>

## Parent

tracker 上父 issue 的引用（若来源是已有 issue；否则省略本节）。

## What to build

从用户视角看，这张 ticket 让哪段端到端行为真正能工作——不是一层一层的实现。

## Acceptance criteria

- [ ] 验收标准 1
- [ ] 验收标准 2

## Blocked by

- 每张阻塞 ticket 的引用，或 "None — can start immediately"。

</issue-template>

无论哪种形态，避免具体文件路径或代码片段——它们很快过时。例外：若某个原型产出的片段比散文更能精确编码一项决策（状态机、reducer、schema、类型形态），内联它并简短注明来自原型。裁到决策含量高的部分——不是可运行的 demo，只是重要片段。

From shenjunjian/matt-skill-cn, MIT.

More from shenjunjian/matt-skill-cn