用途：把计划、规格或对话内容拆解为小而聚焦的工单，每个工单覆盖一个具体变更，并声明阻塞它的其他工单。使用前需已配置问题追踪器与分诊标签词汇，否则提示用户运行 /ai-setup-skills。
主要能力与流程：1) 收集上下文，基于对话内容，或读取用户传入的规格路径、issue 编号或 URL 的正文与评论；2) 可选地探索代码库，使用项目领域词汇，遵守相关 ADR，并寻找预重构机会；3) 起草小任务，每个工单含明确验收标准与至少一类测试。HTTP 处理器与 HTTP 传输层要求通过 HTTP 接口做端到端测试，不用单元测试，此规则优先；无其他实例依赖的代码只需单元测试；有依赖（如用例、仓库）的代码优先集成测试。按变更所需上下文限定范围，拆分可独立验证的变更，预重构排在其依赖项之前，并为每个工单标注阻塞边；4) 以编号列表向用户展示标题、被谁阻塞、交付内容，并询问粒度、阻塞边是否正确、是否需合并或拆分，迭代至用户批准；5) 发布到已配置追踪器。本地文件写入 .scratch/<feature-slug>/issues/<NN>-<slug>.md，Obsidian 写入 <vault>/engineering/<project>/workplans/<feature>/issues/<NN>-<slug>.md（<vault> 取自 $OBSIDIAN_AI_VAULT，用绝对路径），均按依赖顺序从 01 编号，每个工单一个文件。真实追踪器（GitHub、Linear 等）按依赖顺序发布，使用平台原生阻塞/子问题关系，否则设置 Blocked by，并默认应用 ready-for-agent 标签。不要关闭或修改任何父 issue。
限制：工单中避免具体文件路径或代码片段，例外是原型中能更精确表达决策的片段（状态机、reducer、schema、类型形状），需注明来自原型并只保留决策相关部分。具体追踪器适配细节与模板以资料为准，其余未提供。