用途：把产品需求文档（PRD）转换为一系列可独立领取的本地 Markdown issue 文件。使用纵向切片（曳光弹）思路，每个 issue 是贯穿所有集成层的薄纵切面，而非单层横向切片。生成的 issue 面向初级开发者，需说明要构建什么、为何按此顺序、需要验证什么、以及要避免的假设或陷阱，使其无需重读整段对话即可领取一个 AFK issue。
主要能力：先定位 PRD（询问用户文件路径，如 docs/prds/<slug>.md，若不在上下文则读取）；可选地探索代码库以理解现状，沿用项目领域词汇并尊重相关 ADR 或架构文档；将 PRD 拆为曳光弹切片，可标记为 HITL（需人工交互，如架构决策或设计评审）或 AFK（无需人工交互即可实现并合并），尽量优先 AFK；随后向用户确认。
使用方式：以编号列表呈现拆解结果，每项含标题、类型、被谁阻塞、覆盖的用户故事；向用户询问粒度是否合适、依赖关系是否正确、是否需要合并或拆分、HITL/AFK 标记是否正确，反复迭代直到用户批准；获批后按依赖顺序在 docs/issues/<prd-slug>/<NN>-<issue-slug>.md 创建文件（编号 01、02、03…），并告知用户所有文件路径。
issue 内容：包含「要构建什么」（描述端到端行为，引用 PRD 章节而非重复内容，避免具体文件路径或代码片段，除非某片段比文字更精确地表达决策）、分步实施计划（每步说明改什么、为何在此位置、影响哪个模块/接口/契约/模式/工作流/测试面、下一步前验证什么、需避免的常见陷阱）、验收标准、Blocked by（无则写 None - can start immediately）、覆盖的用户故事编号。不得修改父 PRD 文件。
适用场景：需要将 PRD 转为可分配 issue 的软件开发流程。限制：不修改父 PRD；依赖用户提供文件路径并参与确认；未提供收费、平台或效果等信息。