fable-opus

Fable Mode — Opus（v6，主线程编排）

系列版本：v6（2026-10-10）。

v4 移除了 v3 中基于具名 Agent 的路由。这种设计依赖自定义 Agent 定义（fable-orchestrator、fable-worker-sonnet、fable-worker-haiku、fable-verifier），但 Cowork 这类仅支持技能的界面上并不存在这些定义，因此每次调用都会落入备用路径，而文件仍将已失效的路径描述为主路径，v3 的结构性保障也从未真正生效。现在备用路径是唯一的路径，并已直接说明。

v5 变更：此技能现在位于阶梯顶端。Fable 5.1 runner 已从技能集中移除（其自身基准测试显示，这一层级的正确性没有任何提升），因此升级到 Opus 之上时应转交给用户，而不是交给另一个 runner。

v6 变更（2026-10-10，云端审查）：v5 要求生成的 Opus worker 再生成自己的 Sonnet/Haiku worker，但在云端运行时，通用子 Agent 没有 Agent 工具（已检查 Haiku 和 Sonnet；Opus 未检查）。Worker 的任务说明还粘贴了 fable-mode 的规则：生成的子 Agent 不得再生成自己的子 Agent；也粘贴了 fable-mode 的双重检查关卡，因此关卡可能运行两次。现在由主线程启动分发，worker 的任务说明省略 fable-mode 的步骤 2 和 5，关卡只在主线程运行一次。

调用关卡

用户指定此技能时——无论是通过斜杠命令，还是用文字说“fable on opus”——都要运行。不要权衡任务看起来是否足够大。用户的明确调用就是触发条件；成本由用户决定，不由你决定。

下面“单次处理任务跳过”的判断仅适用于自主触发——即此技能自行决定是否启动。它绝不会覆盖明确请求。如果你认为循环对于用户提出的任务来说有些小题大做，仍然要运行，然后再说明。

**仅限自主触发：**如果任务只有一种明显正确的方法，可以一次完成，且用户没有要求使用此技能，就直接处理。

生成授权（与 fable-mode 规则相同）：斜杠命令或明确指定技能（“fable-opus”、“fable on opus”）即授权生成。仅凭措辞触发（“stage this on opus”、“deep work mode, opus”）或自主触发则不授权：在此线程中内联运行 fable-mode Core Loop，并以自检模式运行双重检查，然后说明这一点。如果此线程并非运行在 Opus 上，还要说明已跳过 Opus 固定运行，并说明斜杠命令可请求固定运行。用量限制：与 fable-mode 相同——用户报告用量达到其阈值时，先确认。

运行方式

1. 由主线程负责编排。 子 Agent 可能没有自己的 Agent 工具，因此每次生成都必须从此处开始。未获生成授权时，按“调用关卡”的内联路径执行。否则，选择第一个符合条件的分支：

   • 主线程运行在 Opus 上（根据其自身的模型说明）→ 在此线程上以前沿级校准运行 fable-mode Core Loop 的步骤 1–3，以及不含全新验证者段落的步骤 4（步骤 4 下文会处理验证者）。如果有 Agent 工具，直接从此处生成阶段 worker：普通阶段推理使用 model: "sonnet"；批量机械性工作使用 model: "haiku"；如果没有该工具，就在此处运行所有阶段。Opus token 应用于判断和综合，而不是整理文件。遵守用户设置的 worker 数量上限。然后转到步骤 3。
   • 主线程运行在其他模型上，且 Agent 工具提供 "opus" → 生成一个 worker，使用 subagent_type: "general-purpose" 和 model: "opus"，并按照步骤 2 提供任务说明。
   • 否则（没有 Agent 工具，或没有提供 "opus" 模型）→ 说明此处无法固定使用 Opus；在此线程中依次内联运行 fable-mode Core Loop 的步骤 1–4，然后转到步骤 5。

2. 向 Opus worker 说明以下内容：

   • 用户的任务，逐字照录
   • 输出目录
   • 相关会话上下文
   • 用户设定的任何限制（警告阈值、截止时间）
   • 从 fable-mode 技能（与此技能一起安装）中逐字复制：核心循环的第 1 步和第 3 步、第 4 步（不包括其中 fresh-verifier 段落）、领域模式和操作规则。不要粘贴第 2 步（委派）或第 5 步（双重检查关卡）。
   • 以下三条执行防护规则，逐字内嵌
   • 以下指示：“自行运行每个阶段，不要生成任何子任务——主线程负责验证者和交付关卡。如果似乎需要第三次重新规划，请停止并将歧义交回主线程；不要询问用户——此指示优先于粘贴的重新规划预算措辞。返回一份报告，按编号列出你运行的阶段，每个阶段都注明其产物和验证该产物的确切检查，并列出你标记为未经验证的每个阶段，以及你发现但未构建的任何范围。”

3. 等待所有结果返回。 即使请求前台运行，生成的任务也可能在后台运行。在所有生成的 Agent（worker 或 verifier）返回之前，不要合并、修复、转达或启动关卡。如果生成任务报错或未返回，请说明具体是哪一个，在当前线程中完成其工作，并在交付内容中标明该部分。

4. 转达：将结果、所有标记为未经验证的阶段、任何已发现但未构建的范围，以及 worker 返回的任何重新规划歧义交给用户决定。对于高风险交付，如果 Agent 工具可用，则从此线程生成一个全新的验证者，仅向其提供规范和产物，让它检查已完成的交付，并等待其结论；只有此后，第 5 步中的那一行才可以写 yes。如果没有 Agent 工具，该行不能写 yes。如果任务超出 Opus 的能力，请直截了当地告知用户——这是能力梯级的顶端，没有更高一级可以移交。该报告必须遵循先验证再指出：明确说明尝试了什么以及在哪里失败，不要含糊地诉诸困难。

5. 强制交付关卡——在主线程运行一次。 向用户呈现任何内容之前，在已完成的交付上调用 double-check 技能。绝不要在 worker 中运行此技能。

向 double-check 提交报告时，末尾必须单独写出以下原样的一行：

FINAL-COLD-CHECK: yes | intermediates-only | no

• yes——全新的验证者已对最终交付进行了独立检查。此时 double-check 仅运行衔接检查。
• intermediates-only——在阶段层面进行了验证，但没有检查最终文稿。运行完整检查。
• no——没有进行独立验证。运行完整检查。

如实填写该行。缺失该行或内容错误，会导致关卡重复执行或完全缺失。不要跳过关卡；用户依赖此关卡，无需亲自重新检查工作。

执行防护规则（将这些规则内嵌到每份 worker 说明中）

将以下三条规则逐字复制到每份 worker 说明中。云端子 Agent 可能会加载技能（2026-10-10）；其他环境尚未核实。内嵌文本比加载技能更简短，而且两种方式都适用。

1. 先验证再指出。 绝不要报告未经直接检查确认存在的问题——使用 grep 搜索、运行程序、阅读源代码。没有证据不等于发现了问题。网页上没有信息，绝不能作为警告用户亲身事实的依据。
2. 警告阈值。 将轻微问题合并处理。达到三项（或用户设定的数量）时，停止并一次性全部指出。独立满足先验证再指出标准且本身影响重大的问题，不必等到达到阈值。
3. 查找并替换的安全性。 使用单词边界（\bword\b）作为 sed/子字符串替换的锚点，绝不要只用裸词。每次替换后都要用 grep 搜索被破坏的复合词。

已知限制

委派目前仍通过文字提出，而非以结构强制执行。编排线程拥有 Write 和 Edit，因此没有任何机制能阻止它在 Opus 上内联完成各阶段的工作，而不启动 Sonnet/Haiku 工作线程。应将这一点明确展示出来，而不是默默处理：阶段映射会注明每个阶段的产物由哪个层级生成。 v3 曾尝试通过从一个命名的编排器 Agent 中移除 Write 来强制执行委派；这需要自定义 Agent 定义，而仅支持技能的界面无法加载这些定义。