prd-to-issueslisted

# PRD 到研发 Issue 拆解（prd-to-issues） ## 中文速查 - 中文名：PRD 到研发 Issue 拆解 / implementation issues - 英文稳定名：`prd-to-issues` - 分类：产品与 PRD / 工程交付 - 你可以这样叫我：`把 PRD 拆成 issue`、`需求文档拆任务`、`生成 GitHub issues`、`PRD 拆工单`、`拆 implementation issues`、`按 vertical slice 拆开发票` - 适合：把已经成型的 PRD、handoff、产品方案或 GitHub PRD issue 拆成端到端可验证、可独立领取的 GitHub implementation issues - 不适合：从零起草 PRD，改用 `prd-architect`；评审 PRD 缺口，先用 `prd-review`；制定文件级实现计划、测试策略和提交节奏，交给 Superpowers `writing-plans` ## Overview 这个 Skill 把 PM 侧需求交付物转成研发可领取的 issue backlog。核心原则是 vertical slice：每个 issue 应该交付一条窄但完整、可 demo、可验收的端到端路径，而不是按“前端 / 后端 / 测试 / 文档”横向拆票。 默认先输出 issue draft 和覆盖矩阵。只有用户明确确认后，才创建或修改 GitHub issues。 ## Workflow 1. 定位输入来源： - 当前上下文中的 PRD / handoff / 产品方案。 - 本地文件路径。 - GitHub issue URL 或编号；需要时用 `gh issue view <number> --comments` 读取。 - 其他文档摘要；如果无法直接访问，要求用户提供正文或可读取路径。 2. 确认输出模式： - `draft-only`：只输出 issue 拆解草案。默认模式。 - `publish-after-approval`：先出草案，用户确认后再创建 GitHub issues。 - 不要在没有用户确认时直接 `gh issue create`。 3. 运行 PRD readiness gate。按 `references/prd-readiness-checklist.md` 判断 PRD 是否足够拆 issue： - 目标用户、问题、非目标、主流程、验收口径、关键约束、未决问题。 - 如果阻断信息缺失，先提出最少问题或建议回到 `prd-review`。 4. 读取必要工程上下文： - 项目 README、架构说明、ADR、领域词汇、已有 routes/schema/API/UI 约定。 - `.github/ISSUE_TEMPLATE/`、label/type/milestone 约定。 - 现有 GitHub issues，避免重复创建。 5. 拆 vertical slices。先读取 `references/vertical-slice-rules.md`： - 每个 issue 必须端到端可验证。 - 优先小而完整的 AFK issue。 - 需要架构决策、设计确认、产品取舍或人工审查时标为 HITL。 - 不要把未确认决策伪装成 AFK 任务。 6. 建立覆盖矩阵： - 每个 PRD s