用途与定位 该技能定义一种手动编排模式：Fable 作为编排者，只做三件事——思考、解决分支决策、撰写任务规格；实际读代码、研究、编码与验证由子代理完成。资料称 Fable 的 token 是会话中最贵的资源，因此每一次本可交给子代理的工具调用都视为浪费额度。
硬性禁令
- 不写代码、不改文件；Fable 自己唯一调用的工具是 gh（issues）与流水线跟踪。
- 不亲自阅读代码库；需要上下文时派 Sonnet 侦察代理带着具体问题与回答格式去查，返回摘要。
- 不在 issue 正文没有完整规格时派发任务；对原始 issue 直接说“做 #2”被称为最大反模式，执行者会自行侦察并重复消耗 token。
- 默认不用 ultrathink / xhigh；High 足够，xhigh 仅用于真正困难的架构分支决策。
流水线 侦察（子代理）→ 规格写入 issue 正文（Fable 撰写）→ 按指针派发（执行者）→ 验证器（全新上下文）→ 验收 → 下一项。
规格内容 采用 issue-first 原则：任何任务（来自待办、对话或口头）都先成为带完整规格正文的 issue，再入队。规格是对 issue 正文的整体重写（gh issue edit N --body），原始描述并入“目标”一节；派发时正文即唯一完整文档。规格分为以下部分：目标（一句话描述合并后用户看到什么）、上下文（要改的文件与行号、接口约定、陷阱，且信息足以让执行者无需自行调研）、已解决的分支（每个分支给出决策与一行理由）、步骤（按文件编号的修改计划）、边界（不做什么）、DoD 与验证（验收清单与具体命令或场景）。分支由 Fable 自行解决、不阻塞流水线，用户在正文中可见并可在派发前推翻；若分支改变范围或涉及费用，则停下询问。规格就绪的检验标准：执行者无需打开任何文件做侦察、也无需提问即可完成任务。
派发与顺序 执行者提示是一段简短说明，指向 issue 正文而不重复规格，要求其在目录内严格按规格执行、不越界、不做产品决策、跑 DoD 验证、提交一个带 “closes #N” 的 conventional commit 到 main 且不自行关闭 issue，最后回报改动文件、验证结果与偏差。顺序由文件是否重叠决定：改同一文件的任务严格串行、直接提交 main；互不重叠的一组任务在 worktree 中并行，每组一个 worktree，合并顺序由编排者决定。执行者工作期间 Fable 不等待，而是继续为后续任务写规格。
验收 每项任务由全新上下文、窄提示的验证器子代理执行 DoD 中的命令或场景，只返回通过与否及所见，不做代码评审。失败处理：第一次交回同一执行者带问题清单修改；第二次失败换全新执行者并附验证器诊断；仍失败则标记 blocked、给用户简短诊断，流水线转去做独立任务。成功则关闭 issue 并附一行验收评论，不改动正文。最后一项是独立的 issue 评审：由一次 Sonnet 遍历全部 diff，检查方向由 Fable 在评审规格中指定，发现的 bug 通过同一评审者以修复提交解决。
沟通纪律 只给一条简短流水线状态（已完成、进行中、被什么阻塞）；不转述子代理报告，只给决策与下一步；进展仅依据本会话工具结果中的事实，未验证就明说；定期核对额度消耗，额度紧张时降低 effort 并合并任务，而不是跳过规格。
适用场景与限制 适用于以 GitHub issue 与 gh CLI 管理任务、希望用低成本子代理承担执行工作、由昂贵模型专注决策与规格的团队或个人开发流程。资料未提供具体安装命令、平台依赖版本、收费或价格信息，暂未提供。