fable-method

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

The Fable Method

Fable 方法

A mid-tier model that follows this loop beats a stronger model that free-styles: the quality lives in the structure, the evidence, and the honesty, not in the model. The loop is self-contained. Follow it literally.

中等水平的模型只要遵循这一循环，效果就会胜过随意发挥的更强模型：质量来自结构、证据和诚实，而不在于模型本身。该循环自成体系，请严格遵照执行。

Purpose

目的

Provide a universal, disciplined engineering loop across all problem shapes: classify the ask, define done, gather evidence, decide, act surgically, verify by observation, and report outcome-first.

为各种类型的问题提供一套通用、严谨的工程循环：对请求分类、定义完成标准、收集证据、决策、精准执行、通过观察验证，并优先报告结果。

When to Use

使用时机

When the user explicitly requests the Fable Method (
```
/fable-method
```
, "approach this like Fable").
When starting an ambiguous multi-step engineering task with no specialized specialist pre-assigned.
When executing structured planning (
```
/fable-method plan <task>
```
).
When auditing existing conversational work against lifecycle invariants (
```
/fable-method audit
```
).

用户明确要求使用 Fable 方法时（
```
/fable-method
```
、“approach this like Fable”）。
开始模糊的多步骤工程任务，且尚未分配专门的 specialist 时。
执行结构化规划时（
```
/fable-method plan <task>
```
）。
根据生命周期不变量审计现有对话工作时（
```
/fable-method audit
```
）。

When NOT to Use

不应使用的场景

Trivial one-line edits where the change is obvious and self-contained (execute directly).
Purely autonomous background long-polling or test loops (use
```
fable-loop
```
).
Multi-host installation and setup procedures (use
```
fable-release
```
or installer).

改动明显且自成体系的一行琐碎修改（直接执行即可）。
纯自主的后台长轮询或测试循环（使用
```
fable-loop
```
）。
多主机安装与配置流程（使用
```
fable-release
```
或安装程序）。

Inputs

输入

```
task_description
```
: The problem prompt, specification, or bug report.
```
domain_adapter
```
: Optional sector adapter (
```
references/domains/*
```
) for non-code domains.

```
task_description
```
：问题提示、规格说明或错误报告。
```
domain_adapter
```
：用于非代码领域的可选行业适配器（
```
references/domains/*
```
）。

Expected Outputs

预期输出

```
verified_solution
```
: Surgically implemented changes matching the specification.
```
execution_evidence
```
: Observable evidence proving the solution works as intended.

```
verified_solution
```
：按照规格精准实施的更改。
```
execution_evidence
```
：证明解决方案按预期工作的可观察证据。

Procedure

流程

Triviality Gate: If the task is one file, under ~10 lines, with no new behavior and known edit, execute directly and confirm with one check.
Fit Gate: Determine where the answer lives: in reachable sources (run loop), in unknown external techniques (research first), or only in inference (flag low-confidence).
Step 0 — Classify the Ask:
- Question / assessment: Report findings, change nothing.
- Task: Implement and verify.
- Plan-first: Produce plan and wait for approval if scope is ambiguous or actions are irreversible.
Step 1 — Define Done: Explicitly declare what completion looks like and how it will be verified.
Step 2 — Gather Evidence: Open sources, read relevant code, check authoritative docs before modifying state.
Step 3 — Decide: Formulate the minimal viable plan.
Step 4 — Act Surgically: Modify only the necessary lines with zero collateral drift.
Step 5 — Verify by Observation: Run the code, execute the test, observe the side effect.
Step 6 — Report Outcome-First: State the outcome in the first sentence.

琐事门禁：如果任务只涉及一个文件、不足约 10 行、不改变现有行为且修改位置明确，则直接执行并通过一次检查进行确认。
适配门禁：确定答案应从哪里获得：位于可访问的来源中（运行循环）、涉及未知外部技术（先进行研究），或只能通过推断得出（标记为低置信度）。
步骤 0——对请求分类：
- 问题／评估：报告发现，不做任何更改。
- 任务：实施并验证。
- 计划优先：如果范围不明确或操作不可逆，则生成计划并等待批准。
步骤 1——定义完成标准：明确声明完成后的状态以及验证方式。
步骤 2——收集证据：在修改状态之前，打开源文件、阅读相关代码并查阅权威文档。
步骤 3——决策：制定最小可行计划。
步骤 4——精准执行：仅修改必要的代码行，不产生任何附带改动或漂移。
步骤 5——通过观察验证：运行代码、执行测试并观察副作用。
步骤 6——优先报告结果：在第一句话中说明结果。

Decision Rules

决策规则

Plan-First Priority: If any irreversible action, destructive command, or ambiguous scope is present, plan-first supersedes task execution.
Scope Gate: Do not touch files outside the bounded problem domain.
Evidence Gate: A task is not done until fresh passing machine evidence is observed.

计划优先原则：如果存在任何不可逆操作、破坏性命令或范围不明确的情况，计划优先于任务执行。
范围门禁：不得触碰限定问题域之外的文件。
证据门禁：在观察到本次执行产生的通过测试证据之前，任务不得视为完成。

Tool Policy

工具策略

Execute shell commands to run compilers, linters, and test runners.
Use targeted file reading and editing tools.
Consult domain adapters in
```
references/domains/
```
when handling non-coding tasks (marketing, ops, finance, devops).

执行 shell 命令来运行编译器、linter 和测试运行器。
使用有针对性的文件读取和编辑工具。
处理非编程任务（营销、运营、财务、DevOps）时，查阅
```
references/domains/
```
中的领域适配器。

Evidence Requirements

证据要求

Direct terminal outputs from test runners or build tools.
Line references to source code confirming bug mechanism and repair.

测试运行器或构建工具输出的直接终端结果。
源代码行号引用，用以确认错误机制和修复内容。

Failure Handling

失败处理

If a step fails, diagnose the failure mechanism rather than blindly retrying the same operation.
If two consecutive failures occur, immediately route to
```
fable-recover
```
.

如果某个步骤失败，应诊断失败机制，而不是盲目重试相同操作。
如果连续发生两次失败，立即转交至
```
fable-recover
```
。

Completion Criteria

完成标准

All criteria defined in Step 1 ("Define Done") are satisfied.
Fresh passing test evidence captured.
Final report delivered outcome-first with zero fluff.

步骤 1（“定义完成标准”）中定义的所有条件均已满足。
已获取本次执行产生的通过测试证据。
最终报告以结果为先，不包含任何多余内容。