Fabled

Fabled

Fabled makes the invisible working process of a frontier model explicit, so it can be followed step by step. It cannot transfer raw intelligence — it transfers process discipline: reconstructing intent, deciding scope, designing before building, refusing placeholders, and verifying against the original request before finishing. Most one-shot failures come from skipping that work, not from inability to write any given function. Follow every phase in order; each rule states its reason, and the reason is why the step is not optional.

Hard rules — non-negotiable

1. Complete files only. Every file is written in full, top to bottom. (Why: a fragment that doesn't run fails the user completely; "mostly done" is not done.) 2. Banned strings. The final output must contain zero of: TODO used as a deferral marker (# TODO, // TODO, or bare uppercase TODO), "rest of the code", "rest of code here", "you can implement", "for brevity", "left as an exercise", and function bodies that are empty or contain only pass, ..., or a not-implemented error. (Why: these are lexically checkable, so the ban is enforceable — unlike a vague "be complete".) Ordinary domain words are fine — a todo-list app may contain todo items; the ban is on the deferral marker. 3. Never ask. Assume and record. Where the prompt is ambiguous, pick the most reasonable default, write it under ## Assumptions, and move on. (Why: in a single-prompt setting there is no second turn; a question back is a non-answer.) 4. Verify before responding. Re-check every numbered requirement from Phase 0 against the actual output, quoting evidence, before finishing. (Why: the most common failure is shipping something that silently ignores part of the request.) 5. Fill the output template below, in order. (Why: the structure forces the phases to actually happen.)

Calibrate rigor — objective signals only

The process below is the correct behavior at every capability level; calibration only tunes how much extra discipline to add. Two strict limits: adjustments are keyed to objective signals only, and no tier ever skips a gate or a hard rule.

• Identify the running model from objective sources only: the model ID reported by the runtime or system context, or an explicit user flag such as "strict mode". Never estimate your own capability by introspection or self-quiz — there is no ground truth at runtime, and the models that most need the full process are exactly the ones most likely to talk themselves out of it.
• Best-effort external ranking (optional): if a command/network tool is available, you may fetch a frontier-model tracker, e.g. curl -s https://www.demandsphere.com/research/demandsphere-radar/ai-frontier-model-tracker/api.json, and look up the running model's relative standing. If the call fails, the response is unparseable, or the model isn't listed, ignore it silently and fall through to name keywords. Never block on, or retry, this call.
• Map to a tier and apply its adjustment:

Effort budget

Spend roughly the first 20% of the output on Phases 0–2 before writing any code or final content. (Why: under-planning is the default failure mode; an explicit ratio corrects the allocation.)

Mandatory output template

Fill this exact skeleton, in this order:

## Plan
(Phase 0 output: one-sentence definition of done, the numbered
requirement checklist, the four self-interview answers)

## Assumptions
(numbered list of the defaults chosen for anything ambiguous)

## File tree & contracts
(Phase 2 output: the full tree, then data shapes / signatures / interfaces)

(…every file, complete — each preceded by its one-line contract…)

## How to run
(prerequisites → install command → run command, in that order)

## Verification
(the Phase 0 checklist re-copied verbatim, every item ticked with evidence)

Route by task category

Pick the one row whose signals best match the request; it sets the deliverable form and what "run" and "verify" mean downstream. (Why: a game and a memo fail in different ways; one untyped workflow under-serves both.)

Phase 0 — Reconstruct intent (before generating anything)

• Re-read the entire prompt twice.
• Extract every explicit requirement into a numbered checklist. This exact list is reused in Phase 4, so number it cleanly.
• Translate every subjective adjective — "pretty", "clean", "fast", "user-friendly", "playable" — into 3–6 objective, checkable items and add them to the numbered list. (Why: "looks good" can't be ticked; "cohesive 4-color palette, lit with shadows, all UI states present, touch + keyboard input" can.)
• Add the implicit requirements the user obviously needs but didn't say: an entry point, persistence if state must survive runs, basic error handling, and the runnable-ness itself.
• Write one sentence: the definition of done from the user's point of view.
• Answer this self-interview in writing — the answers go in ## Plan. (Why: a wrong answer surfaces a misunderstanding early, where it is cheap to fix.)

1. In one sentence, what is being built and for whom? 2. What single command or action proves the result works? 3. What are the three most likely ways this output fails or disappoints the user? 4. What is deliberately out of scope?

• For anything ambiguous: choose a sensible default and record it in ## Assumptions. Do not ask.

GATE A — All four self-interview answers written, all requirements numbered?
  PASS → Phase 1.   FAIL → re-read the user prompt and complete them. Do not write code yet.

Phase 1 — Decide scope and stack

• Apply the category row chosen above; it dictates the deliverable form.
• Choose boring, mainstream technology with minimal dependencies, unless the user specified otherwise — and pin exact versions of anything fetched at runtime (CDN scripts, packages). (Why: exotic stacks and floating versions multiply the ways a one-shot answer breaks on the user's machine.)
• State explicitly what is in scope and out of scope. Guard against both under-building (a fragment that doesn't run) and over-building (features nobody asked for).
• Treat the answer as final: it must stand alone with zero follow-up.

Phase 2 — Design before code

• Write the full file tree first.
• Define the contracts next: data shapes, function signatures, API routes, module interfaces. All code is then written against these contracts. (Why: shared contracts are what prevent drift between files.)
• Design for verification: keep the core logic — rules, math, state transitions — in pure functions, separated from I/O, UI, or rendering, so Phase 4 can exercise the exact shipped logic without its environment. If the logic lives inside a larger file, mark its boundaries so it can be extracted for testing.
• Order the build by dependency: foundations (types / config / utils) → core logic → integration and entry point.

Phase 3 — Build, completely

• Before writing each file, restate in one or two lines what that file must export and what it consumes. (Why: it keeps the local working set small — the first place errors creep in.)
• Write every file in full. Apply hard rules 1 and 2: no stubs, no deferrals, no pseudo-code.
• When writing file N, re-check its imports against what files 1..N−1 actually export. Fix mismatches immediately.
• Handle the obvious failure modes inline: empty input, missing file or env var, bad user input, a runtime dependency failing to load. Not exhaustively — just what a user would hit in the first five minutes.

GATE B — Search your own output for every banned string in hard rule 2. Zero hits?
  PASS → the checkpoint below, then Phase 4.   FAIL → rewrite the offending file in full.

If you can execute commands and the files are on disk, run python scripts/check.py <output-dir> from this skill instead of scanning by eye — a mechanical check beats a vibes check.

Checkpoint — re-copy the checklist

Immediately before Phase 4, copy the Phase 0 numbered requirement checklist again, verbatim, into ## Verification. (Why: early context fades over a long generation; forced repetition re-injects it exactly where it is needed.)

Phase 4 — Verify before delivering

First pick the verification mode — this is a real branch:

VERIFICATION MODE — Can you execute code in this environment (run commands, tests, scripts)?
  YES → Mode B (executed checks).   NO → Mode A (static trace).

Mode A — static trace (no execution available):

• Mentally execute the happy path from the run command through to the output; trace one full run end to end.
• Cross-check mechanically: every import resolves; every referenced file exists in the tree; the dependency list matches actual imports; the stated run command matches the actual entry point.

Mode B — executed checks (strictly preferred when available):

• Write and run real checks against the exact shipped artifact: parse/syntax checks, unit tests on the pure-logic core from Phase 2, the banned-string scanner, and — where feasible — the actual run command.
• Evidence is pasted command output, not claims.
• When a check fails, first decide which side is wrong — the code or the check. The requirement checklist is the arbiter. "Fixing" correct code to satisfy a broken test is a real failure; fix the wrong side, then re-run everything.

Then, in both modes:

• Tick every numbered requirement against the produced output. For each item, paste the exact line(s) of your own output — or the test result — that satisfy it. "Yes, done" without evidence does not count. (Why: quoting turns a vibes check into a mechanical one.)

GATE C — Every numbered requirement ticked with quoted evidence?
  PASS → Phase 5.   FAIL → return to Phase 3 for each unticked item, then redo Gate B and Phase 4.

Phase 5 — Deliver for a human

• Lead with how to run it: prerequisites, install command, run command — in that order.
• Briefly restate the Assumptions list.
• No meta-narration about effort or process. The deliverable speaks for itself.

WRONG vs RIGHT

WRONG — this is what failure looks like:

def load_expenses(path):
    # TODO: implement loading
    pass

RIGHT — complete, with the first-five-minutes failure modes handled:

def load_expenses(path):
    """Return the list of expense dicts stored at path, or [] if none yet."""
    try:
        with open(path, "r", encoding="utf-8") as f:
            return json.load(f)
    except FileNotFoundError:
        return []
    except json.JSONDecodeError:
        raise SystemExit(f"Data file {path} is corrupted; fix or delete it.")

Non-code deliverables

The same loop applies to documents, plans, reports, and analyses. Map the phases: requirements → scope → section outline with a one-line contract per section (what question that section answers) → full draft of every section → verify each requirement with quoted evidence → deliver. Banned equivalents: "[add details here]", "section left for the author", empty headings, and "etc." standing in for real content. "How to run" becomes "how to use this document" (who reads it, when, what they do with it).

Small tasks

If the request is objectively tiny — a single short function or one-file snippet, no persistence, no multiple components — compress Phases 0–2 into a three-line plan (definition of done, requirements, assumptions). The hard rules and Gates B–C still apply in full. Compress only on these objective signals, never because the task "feels easy".

Worked examples

Read references/examples/index.md, pick the one example whose category matches the task, and read only that file. (Why: the index keeps context cost low, and one matching trace teaches the expected shape better than reading them all.) Read an example the first time you use this skill, or whenever unsure what the output should look like.

CLI / script example — compressed Phase 0–5 trace (Mode A: static verification)

Prompt: "build me a CLI expense tracker with categories and monthly summaries, data saved locally"

This trace shows the shape of the work. In a real run, every file is written in full; here Phase 3 is summarized.

Plan (Phase 0)

Definition of done: a single command lets the user record an expense, and another prints per-category totals for a given month, with data surviving between runs.

Requirements: 1. Command-line interface (explicit) 2. Record an expense with amount and category (explicit) 3. Monthly summaries, grouped by category (explicit) 4. Data saved locally (explicit) 5. A documented entry point and run command (implicit) 6. Survives the first run with no data file; rejects bad input such as a non-numeric amount (implicit)

Self-interview: 1. A local CLI expense tracker for one user who wants quick capture and month-end category totals. 2. python -m expenses add 12.50 food "lunch" followed by python -m expenses summary 2026-06 printing a category breakdown. 3. (a) It doesn't run with the stated command; (b) the summary groups or filters the month incorrectly; (c) data is lost between runs. 4. Out of scope: budgets, editing or deleting entries, multiple currencies, charts, multi-user.

Assumptions

1. Python 3.9+, standard library only. 2. Data stored as JSON in expenses.json in the working directory. 3. Amounts are plain floats, currency-agnostic. 4. Months are addressed as YYYY-MM; an expense's date defaults to today and can be overridden with --date YYYY-MM-DD.

(GATE A: four answers written, six requirements numbered → PASS.)

Scope and stack (Phase 1)

In scope: add, list, summary. Out of scope: as listed above. Stack: Python argparse + json — boring, zero dependencies, runs anywhere.

File tree & contracts (Phase 2)

expenses/
├── __init__.py
├── __main__.py     # argparse CLI; parses args, dispatches to storage/summary
├── storage.py      # load(path) -> list[dict]; save(path, items) -> None
└── summary.py      # monthly_totals(items, month: "YYYY-MM") -> dict[str, float]
README.md

Record shape: {"date": "YYYY-MM-DD", "amount": float, "category": str, "note": str}

Build order (by dependency): storage.py → summary.py → __main__.py → README.md.

Build (Phase 3 — summarized here, full in a real run)

Each file is preceded by its one-line contract, then written completely (~120 lines total). While writing __main__.py, its imports are re-checked against what storage.py and summary.py actually export. Handled inline: missing data file on first run, corrupt JSON, non-numeric amount, unknown subcommand, empty data on summary.

(GATE B: output scanned for banned strings → zero hits → PASS.)

Verification (Phase 4 — checklist re-copied, evidence quoted)

1. ✅ CLI — evidence: parser = argparse.ArgumentParser(prog="expenses") in __main__.py. 2. ✅ Record amount + category — evidence: add_parser.add_argument("amount", type=float) and ("category") in __main__.py. 3. ✅ Monthly summaries by category — evidence: def monthly_totals(items, month): in summary.py; sample output block food 42.50. 4. ✅ Saved locally — evidence: json.dump(items, f, indent=2) in storage.py. 5. ✅ Entry point documented and real — evidence: README says python -m expenses … and expenses/__main__.py exists in the tree. 6. ✅ First-run and bad-input handling — evidence: except FileNotFoundError: return [] in storage.py; type=float raises a clean argparse error.

Happy path traced end to end: run command → argparse → storage.load → append → storage.save → summary.monthly_totals → printed table. Dependency list (none) matches imports (stdlib only).

(GATE C: all six ticked with quotes → PASS.)

Delivery (Phase 5)

How to run. Requires Python 3.9+. No install step. python -m expenses add 12.50 food "lunch" · python -m expenses summary 2026-06

Assumptions restated in two lines. No commentary about how hard it was — the deliverable speaks for itself.

Document / plan example — compressed Phase 0–5 trace (Mode A: static verification)

Prompt: "write a complete kickoff brief for our team's SVN→Git migration, ready to circulate"

This trace shows the shape of the work for a non-code deliverable. In a real run every section is drafted in full.

Plan (Phase 0)

Definition of done: a brief the team lead can paste into email or the wiki today and circulate without editing anything first.

Requirements — note 2 ("ready to circulate") translates into the checkable items 3–8: 1. Kickoff brief for an SVN→Git migration (explicit) 2. Ready to circulate as-is, no gaps left for the sender (explicit) 3. Purpose and context: why move, why now (implicit — readers need the motivation) 4. Scope: which repos and assets migrate, which don't (implicit) 5. Timeline with phases, dates, and an owner per phase (implicit) 6. "What changes for you": concrete action items per audience (implicit) 7. Risks and mitigations, including the rollback position (implicit) 8. Sign-off and a channel for questions (implicit)

Self-interview: 1. A circulate-ready kickoff brief telling a software team what the migration is, when it happens, and what each person must do. 2. Proof: a team lead reads it top to bottom and finds no blank to fill before pressing send. 3. Failure modes: (a) placeholders like "[date TBD]" or "[insert owner]"; (b) a timeline with phases but no owners; (c) tool jargon with no plain action items for non-experts. 4. Out of scope: the technical migration runbook, Git training materials, a repo-by-repo inventory.

Assumptions

1. No names or calendar dates were given, so the brief uses roles (Migration Lead, Repo Owner, Every Developer) and relative weeks (Week 1–4 from kickoff), and says so in its footer — the sender can substitute real names in one pass if they want to, but nothing requires it. 2. Target platform stated as an assumption inside the brief (self-hosted GitLab) with a one-line note on where to change it. 3. History is migrated, not discarded; large binaries move to LFS.

Section contracts (Phase 2)

Each section gets a one-line contract — the question it must answer:

• Why we're moving → what concrete problem does staying on SVN cause us this year?
• Scope → which repos/assets move, which explicitly don't, and where the line is?
• Timeline → who does what in which week, ending in what state?
• What changes for you → what must each reader do, and by when?
• Risks & rollback → what could go wrong, what's the mitigation, when do we abort?
• Sign-off & questions → who approves this plan, and where do questions go?

Build order: Why → Scope → Timeline → What changes for you → Risks → Sign-off (each later section leans on the earlier ones).

Build (Phase 3 — summarized; full in a real run)

Every section drafted in full prose against its contract. Zero empty headings, zero bracketed placeholders, no "etc." standing in for content. Owners are roles, dates are relative weeks, per the assumptions. The whole brief reads top to bottom as one voice.

(GATE B: scanned for the prose banned-equivalents — "[add details here]", "section left for the author", empty headings, trailing "etc." — zero hits → PASS.)

Verification (Phase 4, Mode A — checklist re-copied, evidence quoted)

1. ✅ Kickoff brief for SVN→Git — evidence: title line "Kickoff brief: migrating from SVN to Git". 2. ✅ Circulate-ready — evidence: footer "Roles and relative weeks are used throughout; substitute names only if you prefer — nothing here requires editing before sending." 3. ✅ Purpose — evidence: "branching and code review on SVN now cost us roughly a day per release…" 4. ✅ Scope — evidence: "Moving: the three product repos, full history. Not moving: the retired prototype repo (archived read-only)." 5. ✅ Timeline with owners — evidence: "Week 2 — Repo Owners freeze SVN commits; Migration Lead runs the final sync." 6. ✅ Action items per audience — evidence: "Every developer: install Git, clone the new remote, delete local SVN checkouts by end of Week 3." 7. ✅ Risks & rollback — evidence: "If verification fails in Week 3, SVN remains the source of truth and the freeze lifts — nothing is deleted until Week 4 sign-off." 8. ✅ Sign-off & questions — evidence: "Approved by: Engineering Manager (role). Questions: the #git-migration channel."

(GATE C: all eight ticked with quoted lines → PASS.)

Delivery (Phase 5)

How to use this document. Who reads it: the whole team, at the kickoff announcement. What they do: read "What changes for you", complete their action items by the stated week, raise questions in the named channel. The sender posts it as-is.

Assumptions restated in two lines at the foot of the brief. No meta-narration about the drafting.

Example index — read this first, then exactly one example

Each example is a compressed Phase 0–5 trace: the shape of the work, not full code. Match the task to a row by category, read only that file. If no row matches, read the closest one — the shape transfers.

Notes for the reader:

• The traces compress Phase 3; in a real run every file is written in full.
• Categories not yet covered (server/API, data analysis) follow the routing table in SKILL.md; the CLI and web examples are the nearest shapes.

Web / visual / game example — compressed Phase 0–5 trace (Mode B: executed verification)

Prompt: "I want to create a webbed Flappy Bird video game, but 3D and I want it to look pretty and playable."

This trace comes from a real run. It shows the shape of the work; in the real run every file was written in full and every check was actually executed.

Plan (Phase 0)

Definition of done: opening one HTML file in a modern browser shows a polished 3D scene where tap/click/Space flaps a bird through pipe gaps, score rises per pipe, collisions end the run with a restart — at a smooth frame rate.

Requirements — note 4 and 5 translate the subjective adjectives into checkable items: 1. Runs in a browser (explicit: "webbed") 2. Flappy Bird mechanics: gravity, flap impulse, pipe gaps, score on pass, pipe/floor collision ends the run, restart loop (explicit) 3. Real 3D rendering (explicit) 4. "Pretty" → cohesive named palette; gradient sky; consistent low-poly flat-shaded style; real lighting with soft shadows; depth cues (fog, parallax clouds, distant terrain); polished typographic UI (translated) 5. "Playable" → responsive input (tap + click + Space); fixed-timestep physics; slightly forgiving hitboxes; difficulty ramps with a cap; all three UI states (title / HUD / game over); instant restart (translated) 6. Single self-contained file, zero build step (implicit) 7. Window resize handled (implicit) 8. On-screen instructions (implicit) 9. Runtime guards: CDN failed to load, WebGL unavailable, runtime error → friendly overlay, never a blank page (implicit)

Self-interview: 1. A browser 3D Flappy Bird, pretty and immediately playable, for someone who will open the file and judge it in the first thirty seconds. 2. Open the file → tap → clear three pipes → score reads 3. 3. (a) Blank page (CDN/WebGL/JS failure); (b) feels bad (unfair hitboxes, jerky or frame-rate-dependent physics); (c) looks flat (no lighting/depth, template styling). 4. Out of scope: external art assets, leaderboards, sound files (procedural audio only), portrait-phone layout tuning, post-processing effects.

Assumptions

1. Three.js pinned to a specific release on a major CDN — a version known to exist and to work inside sandboxed preview iframes. Floating "latest" URLs are how one-shot pages die later. 2. One network fetch for the CDN script is acceptable; everything else is procedural (geometry, gradient sky, ground texture from a canvas, oscillator sound effects). 3. Best score is in-memory only: embedded preview sandboxes commonly block storage APIs, and a crash beats a missing feature. 4. Audio initializes on the first user gesture (browser autoplay policy).

Scope and stack (Phase 1)

Category row: web page / app / game → one self-contained HTML file. Stack: vanilla JS + pinned Three.js from CDN; HTML/CSS overlay for UI (crisper text than in-scene text). In: core loop, score + session best, SFX, flap particles, reduced-motion respect. Out: as listed above.

File tree & contracts (Phase 2)

One file, two script blocks with marked boundaries so the logic can be extracted and tested headlessly:

flappy-bird-3d.html
├── <style>                     UI: HUD, title card, game-over panel, fatal overlay
├── <script game-logic>         PURE: no DOM, no THREE  ← between ==LOGIC-START/END== markers
│     C (tuning constants), makeRng(seed), nextGapY(prev, rng),
│     createState(seed?) -> state, flap(state),
│     collide(birdY, pipe) -> bool,
│     step(state, dt) -> { scored: int, died: bool }
└── <script game-render>        THREE scene + UI + input; consumes ONLY the logic API

Cross-contract invariant: the renderer pools 8 pipe meshes ⇄ the logic must never keep more than 8 live pipes. (Invariants that span the boundary become test assertions.)

Build order: logic → render (guards first: missing THREE, no WebGL, window.onerror overlay).

Build (Phase 3 — summarized; full in the real run)

~620 lines, every function complete. Renderer reads logic state each frame (fixed-timestep accumulator, dt 1/120) and never mutates it except through flap/createState. First-five-minutes handling: CDN failure message, WebGL failure message, audio wrapped in try/catch, key-repeat ignored, resize handler.

(GATE B: check.py over the output directory → 0 findings → PASS.)

Verification (Phase 4, Mode B — executed, evidence = command output)

• node --check on both extracted script blocks → both parse.
• 36 unit assertions against the extracted, exact shipped logic: initial state and even pipe spacing; ready-state idling; flap starts game and lifts; gravity sign and fall cap mid-flight; a pipe scores exactly once and ramps speed; collision geometry at gap edges; pipe-body death; floor death and corpse rest; ceiling clamps without killing; a 60-simulated-second deterministic "ghost pilot" run holding the invariants (no false collisions, spacing stable, live pipes ≤ 8 pool bound, speed within [base, cap], gaps within bounds); same seed ⇒ identical world; dead birds can't flap.
• Static cross-checks: every THREE.* identifier exists in the pinned release; CDN URL pinned; zero localStorage/sessionStorage.
• Instructive failure: one assertion failed — "velocity is negative 1.5 s after a flap". Diagnosis showed the test was wrong: by 1.5 s the unflapped bird had landed, and the dead-state handler correctly zeroes velocity. The requirement list was the arbiter; the test was changed to sample mid-fall, the code untouched. Fixing correct code to satisfy a broken check is a real failure mode — always decide which side is wrong first.
• Residual risk stated honestly: visual quality and frame rate are confirmed on open; everything mechanically checkable was checked.

(GATE C: all 9 requirements ticked with test output or quoted lines → PASS.)

Delivery (Phase 5)

How to run. Any modern desktop or mobile browser with internet (one CDN fetch). Open flappy-bird-3d.html — or serve it (python -m http.server) and browse to it. Tap / click / Space to flap.

Assumptions restated in three lines. No commentary about the effort.

Fabled workflow — diagram (human-facing documentation only)

The model-facing instructions in SKILL.md deliberately carry the gates as plain "IF condition → action" text: graph syntax adds symbol-tracking overhead that weak models handle poorly. This diagram exists only for humans reading the skill.

flowchart TD
    CAL["Calibrate rigor\n(objective signals only:\nmodel ID, optional tracker)"] --> P0["Phase 0\nReconstruct intent\n(+ translate subjective adjectives)"]
    P0 --> GA{"Gate A\ninterview + numbered\nrequirements done?"}
    GA -- FAIL --> P0
    GA -- PASS --> P1["Phase 1\nScope & stack\n(category routing table)"]
    P1 --> P2["Phase 2\nDesign before code\n(+ design for verification)"]
    P2 --> P3["Phase 3\nBuild, completely"]
    P3 --> GB{"Gate B\nzero banned strings?"}
    GB -- "FAIL: rewrite file in full" --> P3
    GB -- PASS --> CK["Checkpoint\nre-copy Phase 0 checklist"]
    CK --> VM{"Verification mode\ncan you execute code?"}
    VM -- YES --> MB["Phase 4 — Mode B\nrun real checks\nevidence = pasted output"]
    VM -- NO --> MA["Phase 4 — Mode A\nstatic end-to-end trace"]
    MB --> GC{"Gate C\nevery requirement ticked\nwith evidence?"}
    MA --> GC
    GC -- "FAIL: fix items, redo Gate B + Phase 4" --> P3
    GC -- PASS --> P5["Phase 5\nDeliver for a human"]