القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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. |
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.
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.
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.
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.)
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.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.