FableCodex puts a goal ledger and a findings gate between the prompt and completion

A Codex plugin that disclaims the model in its first paragraph

FableCodex is a plugin for Codex, and its stated job is to add operating habits to Codex work rather than capability to the model. The habits are named in one line: inspect first, track goals, record evidence, close review findings, and verify before claiming completion. The framing sentence is a cost judgement rather than a feature list, and it is worth reading twice. It says the plugin is useful when the cost of a missed step is higher than the cost of a little process.

The opening disclaimer is unusually firm. FableCodex does not clone, unlock or replace the Fable 5 model, and it cannot change model weights, context length, training or hidden safety systems. What it provides is Codex-native workflow guidance, local ledgers, examples, coverage accounting and optional routing docs.

That disclaimer matters because the name invites the wrong assumption. Fable is a common enough word that a reader arriving cold may expect a model product. It is not one: it is a workflow layer over a coding agent, and the only artefacts it writes are local JSON files.

The licence is AGPL-3.0, with both a LICENSE and a NOTICE file at the root, and the repository is not archived. Its last push was on 2026-07-26.

Seven steps, and an explicit claim that capability is not what changes

Invoking `@codex-fable5` makes Codex read the skill and apply a stricter sequence, enumerated in the README as seven steps.

Classify the task before acting. Inspect the workspace, files, tools or cited sources. Use the right Codex-native tools instead of relying on memory. For long work, track goals with evidence checkpoints. For review-sensitive work, track findings and require a final findings gate. Verify with tests, lint, typecheck, screenshots, command output, source inspection or connector readback. Then report what changed, what was verified and what risk remains.

Two details are load bearing. Step two puts inspection before action, which is the ordering the whole plugin exists to enforce. Step six lists six different kinds of verification, and the list is the practical part: a screenshot and a connector readback count as evidence alongside a passing test suite.

The README's own summary of the effect is blunt. The skill is procedural, and it improves discipline rather than raw model capability. That is also the honest expectation to set: nothing here changes what the model can do, only whether a step gets skipped.

The only control surface is the prompt, including the instruction to do less

There is no configuration file for strictness. The README is explicit that the user controls the skill through the prompt, and the instruction is to be explicit about scope, strictness, verification and stopping rules.

Four canned shapes are given. Strict mode asks for a goal ledger, recorded review findings, and no completion until tests and the findings gate pass. Analysis only forbids editing files and asks for findings with file and line references. Implementation with limits forbids committing, pushing or deleting branches, and asks for unit tests plus residual risk. Debugging asks for reproduction first, multiple hypotheses kept open, disconfirming evidence gathered, and only then a fix and a verification.

A lighter pass is documented too, which is the more interesting half: review quickly, do not create a goal ledger, check key evidence, report only actionable findings.

The skip list is as deliberate as the use list. Short answers, tiny single-file edits, brainstorming where no verification is expected, and any task where the ledger process would be heavier than the work itself. A plugin that documents when not to use it is rarer than it should be.

A goal ledger is a JSON file, and the goals carry typed prefixes

For longer work the helper keeps local state in `.codex-fable5/goals.json`. Using it means putting the bundled helper on your PATH, then declaring goals by name:

export PATH="$PWD/plugins/codex-fable5/bin:$PATH"

codex-fable5 goals create --brief "Migration" \
  --goal "inspect::Find current behavior and tests" \
  --goal "change::Implement the migration" \
  --goal "verify::Run tests and inspect output"

codex-fable5 goals next

The prefixes are the interesting part. Goals are written as `inspect::`, `change::` and `verify::` ahead of their description, so the ledger records what kind of step each goal is rather than leaving the model to decide what a goal represents. `goals next` starts or resumes the next unfinished one, which is what makes the ledger resumable across sessions rather than a scratchpad for a single sitting.

That the state is a plain JSON file in the working tree is what makes it auditable. A ledger you can read, diff and commit is a different thing from a ledger held in a chat transcript, and nothing here needs a service to be inspected.

The final goal is the only one that demands verification evidence

Every completed goal needs evidence, supplied through a checkpoint:

codex-fable5 goals checkpoint \
  --id G001 \
  --status complete \
  --evidence "Read importer.ts and import.test.ts; current parser rejects quoted commas."

Note what the evidence in that example is: the files that were read and the specific behaviour found. It is a record of what was learned, not a claim that something was done.

The last goal is held to a stricter standard, because it carries a verification command and its result as separate fields:

codex-fable5 goals checkpoint \
  --id G003 \
  --status complete \
  --evidence "Implemented quoted CSV parsing and updated tests." \
  --verify-cmd "python3 -m unittest discover -s tests -v" \
  --verify-evidence "All tests passed."

Splitting the command from its result is the design decision here. It forces the runner to record what it ran as well as what came back, so a checkpoint cannot be closed by asserting an outcome.

Findings live in a second file, and the gate fails on open or blocked

A finding is defined as an accepted review issue that must not be lost before final completion. They are stored separately, in `.codex-fable5/findings.json`, and added with the evidence that justifies them:

codex-fable5 findings add \
  --title "Missing final verification" \
  --severity high \
  --source review \
  --location "plugins/codex-fable5/skills/codex-fable5/scripts/codex_goals.py" \
  --evidence "Final checkpoint can complete without proof that tests ran."

Severity and source are both required inputs rather than inferred, and the location is a real path, so a finding is reviewable on its own terms.

Resolving one requires the fix and the verification together:

codex-fable5 findings resolve \
  --id F001 \
  --evidence "Final checkpoints now require verification evidence." \
  --verify-cmd "python3 -m unittest discover -s tests -v" \
  --verify-evidence "Regression test passed."

codex-fable5 findings gate

Two rules make it bite. The gate fails while any finding is `open` or `blocked`, and final goal completion also fails while blocking findings remain. So the finding list and the goal ledger check each other, and neither can be finished around.

The install command pins v0.5.1, and three releases were cut on one day

Installation is two commands against a marketplace reference:

codex plugin marketplace add baskduf/FableCodex --ref v0.5.1
codex plugin add codex-fable5@fablecodex

Then Codex is restarted and the skill is invoked by name in the prompt. A development install swaps `--ref v0.5.1` for `--ref main`, and the README gives a local development route as well, though that section is cut off mid-command in the text as it reads.

The pinned reference is the detail to notice. v0.5.1 was published on 2026-06-18, alongside v0.5.0 and v0.4.4, all three within a few hours of each other. The repository's last push came later, on 2026-07-26, so the default branch has moved past the tag the install command names.

That is what `codex-fable5 update` is for. It moves the checkout to the latest stable `v*` tag, and the README is careful about its scope: it changes only the FableCodex checkout and plugin package, not model access, provider credentials or runtime behaviour. `--ref main` is for when you deliberately want the development branch instead.

The examples folder names the same provider bridge two different ways

The repository carries the usual governance furniture, and more of it than most projects this size. The root holds a CHANGELOG, CODE_OF_CONDUCT, CONTRIBUTING, GOVERNANCE, SECURITY, SUPPORT and a ROADMAP, plus five READMEs covering English, Korean, Japanese, Simplified Chinese and Traditional Chinese. There are also `.agents/`, `docs/`, `evals/`, `examples/`, `plugins/` and `tests/`.

The examples directory is small and shows the seams. It holds `AGENTS.md`, `hooks.json`, and two files that both appear to configure a provider bridge by a different name: `codex-config.litellm.toml` and `litellm-fable5.yaml`. One uses a dotted TOML naming convention and the other a flat YAML one, for what the README calls optional routing docs.

That is minor, but it is the kind of thing worth resolving before anyone copies from those files. The presence of `evals/` alongside `tests/` also suggests two different kinds of checking, one for correctness and one for behaviour of the workflow itself, though the split is not described in the visible text.

The command reference closes the plugin's surface cleanly: status, version, update, and the goals and findings subcommands, with a documented fallback that runs the checkout helper directly when you have not changed PATH.

Editorial conclusion

Adopt FableCodex for work where a missed step costs more than the paperwork does, which the project defines as multi-step implementation, migrations, CI failures and security-sensitive changes. Skip it for short answers and single-file edits, since the ledger overhead exceeds the work. Two checks before you rely on it: whether the tag your install command pins is still the one you want, since the README hardcodes v0.5.1 while `codex-fable5 update` moves to the latest stable `v*` tag, and whether your Codex session will actually run the helper, since the goal and finding commands only resolve once `plugins/codex-fable5/bin` is on your PATH.

Frequently asked questions

Official sources

1. baskduf/FableCodex on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases