to-tickets-agentic

拆解为 Ticket

将计划、规范或对话拆分为 tracer-bullet 垂直切片。每个 Ticket 都要声明其阻塞项、实施通道和测试接缝。

应配置问题跟踪器和分诊标签词汇。若缺少这些配置，请运行 /setup-agent-skills。

1. 收集上下文

使用当前对话。当用户提供规范、问题或 URL 时，阅读其完整正文和评论。阅读相关领域文档和 ADR。

2. 按需探索

探索足够多的代码，以了解现有接缝、可能的重叠和预重构机会。优先让变更变得容易，再去轻松地实现变更。

3. 起草垂直切片

每个 Ticket 必须：

• 在每个受影响层中切出一条范围狭窄但完整的路径；
• 能够独立演示或验证；
• 适合在一个全新的 Agent 上下文中完成；
• 标明其阻塞边；并且
• 将前置的预重构拆分为更早的 Ticket。

对于无法以垂直切片形式通过绿灯测试的大范围机械重构，使用扩展-收缩 Ticket：先扩展并引入新形式，再按影响范围分批迁移调用方，最后在所有迁移完成后收缩。

4. 与用户分配通道

展示带编号的草案。对每个 Ticket，列出其标题、阻塞项、交付行为、建议通道和待测接缝。确认：

• 粒度和阻塞边；
• 合并或进一步拆分；
• AFK 通道还是有人值守通道；以及
• 共享同一执行前沿的 Ticket 之间的文件或模块重叠。

通道判断依据是接缝：

• AFK。 公共接缝已经存在或现在已经确定，因此可以在 Ticket 中明确列出。
• 有人值守。 接缝或接口设计仍存在需要人工判断的问题。

同一前沿上的 Ticket 必须涉及互不重叠的区域。即使两个重叠的 Ticket 在逻辑上互不阻塞，也要在它们之间添加阻塞边；多个自主运行同时修改共享文件会造成不必要的合并冲突。

持续迭代，直到用户批准每个 Ticket 及其通道。

5. 发布

每个标题都必须且只能以 [Ticket] 为前缀。

• 本地跟踪器。 按依赖顺序，在 .scratch/<feature>/issues/<NN>-<slug>.md 下为每个 Ticket 编写一个文件。
• 实际跟踪器。 按依赖顺序创建 Ticket；如果支持，将其作为原生子项关联到父项，然后在第二轮设置原生阻塞边。确认父项列出了所有子项。

对 AFK Ticket 应用已配置的 ready-for-agent 标签，对有人值守的 Ticket 应用 ready-for-human 标签。保持父规范不变，并维持开启状态。

子问题关系和被阻塞关系并不相同：前者将工作归入父项之下；后者控制执行顺序。

Ticket 模板

# [Ticket] <title>

## Parent

<parent reference, when one exists>

## What to build

<the end-to-end behavior this ticket delivers>

## Acceptance criteria

- [ ] <observable criterion>

## Seams under test

- <public interface and behavior, or "Attended. Seams to be agreed at the keyboard">

## Blocked by

- <blocking ticket, or "None. Can start immediately">

描述接口和行为，而非文件路径。只有当原型代码片段能比文字更准确地记录已确定的决策时，才可以将其纳入。

发布完成的条件是：每个获批的 Ticket 都已创建，带有正确的通道标签和接缝，在适用时已关联到父项，并且每条阻塞边都已体现。