---
name: to-issues
description: 将计划、规范或 PRD 使用示踪子弹垂直切片分解为项目 Issue 跟踪器上可独立获取的 Issue。当用户想要将计划转换为 Issue、创建实现工单或将工作分解为 Issue 时使用。
---

# 转化为 Issue

使用垂直切片（示踪子弹）将计划分解为可独立获取的 Issue。

Issue 跟踪器和分类标签词汇应已提供给你——如果还没有，运行 `/setup-matt-pocock-skills`。

## 流程

### 1. 收集上下文

从对话上下文中已有的内容开始。如果用户传递了一个 Issue 引用（Issue 编号、URL 或路径）作为参数，从 Issue 跟踪器中获取它并读取其完整正文和评论。

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

如果你还没有探索代码库，请这样做以了解代码的当前状态。Issue 标题和描述应使用项目的领域词汇表，并尊重你触及区域中的 ADR。

### 3. 起草垂直切片

将计划分解为**示踪子弹** Issue。每个 Issue 是一个薄的垂直切片，贯穿所有集成层端到端，**不是**一个层的水平切片。

切片可以是 'HITL'（需要人类介入）或 'AFK'（可无人干预）。HITL 切片需要人类交互，如架构决策或设计评审。AFK 切片可以在没有人类交互的情况下实现和合并。尽可能优先选择 AFK 而不是 HITL。

<垂直切片规则>
- 每个切片提供一个狭窄但**完整的**路径通过每一层（模式、API、UI、测试）
- 完成的切片可独立演示或验证
- 宁愿多而薄的切片，也不要少而厚的
</垂直切片规则>

### 4. 询问用户

以编号列表呈现建议的分解。对每个切片，展示：

- **标题**：简短描述性名称
- **类型**：HITL / AFK
- **被阻塞**：必须首先完成哪些其他切片（如果有）
- **覆盖的用户故事**：这解决了哪些用户故事（如果源材料有的话）

问用户：

- 粒度感觉合适吗？（太粗 / 太细）
- 依赖关系正确吗？
- 任何切片应该合并或进一步拆分吗？
- 正确的切片被标记为 HITL 和 AFK 吗？

迭代直到用户批准分解。

### 5. 将 Issue 发布到 Issue 跟踪器

对每个批准的切片，在 Issue 跟踪器上发布一个新的 Issue。使用下面的 Issue 正文模板。应用 `needs-triage` 分类标签，使每个 Issue 进入正常分类流程。

按依赖顺序发布 Issue（先解决阻塞项），以便你可以在"被阻塞"字段中引用真实的 Issue 标识符。

<Issue 模板>
## 父级

对 Issue 跟踪器中父 Issue 的引用（如果源是现有 Issue，则包含此部分，否则省略）。

## 要构建什么

此垂直切片的简洁描述。描述端到端行为，而不是逐层实现。

## 验收标准

- [ ] 标准 1
- [ ] 标准 2
- [ ] 标准 3

## 被阻塞

- 对阻塞工单的引用（如果有）

如果没有阻塞项，则写"无——可以立即开始"。

</Issue 模板>

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