/fable-discipline

name: fable-discipline
description: "Engineering discipline distilled from a forensic read of one model's work. Use when building a feature, fixing a bug, writing tests, hardening a data path, or running any task that spans multiple files, sources, or sessions. Two layers: how to RUN the task (stage it, verify each stage with a check that can fail, write done-criteria) and how to WRITE the code (recon before edit, verify against a copy with a negative self-test, single-writer chokepoints, scar-anchored why-comments). Ships a paired hook that deterministically blocks a test from touching live data, the one habit a machine can enforce."

Fable-Discipline

Coding and task discipline, distilled from reading thousands of edits by one capable model and grading them against an independent review. It is additive: it does not replace what your model already does well, it adds the habits that strong engineers have and most code generation skips.

Most of it is judgment the skill teaches. One slice is enforced by a hook, because a rule a model can talk itself out of is a suggestion, not a gate. The skill teaches; the hook makes the one checkable habit non-optional.

<!-- kipi-only:start -->

Position: the execution-discipline layer of prd-os

This skill is not a sibling system to prd-os; it is prd-os's execution-discipline layer (merged 2026-07-04, see the plugin CHANGELOG). Two load paths, one skill:

• **PRD work:** `/issue-start` loads this skill before the first edit of every

DSSE issue. The issue's receipts (verified, reviewed, findings_triaged) are the task-level half of the same contract this skill states per-edit.

• **Non-PRD work:** the quick-plan fast path and the fable-discipline auto-invoke

rule load it for any coding task bigger than a one-line change.

The public standalone export (github.com/assafkip/fable-discipline) mirrors this copy; `scripts/export-fable-mirror.sh --check` is the drift blocker. <!-- kipi-only:end -->

When NOT to use this

One-line changes, typo fixes, a task with one obvious approach that fits in a single pass. Staging a trivial task buries the answer under ceremony. This earns its cost only when a one-shot attempt would plausibly miss something.

---

Layer 1: running the task

How to move through complex work without shipping a confident wrong answer.

1. **Stage before you act.** Write the stage plan first. Number the stages, name the one checkable artifact each produces. If a stage produces nothing checkable, merge it into the next. The map is living, not a contract; update it when what you learn invalidates it.

2. **Verify each stage with a check that can fail.** A test that runs, a file that provably exists in the right shape, a source actually read, an output diffed against the spec. "I reviewed it and it looks right" is not a check: a model that would skip verification also passes its own introspection. If a stage has no failable check, say so and mark its output unverified so the gap is visible.

3. **Say, then batch.** State the one-line intent, then fire the burst of actions that executes it. The test is binary: a reader given only your intent lines can reconstruct the plan, or the intent line failed; rewrite it. It keeps you from drifting mid-burst.

4. **Done is written, not felt.** Define done-criteria up front. On a task that spans sessions, keep a short work log (decisions, what was tried, what failed) and re-read it before continuing, so you do not duplicate work or guess where you left off.

5. **Ground before you diagnose.** Confirm a perceived error actually reproduces before you act on it. Read where the data comes from before you trust what it represents. The failure mode this prevents: seeing a likely error, diagnosing it instinctively, and running with that explanation before checking it was real.

---

Layer 2: writing the code

1. **Recon before edit. Read reality, do not assume it.** Grep the real schema and call-sites before changing anything. Never edit a file you have not read this session, unless you created that file in this same session (your own fresh write counts as read). If you already read a schema, re-read the exact field names rather than guessing them.

2. **Verify against a copy, with a negative self-test.** A passing gate is not trusted until it has been seen to fail. Run the reproducer against a copy of the live resource, never the live one, unless the resource is disposable by design (a regenerable fixture or sandbox environment). Then corrupt a valid input and prove the check FAILS on the violation, so a green result is not a rubber stamp.

**A mutation result is THREE claims, and usually only one gets checked.** "The mutant was KILLED" is meaningless until "the mutant was APPLIED" and "the check was GREEN first" are both proven. An unapplied mutant and a well-defended one are identical bytes on the terminal, and so are a killed mutant and a command that was already red. Every mutation run therefore:

• matches its anchor **exactly once** before writing, and proves the bytes on

disk moved (digest, not length: a length-preserving mutant is legitimate);

• exits non-zero as a **FAILED EXPERIMENT** on an anchor miss or an ambiguous

anchor, and never falls through to the run. Override: re-derive the anchor from the file as it is now and re-run once it matches exactly one site. Loosening the anchor to make it match is not the hatch, it is the scar;

• pins `PYTHONDONTWRITEBYTECODE=1` AND a bytecode-cache path outside the source

tree. The first stops the run LEAVING a cache; only the second stops it READING a stale one, and the stale read is what measures the unmutated module;

• starts from a **green baseline**, measured per experiment against the

unmutated file rather than trusted once at the top of a table. A mutation run against an already-red check kills eve