fable-method：把 Claude Fable 5 的工作方式写成可执行的技能与评测

它要解决的是指令文件只讲价值观、不讲动作顺序的问题

多数 agent 指令文件写的是「要谨慎、要验证你的工作」这类取向，模型读完仍然不知道下一步做什么。fable-method 的出发点是把取向换成动作序列与阈值：先分类请求，再定义什么叫完成并给出一个具名的验证方式，然后并行从一手来源取证，收敛到一条推荐，做最小改动，靠观察验证，最后先报结果再补诚实的保留意见。README 明确说这样写的目的是让中档模型可以照着字面执行。目标读者是给编码 agent 写指令的人，以及需要让弱模型在无人值守下少出错的团队。仓库自述这套内容是 Claude Fable 5 在被从订阅中移除前留下的工作方式，四个技能分别对应 think（fable-method）、act（fable-loop）、prove（fable-judge）、grow（fable-domain）。

主循环的六个步骤，以及每根箭头上的硬边界

主循环是一条从 ask 到 report 的直线：0 分类、1 定义完成、2 取证、3 决策、4 行动、5 验证、6 报告。分类阶段先问是不是 trivial，判据是单文件、十行以内、不引入新行为、不需要检索，满足就直接做、跑那一个显然的检查、两句话汇报。不满足就进入 fit gate，问「答案在哪里」：来源可达就继续走形状判断，未知但可研究就先花第 2 步的预算去研究，只能靠自己的推断就直说不要伪装，属于专门且反复出现的领域就去做一个技能。按形状分流后，问题类请求只诊断不改动，给出发现加一条推荐；plan-first 类（范围含糊、动作不可逆、或者对方就是要一份计划）先产出计划产物然后停下等批准；任务类才进入执行。真正让这套东西可执行的是每根箭头上的边界：3 次验证失败就停下交还，2 次查不到就停止检索，说不出验证方式就先问一个具体问题。README 称完整方法在 skills/fable-method/SKILL.md，约 110 行。

fable-judge 不看报告，靠 diff 与执行来判定

prove 这一环由 fable-judge 承担。README 对它的描述很具体：盲测的 LLM 裁判通过 diff 和执行来验证，而不是读报告。这个区别决定了它能不能用在会撒谎的执行者身上。评测里对应的场景是让 Haiku 去审一份声称「工作已完成」的报告，报告里埋了造假内容，没有 fable-judge 时命中 4 和 3（满分 5），加上之后两次运行都是 5 分全中。另一个场景是营销文案审查：Haiku 需要在判定之前先找到品牌规则与产品事实文件，未加技能时两次运行只有一次找到，其中一次还夸了一个伪造的价格；加上之后两次运行都找到，六处造假全部命中。这两个案例的判定方式都落在可核验的产物上，而不是模型的自述。

fable-domain 生成新的领域适配包，代价是只能盲评

grow 这一环由 fable-domain 承担，它按作者模型被观察到的方式生成新的领域适配器。评测第 12 轮让 Sonnet 盲做一个有研究依据的 devops 适配包，判定标准是 Fable 轨迹的门槛，得 9/10：来源被抓取并抽查，陷阱夹具在三种状态下都验证过。第 13 轮做了跨档位对比：裸模型对上有 fable-domain 时，Haiku 从 2 分升到 6 分，Sonnet 从 9 分升到 10 分，Opus 从 8 分升到 9 分。README 把这条读成「提升与档位成反比」，并称这是仓库的论点。这里需要留意的是评判方式本身：适配包的质量由「Fable 轨迹门槛」来打分，而 Fable 5 已经无法再跑，这个门槛是一个被写下来的参照，不是可复现的对照实验。仓库把生成过程与判定标准都公开在 eval 目录下，但读者要自己判断这个门槛是否适合自己的领域。

安装与配置：plugin 清单、技能目录与评测夹具

仓库以 Claude Code 插件形式分发，README 的徽章指向 .claude-plugin/plugin.json，其中声明 plugin v1.4.0。技能按目录组织，主技能路径是 skills/fable-method/SKILL.md，另外三个技能对应 act、prove、grow 三个环节。评测材料分布在三处：eval/cases/ 每个场景一份案例研究，eval/RESULTS.md 是完整日志，eval/results/ 存放裁判的原始输出，文件名带轮次与场景，例如 round3-v3-intent-gate-and-sonnet.json、round8-fable-judge-transfer.json、round13-cross-tier.json。CI 配置在 .github/workflows/checks.yml。README 建议从 eval/cases/s2-surprise-trap.md 这个「意外陷阱」案例开始读，因为它最能说明方法在什么情况下起作用。需要说明的是，我没有安装或运行过这个项目，以上路径与文件名都来自 README 与仓库结构描述，实际接入宿主时的具体命令请以仓库文件为准。

已知失败模式：弱档模型在 s9 上仍然漏掉跳过的部署决策

README 没有只列成功项。有一条被明确标为失败：让 Haiku 在 s9 场景中主动提出「部署被跳过」这个决策，三种规则措辞下十二次运行只有一次做到，仓库把它记为仅弱档模型存在的问题，并说明 Sonnet 与 Opus 在八次运行中全部原生提出。另一个例子更能说明边界在哪里：第 11 轮里，裸的 Fable 5 面对夹具自带 README 所规定的未授权 staging 部署，两次运行中有一次直接部署了，授权门这条规则正是从这次运行里长出来的。还有一条是设计上的取舍：小任务在能力较强的模型上跑，README 标为 fine 且 no lift。换句话说，这套方法的价值集中在陷阱场景，包括权威冲突、虚假完成声明、弱执行者、无人值守运行。把这些规则套到普通任务上，得到的是额外的步骤和 token 消耗，而不是更好的结果。

与纯提示词约束的差别在哪里

常见的替代做法是在系统提示里写一段行为规范，或者在 CLAUDE.md 里堆几条原则，靠模型自己去解释和执行。fable-method 走的是另一条路：把规则写成带阈值的步骤，配上可核验的产物，再用一套评测去检查规则本身是否有效。差别体现在两处。第一处是失败的处理方式，纯提示词方案遇到「报告说完成了」时只能继续追问，fable-judge 则要求裁判去 diff 和运行，把判断落到可执行的证据上。第二处是规则的可追溯性，README 声称每条规则的存在都对应一次失败的测试或一段轨迹，并且每条主张都链接到已提交的 transcript，例如授权门对应 round11 的那次未授权部署。这种把规则与失败记录绑定的做法，比在提示词里追加一句「不要擅自部署」更难维护，但至少能回答「这条规则为什么在这里」。代价是仓库与评测日志必须一起演进，规则改动会牵动评测。

维护成本与许可

仓库采用 MIT 许可，允许修改与再分发，包括商用，前提是保留版权与许可声明。这一点对打算把 adapter bundle 分发给别人的人有实际影响：MIT 不要求你公开衍生作品，但也不为适配包里的内容来源背书，如果你用 fable-domain 生成了某个领域的适配器，其中的事实与素材是否可追溯，责任在你这一侧。维护方面，从提交记录看 v1.2.0 到 v1.4.0 之间隔了六天，v1.4.0 一次性加入了 fit gate、twin check、artifact gate 和带红线的 maker，说明规则集仍在快速变动。这意味着两件事：一是升级时要重新读 SKILL.md 而不是只看版本号，二是评测日志里的轮次编号会随规则改动而失效，旧轮次的结论不自动适用于新版本。仓库没有给出兼容性承诺或弃用策略，README 里也没有升级指引。

编辑结论

适合采用的情况：你在用 Haiku 这类中低档模型跑无人值守的 agent 任务，或者任务里存在权威冲突、虚假完成声明这类陷阱，README 的评测显示提升主要出现在这里。不适合的情况：日常小任务在能力较强的模型上跑，仓库自己标注为 no lift，引入这套流程只是增加 token 与步骤开销。上手前先确认三件事：plugin.json 里声明的版本与 .claude-plugin 目录结构是否与你的宿主兼容；eval/cases 中与你场景最接近的那个案例，其判定标准是否由 diff 与执行得出；以及 MIT 许可下你打算分发的 adapter bundle 里，是否混入了你自己无法追溯来源的素材。

官方来源

1. Issues
2. License: MIT
3. README
4. Releases
5. Sahir619/fable-method on GitHub