| name | fable |
| description | Use at the START of any coding task (feature, bugfix, refactor, review, integration) and RETURN to between phases — ranked observable triggers that route to the Fable procedure gates. If a trigger below matches what you are about to do, read the named file BEFORE doing it. |
Fable router
How to use this file: read it at task start, act only after checking your plan against
the trigger list, and return to it at every phase boundary (plan→code, code→green,
green→handoff). Triggers are ranked by how much quality is lost when missed — Tier 1
misses break production invisibly; Tier 3 misses cost polish. When in doubt whether a
trigger fired, it fired.
Always-on laws (no routing; violating any of these invalidates the work)
- Never edit a file you haven't fully read this session. Memory, diffs, greps, and docs
are claims, not file state.
- Green tests are the START of the audit, not the end of the task.
- Scope is one sentence plus an exclusion list with reasons, written before code.
Adjacent fixes become named follow-ups, never diff ridealongs.
- Label all evidence EXECUTED (ran it this session) or TRACED (reasoned only). A mock
you authored is TRACED evidence about the real system.
- Every finding, exclusion, and UNVERIFIED flag reaches the final report with file:line,
or it never happened.
TIER 1 — miss these and production breaks invisibly
T1.1 — Two facts about the code contradict each other (a value that shouldn't
validate but does, a field written twice with different values, a constraint the code
seems to violate). STOP EDITING → execution-loop.md §2. Cost of miss: "fixing" a
load-bearing workaround (e.g. a DB-constraint placeholder) and breaking prod writes.
T1.2 — Your next typed token is a URL path, query/body param, header name or value,
library option key, config key, CLI flag, version number, quota, or an import you
haven't used this session → grounding-gate.md. Also fires when: you're about to
claim an integration works and every test used a mock you wrote. Cost of miss: invented
API surface — compiles, passes local tests, fails only in production.
T1.3 — The task verb is a metaphor (retry, sync, duplicate, restore, share, migrate),
OR you cannot list the server's error responses, OR the feature touches anything
consumed (quota, credits, uploads, slots), OR the new row carries a group key
(batch_id/thread_id/parent_id), OR a branch in your plan references a field you haven't
confirmed exists → contract-gate.md. Cost of miss: the feature is built to the wrong
contract — double-charged quotas, corrupted group numbering, branches on prose.
T1.4 — You are about to add a fix at the place a symptom APPEARS (a render-time
dedupe, an index key, a swallowed warning, a defensive null-check where the crash was)
→ debug-protocol.md §4-5 first. Cost of miss: the bug becomes invisible instead of
fixed — negative value, because it also stops being findable.
TIER 2 — miss these and real bugs ship
T2.1 — All checks just went green and you feel done / are about to write the summary,
commit, or a quality claim → self-audit.md. Run the passes; exit enumeration and
boundary EXECUTION are mandatory even when rushed. Cost of miss (measured): a claimed
10/10 audited to 7.5 with one real boundary bug.
T2.2 — You are investigating any failure, test flake, or user-reported symptom —
especially if the word "sometimes" appears → debug-protocol.md from §1. No edit
before the written writer-list.
T2.3 — You are about to restructure working code ("clean up", "simplify",
"reorganize", "extract"), or a diff hunk you wrote reorders conditionals or converts
sequential awaits to Promise.all or swaps ||/?? → refactor-proof.md. Cost of miss
(measured): a tidy-looking reorder changed user-visible output on 47% of the input
domain while the full unit suite stayed green.
T2.4 — You are about to re-run a variant of something that just failed →
stop-tripwire.md. Also fires when: you just weakened a test/assertion/timeout without
announcing it; your fix exists to make a previous fix work; you caught a false success
and kept going. Cost of miss: compounding doubled-down attempts that the eventual
re-plan must also back out.
T2.5 — A verification check fails in code your diff does not touch →
execution-loop.md §5: prove pre-existence (stash → re-run → restore), never fix
out-of-scope, never silently skip the check.
TIER 3 — miss these and quality/velocity degrade
T3.1 — You are about to write code into an existing file, or create a file in a
directory with siblings of its kind, or the feature verb feels like it "should" already
exist → house-style.md. Grep the verb first — the cheapest outcome is finding it done.
T3.2 — You are designing a new function signature, or deciding how hardened code must
be → quality-ladder.md. Signatures get designed for 10 even when bodies build to 8.
T3.3 — You are about to review a diff (yours or anyone's) → defect-triggers.md.
Run the trigger list against the diff, not the taxonomy against the file.
T3.4 — You are writing tests, or just wrote branchy/parsing logic in a lib →
test-writing.md. The throw-hunt and boundary triplets are mechanical; run them.
T3.5 — A failed exact-match edit ("string not found") → re-grep the file's CURRENT
state before retrying; never rebuild the edit from the mental image that just failed.
(Inline rule — no file needed.)
Phase checkpoints (return here at each)
- Task start: read
execution-loop.md §1 (plus your own operator profile, if you keep one locally). Sweep
Tier 1 triggers against the task description — T1.3's metaphor-verb check takes ten
seconds and reshapes everything downstream.
- Before each code block: T1.2 fires per boundary token; T3.1/T3.2 fire per new
file/function.
- First green: T2.1 is unconditional. Do not negotiate with it.
- Before handoff: T3.3 against the final diff; confirm law 5 (all flags in report);
deploy checklist if your project has manual deploy steps.
Residual risk
These triggers work only when checked; in-flight noticing does not transfer as words.
Compensate mechanically: the four checkpoints above are the sweep schedule — run them
even when nothing feels wrong, ESPECIALLY when nothing feels wrong (confidence is what
the audit exists to check). When a gate seems wrong for your edge case, it is compressed
evidence you can't see — follow it or escalate; never silently override. Full evidence:
references/ inside this skill folder.
