用途：把计划、规格或对话拆成一组工单，采用曳光弹（tracer bullet）式的垂直切片，每张工单声明阻塞它的其他工单。使用前 issue tracker 与分诊标签词汇应已提供，如未提供需先运行 /setup-ouyangjiahong-skills。
主要能力与流程：一、收集上下文，基于对话已有内容工作；若用户传入规格路径、issue 编号或 URL 等引用，抓取并读完整正文和评论。二、可选探索代码库，了解当前状态，工单标题与描述使用项目领域术语表词汇并遵守相关 ADR，同时寻找前置重构机会。三、起草垂直切片：每个切片切一条窄但完整的路径，穿过 schema、API、UI、测试等各层，可独立演示或验证，大小控制在一次全新上下文窗口能装下；前置重构应先做；为每张工单标注阻塞边。宽重构是例外，按扩展—收缩处理：先加新形式不破坏，再按影响半径分批迁移调用点，最后删除旧形式；批次无法独自保持绿灯时共享集成分支并阻塞一张最终集成验证工单。四、向用户确认，以编号列表展示每张工单的标题、被谁阻塞、交付什么，并询问粒度、阻塞边是否正确、是否需合并或拆分，迭代至批准。五、发布到已配置 tracker：本地文件写入 .scratch/<feature-slug>/issues/<NN>-<slug>.md，每张工单一个文件，按依赖顺序从 01 编号，Blocked by 列出依赖的编号/标题；真实 tracker（GitHub、Linear 等）按依赖顺序每张发一个 issue，有原生阻塞/子 issue 关系就用，否则把 Blocked by 设为阻塞 issue，除非另有指示套上 ready-for-agent 标签。做前沿即阻塞已完成的工单。不要关闭或修改任何父 issue。
限制：两种形式都避免具体文件路径或代码片段，例外是原型产出的决策密集片段可内联并注明来源。资料未提供具体安装命令、收费或平台支持范围。