用途
to-issues 用于把一个计划、规格说明（spec）或 PRD 拆解成 issue tracker 上可独立领取的 issue。它采用垂直切片（tracer bullets）的方式：每个 issue 是一条贯穿所有集成层的端到端薄切片，而不是某一层的水平切片。适用于用户希望转换现有计划或需求文档为可执行工单的场景。
主要能力
- 从当前对话上下文中收集信息；若用户以参数形式传入 issue 引用（issue 编号、URL 或路径），则从 issue tracker 获取并读取其完整正文与评论。
- 可选地探索代码库以理解代码现状；issue 标题和描述使用项目领域词汇，并遵守所涉及区域的 ADR。
- 将计划拆解为 tracer bullet 形式的垂直切片。切片可标记为 HITL 或 AFK：HITL 切片需要人工交互（例如架构决策或设计评审）；AFK 切片无需人工交互即可实现并合并。尽可能优先选择 AFK。
- 以编号列表向用户呈现拆解方案，每个切片展示：标题（简短描述性名称）、类型（HITL / AFK）、被哪些切片阻塞（如有）、覆盖哪些用户故事（若源材料包含）。并向用户确认：粒度是否合适（过粗/过细）、依赖关系是否正确、是否需要合并或进一步拆分、HITL 与 AFK 的标注是否正确。迭代直到用户批准拆解方案。
- 将批准后的切片发布到 issue tracker：每个切片发布一个新 issue，使用指定的 issue 正文模板，并应用 needs-triage 标签，使每个 issue 进入常规 triage 流程。按依赖顺序（阻塞项在前）发布，以便在“Blocked by”字段中引用真实的 issue 标识符。
issue 正文模板
发布时使用以下结构（如有父 issue 则引用，否则省略该部分）：
- 对父 issue 的引用（如果来源是现有 issue，否则省略此部分）
- What to build：对该垂直切片的简明描述，描述端到端行为，而非逐层实现。
- Acceptance criteria：验收标准列表（示例中为多条复选项）。
- Blocked by：对阻塞工单的引用（如有），若无阻塞则写“None - can start immediately”。
不要关闭或修改任何父 issue。
使用方式
Issue tracker 为 GitHub，本仓库的 issue 和 PRD 以 GitHub issue 形式存在，所有操作使用 gh CLI：
- 创建 issue：
gh issue create --title "..." --body "..."。多行正文使用 heredoc。 - 读取 issue：
gh issue view <number> --comments，用 jq 过滤评论，并同时获取标签。 - 列出 issue：
gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'，配合适当的--label与--state过滤条件。 - 评论 issue：
gh issue comment <number> --body "..." - 添加 / 移除标签：
gh issue edit <number> --add-label "..."/--remove-label "..." - 关闭：
gh issue close <number> --comment "..." - 仓库从
git remote -v推断——在克隆目录内运行时 gh 会自动完成。
当某技能要求“publish to the issue tracker”时，即创建一个 GitHub issue；当要求“fetch the relevant ticket”时，即运行 gh issue view <number> --comments。
适用场景
- 将已有的计划、规格说明或 PRD 转换为可独立领取的工单。
- 需要对拆解粒度、依赖关系和人工介入点（HITL/AFK）进行确认的团队协作流程。
- 使用 GitHub issue 与 gh CLI 作为工作流基础设施的项目。
限制
- 资料中仅说明 issue tracker 为 GitHub，是否支持其他 issue tracker 暂未提供。
- 除上述流程与 gh CLI 命令外，未提供其他功能、收费、价格或平台信息。