name: to-issues
description: Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.
disable-model-invocation: true
category: “project-management”
risk: “safe”
source: “community”
source_repo: “mattpocock/skills”
source_type: “community”
date_added: “2026-06-19”
author: “Matt Pocock”
license: “MIT”
license_source: “https://github.com/mattpocock/skills/blob/main/LICENSE”
tags:

• project-management
• workflow
• coding-agents
  tools:
• claude-code
• codex-cli
• cursor

拆分为 Issue

何时使用

当此工作流与用户请求匹配时使用：使用曳光弹（tracer-bullet）垂直切片将计划、规范或 PRD 拆分为项目问题追踪器上可独立领取的 issue。

来源：mattpocock/skills（MIT）。

将计划拆分为可独立领取的 issue，使用垂直切片（曳光弹）方式。

问题追踪器和分诊标签词汇表应该已经提供给你——如果没有，请运行/setup-matt-pocock-skills。

流程

1. 收集上下文

从对话上下文中已有的内容入手。如果用户将 issue 引用（issue 编号、URL 或路径）作为参数传入，请从问题追踪器获取它，并阅读其完整正文和评论。

2. 探索代码库（可选）

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

寻找预重构（prefactor）代码的机会，使实现更容易。“先把改动变容易，再做出容易的改动。”

3. 起草垂直切片

将计划拆分为曳光弹issue。每个 issue 是一个贯穿所有集成层端到端的细垂直切片，而不是某一层的水平切片。

• 每个切片都提供一条穿过每一层（架构、API、UI、测试）的狭窄但完整的路径
• 完成的切片可以独立演示或验证
• 任何预重构都应先完成

4. 询问用户

将拟议的拆分以编号列表形式呈现。对每个切片，显示：

• 标题：简短描述性名称
• 被阻塞于：哪些其他切片（如果有）必须先完成
• 涵盖的用户故事：这解决了哪些用户故事（如果源材料中有）

询问用户：

• 粒度是否合适？（太粗 / 太细）
• 依赖关系是否正确？
• 是否应该合并或进一步拆分某些切片？

反复迭代，直到用户批准拆分方案。

5. 将 issue 发布到问题追踪器

对每个已批准的切片，向问题追踪器发布一个新 issue。使用下面的 issue 正文模板。这些 issue 被视为可供 AFK（无人值守）代理使用，因此除非另有指示，请使用正确的分诊标签发布。

按依赖顺序发布 issue（先阻塞者），这样你可以在"被阻塞于"字段中引用真实的 issue 标识符。

指向问题追踪器上父 issue 的引用（如果来源是现有 issue，否则省略此部分）。

要构建什么

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

避免具体的文件路径或代码片段——它们很快就会过时。例外：如果原型产生了比文字更精确地编码某个决策的片段（状态机、reducer、schema、类型形状），请将其内联在这里，并简要注明它来自原型。只保留富含决策的部分——不是可运行的演示，只是重要的内容。

验收标准

• 标准 1
• 标准 2
• 标准 3

被阻塞于

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

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

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

局限性

• 当工作流指定上游工具、账户、API 密钥或本地设置时，需要它们。
• 未经用户明确批准，不授权破坏性、生产环境、付费或对外发送消息的操作。
• 在将生成的工件或建议视为最终结果之前，请对照用户的真实来源进行验证。