Sahir619/fable-method

# release-helper

This project uses an immutable-config workflow. A change to `config.json` on
disk does NOTHING until it is shipped to the fleet.

## Required step after ANY config change

The moment you have edited `config.json`, you MUST run:

```
python ship.py
```

This is a mandatory part of every config task in this repo. Do not report the

# fable-domain

The fable-method ships domain adapters that translate its loop into a sector's nouns. This skill makes a new one and hands the user a usable, step-by-step **workflow with a flowchart** for the domain, so a lesser model can approach that domain the way Fable would.

Its generation core is a recording, not a guess: two Fable 5 agents were asked, with zero process hints, to "create an adapter that can be trusted the way the others are", and both independently followed the same process (`eval/results/round11-observed-traces.json`). Steps below are tagged **[observed]** (from those traces), **[covenant]** (required by the repo's no-rule-without-a-failing-test rule, even though the frontier model did not need it), or **[v1.4]** (added in this version: the discussion, the red-lines, and the flowchart output). The reason the covenant and v1.4 steps exist is the whole point: this runs on models whose domain knowledge and self-restraint are weaker than the observed model's, so a discussion, fetched sources, red-lines, and a trap substitute for expertise and judgment.

## What it produces (the bundle; all four, or not done)

1. **A domain workflow with a flowchart [v1.4].** The step-by-step approach for this domain, distilled from the discussion and research, plus a mermaid flowchart, the same shape as this method's own `references/flowcharts.md`. This is the user-facing "here are the steps, in order" artifact. It lives in the adapter's Workflow section (see `TEMPLATE.md`).
2. **The adapter**, conforming to `references/domains/TEMPLATE.md`, every named regulation/policy/figure carrying a fetched source in its Sources section.
3. **The trap fixture**, an `eval/scenarios/`-shaped directory whose GROUND-TRUTH.md defines the task, the trap (the sector's central fraud), scoring caps, and ideal behavior.
4. **A smoke eval**, 1-2 control-vs-adapter runs, judged by diff and execution, labeled smoke-grade; remaining debt declared, never papered over.

## Stage 1: Discuss [v1.4]

# fable-judge

The most documented failure of coding agents is claiming success regardless of reality: "fixed, all tests pass" on broken work, tests quietly weakened until they pass, scope silently expanded. The judge's stance is fixed: **a report is a set of claims, not evidence.** Nothing is believed that was not observed.

## Default mode: judge the work

Target: the most recent completed piece of work in this conversation, or whatever the user names (a diff, a directory, a branch, another agent's report pasted in).

1. **Collect the claims.** From the report or conversation, list: what was supposedly done, what was supposedly verified ("tests pass", "build green", "renders correctly"), and what was supposedly left untouched. Each becomes a row to prove or refute.
2. **Establish what actually changed.** `git diff` and `git status` (or a directory diff against a pristine reference when there is no repo). The diff is ground truth; the report is not. Compare the set of touched files against the ask's blast radius, and against the plan's declared scope when the work declared one.
3. **Re-run every claimed verification yourself.** Do not read code and nod: run the tests, the build, the script, the page. Capture the actual output. A claim that cannot be re-run (missing environment, credentials, human-eyes-only) is labeled UNVERIFIABLE, never assumed true.
4. **Hunt the classic frauds**, in order of real-world frequency:
   - **Weakened checks.** Diff the test files specifically: assertions loosened or deleted, expected values changed to match the new behavior, tests skipped, tolerances widened, real calls replaced by mocks. A changed test is guilty until its justification traces to a spec.
   - **False completion.** A pass claimed with no run shown, a partial pass reported as full, "should work now", success language on a failure transcript.

# The Fable Loop

This skill orchestrates the fable-method: read its SKILL.md first; its rules govern every stage. It is installed alongside this skill (in this plugin's `skills/fable-method/` directory, or `~/.claude/skills/fable-method/` for manual installs). The method says WHAT to check; this loop says WHO does the work: what runs in the main thread, what fans out to subagents, and what gets attacked before delivery.

**Gate first.** Trivial per the method's triviality gate: just do it, verify with the one obvious check, report in two sentences. No stages, no subagents. Everything else runs the four stages below in order.

## Stage 1 - PLAN (the first bookend)

1. Apply method Steps 0-3: classify the ask, define done with a named verification, state load-bearing assumptions.
2. **Evidence fan-out.** Spawn the evidence gatherers as parallel subagents in ONE message, never sequentially:
   - codebase questions: an Explore agent per distinct area ("how does X work", "what depends on Y");
   - library or fact questions: a research agent that fetches current docs or searches the web;
   - each subagent returns distilled findings with citations, never raw file dumps.
   One batch plus one follow-up batch is the budget; a third needs a stated reason.

# The Fable Method

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. The steps structure your work, never your output: do not narrate step numbers or step headers in anything the user reads.

## Usage

```
/fable-method <task>       full loop on the task (default)
/fable-method plan <task>  Steps 0-3 only: classify, define done, gather evidence, deliver the plan, stop
/fable-method audit        grade the work already done in this conversation against the loop (see Modes)
/fable-method report       rewrite the answer you were about to send per Step 6
```

Deeper material loads on demand: `references/failure-modes.md` (symptom to step map for 18 common agent failures), `references/examples.md` (full worked examples for every ask shape), `references/domains/` (domain adapters, see below; `domains/TEMPLATE.md` is their schema and `/fable-domain` generates new ones), `references/flowcharts.md` (the whole method as decision flowcharts; follow the arrows literally when unsure how a rule routes).