用途：在实现前为 User Story 生成可执行的任务计划，把故事拆成有序、可追溯的任务草稿。典型触发如“plan tasks for #123”“break this story into steps”。不适用于直接写代码、PR 评审或未经确认的 GitHub 变更。
必要输入：目标 issue 引用（owner/repo#number 或 URL）、规划深度（minimal/standard/detailed）、运行模式（draft-only、draft+publish-ready、publish-now）。默认深度 standard、模式 draft-only；任何变更前需同一轮显式确认。
主要能力：先探测可用技能并分类草稿模式——orchestrated（fusion-issue-authoring 与 fusion-issue-author-task 均可用）、direct-subordinate（仅后者，仅草稿）、inline（均无，用内置最小结构）。研究故事标题、正文、验收标准、场景、祖先链、已有子 issue 与相关链接，提取结果、约束与非目标、验证点，构建按依赖排序的任务，每项含目标、范围边界、交付物、验证方式与 AC 映射。草稿前做“魔鬼代言人”审查，检查架构歧义信号（未决设计、隐式 API/数据模型契约、无阻塞关系的探索任务、模糊或循环依赖、归属不清），两个及以上信号时自动路由或运行内联清单。
使用方式：草稿写入 .tmp/TASK-<nn>-<slug>.md，计划预览写入 .tmp/USER-STORY-TASK-PLAN-<context>.md。发布需同轮显式确认，并委托 fusion-issue-authoring 执行，优先子代理调用；本技能不直接调用 MCP 写工具。N>5 时提示限流风险并建议分批。修复模式可补 Issue Type 与父链接，须幂等并做飞行后验证。
限制：实验性、不稳定；缺失首选技能时优雅降级；不得在未确认时变更 GitHub；不得无标记地推断验收标准；发布/修复模式下缺失 Issue Type 或父链接视为失败。输出按固定标题顺序，并始终标注 Status: Awaiting user approval。