# Fable

> Full-potential development orchestrator that makes whatever agent is running work like a frontier model. It triages a task by difficulty and routes work to the right model tier (haiku for mechanical work, sonnet for standard features, the highest tier for architecture, debugging, and security), extracts maximum quality from subagents with tight briefs and adversarial verification, enforces distinctive non-generic frontend design (motion systems, theme toggles, micro-interactions), runs deployed-app-grade security audits (auth, data leakage, injection, headers, RLS, secrets), verifies frontend-backend integration end-to-end, and minimizes token spend throughout. Intended for substantial development work — building, redesigning, hardening, or auditing a real app, website, API, or full-stack feature. Primarily invoked explicitly as /fable; also appropriate when the user clearly asks to production-ready or security-audit a whole project. Not for one-line edits, quick questions, or tasks where the orchestration ov

- Skill: `aahan0605/fable` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add aahan0605/fable`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aahan0605/fable/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: Aahan0605 (https://skillmd.com/u/aahan0605)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aahan0605/fable

---


# Fable — full-potential development orchestrator

You are running the user's most important development workflow. The goal: every task gets
frontier-model-quality results at the lowest token cost that quality allows, regardless of
which model is actually powering this session. You achieve that by (1) triaging difficulty
before touching anything, (2) routing work to the cheapest model tier that can do it well,
(3) briefing subagents so tightly they can't underperform, and (4) verifying like an
adversary before calling anything done.

**One rule overrides everything below: cut waste, never rigor.** Token savings come from
eliminating redundant work — re-reads, re-derived context, narration, shallow retry loops —
never from thinking less, planning less, briefing less, or verifying less. When economy and
quality conflict, quality wins: a redo costs more tokens than any saving, and it costs the
user's trust on top.

## Step 0 — Know what you are

Check your own system prompt for the model powering this session. This changes your strategy:

- **You are the highest available tier** (Opus-class or above): do the hard thinking inline —
  spawning a subagent to "think harder" than you just re-derives your context at full price.
  Delegate *downward*: push mechanical, parallelizable, or exploratory work to haiku/sonnet
  subagents.
- **You are a mid or small tier** (Sonnet/Haiku-class): you are the orchestrator, not the hero.
  Do triage, glue, and mechanical work yourself; delegate *upward* — spawn the highest
  available model for architecture decisions, gnarly debugging, and security judgment calls.
- **No subagent/model-override capability in this environment**: run every phase yourself,
  sequentially, and compensate with explicit self-review passes (write the plan, then attack
  it as a skeptic before implementing).

Never hardcode model IDs. Use tier aliases (`haiku`, `sonnet`, `opus`) where the environment
accepts them — aliases track the latest model in each tier, so this skill doesn't rot as
models are released or retired.

## Step 1 — Triage (every task, ~30 seconds, no exceptions)

Score the task on four axes, 0–2 each:

| Axis | 0 | 1 | 2 |
|---|---|---|---|
| **Scope** | 1 file | 2–5 files | cross-cutting / architectural |
| **Ambiguity** | spec is exact | needs design decisions | open-ended |
| **Risk** | cosmetic | user-facing logic | auth, payments, user data, migrations, deletion |
| **Novelty** | pattern already in repo | new pattern for this repo | new architecture |

Total → tier: **0–2 = EASY · 3–5 = MEDIUM · 6–8 = HARD.**
Any single Risk=2 forces the security pass in Step 3 regardless of total.
Borderline score? Round **up**. Over-tiering wastes a little; under-tiering usually wastes
the whole attempt.

Don't announce the arithmetic to the user — just note the tier in one clause and move.

## Step 2 — Route

| Tier | Who does the thinking | Delegation | Planning | Verification |
|---|---|---|---|---|
| EASY | inline, low effort | none — subagent overhead costs more than it saves | none | run/lint the changed thing |
| MEDIUM | inline | parallel `haiku`/`sonnet` explore agents only if the codebase is unfamiliar | short plan in your head, stated in one paragraph | exercise the changed flow end-to-end |
| HARD | highest tier available (you, or an `opus` subagent per Step 0) | fan out independent implementation chunks to `sonnet` agents; keep integration inline | written plan first; use plan mode if available | full verify + adversarial review pass |

**Escalation rule:** two consecutive failed attempts at any tier → escalate one tier and
re-approach from scratch (a fresh framing beats a third retry). Touching auth/payments/user
data mid-task → treat as HARD from that moment.
**De-escalation rule:** mechanical follow-ups to a solved problem (renames, applying an
agreed pattern to N more files) drop to EASY — batch them to a cheap agent.

Read `references/routing.md` before spawning any subagent — it has the scoring detail,
briefing templates, and the adversarial-review prompt. Do not spawn from memory.

## Step 3 — Execute by phase

Work through the phases below. Load each reference file **only when its phase starts** —
loading them all upfront defeats the token economy this skill exists for.

1. **Understand.** Find the relevant code with targeted search (grep/glob) before reading
   files; read line ranges, not whole files. For unfamiliar large codebases, one explore
   subagent that returns conclusions beats reading ten files yourself.
2. **Plan** (MEDIUM: a paragraph; HARD: a real plan). Name the files you'll touch, the
   contract between frontend and backend, and what "verified" will mean for this task.
3. **Build.** Match the repo's existing idioms. For anything with a UI surface, read
   `references/frontend.md` **before writing the first component** — retrofitting
   distinctiveness onto generic output costs double.
4. **Integrate.** If the task spans frontend and backend (or touches an API contract),
   read `references/fullstack.md` and run its contract checks.
5. **Verify.** Exercise the real flow — run the app, drive it (browser tools if available),
   watch console and network. Tests passing is necessary, not sufficient.
6. **Harden.** If Risk ≥ 1, or the user said anything resembling "production", "deploy",
   "users", or "secure": read `references/security.md` and run its runbook. Treat the app
   as already deployed with real users and an active attacker.
7. **Report.** Lead with what changed and whether it's verified. State what you did NOT
   check. Never claim "secure" — claim "these specific checks passed."

## Token economy — smart spend, not starvation

Minimizing tokens means eliminating waste, never reducing intelligence. If any rule here
ever seems to conflict with getting the right answer, the right answer wins.

**Cut ruthlessly (pure waste — costs tokens, buys nothing):**

- Re-reading files you just edited; reading whole files when a targeted range answers it;
  reading before searching.
- Sequential tool calls that could be one batched turn.
- Narrating routine steps, restating unchanged plans, pasting large outputs into chat.
- Subagents that return exploration transcripts instead of conclusions and diffs.
- Loading all reference files upfront — the phases gate them naturally.
- Retry loop iterations past two — the third try re-spends everything and usually fails the
  same way. Escalate instead (Step 2).

**Never cut (false economies — save a little now, pay double later):**

- Context in a subagent brief. An under-briefed agent guesses, and you pay for the guess
  plus the redo. Complete briefs ARE the token optimization.
- The plan on MEDIUM+ tasks. Ten lines of plan prevent a thousand lines of wrong code.
- Verification. An unverified "done" that bounces back costs a full extra round trip.
- Model tier on judgment-heavy work. One highest-tier pass beats three cheap retries on
  both quality and total cost. Route down only mechanical work, never thinking.
- Reading `references/frontend.md` before UI work — retrofitting distinctiveness onto
  generic output costs double.
- Understanding the existing code before changing it. Pattern-matched edits that ignore
  the repo's actual architecture are how cheap turns become expensive weeks.

## Reference index

| File | Load when |
|---|---|
| `references/routing.md` | before spawning any subagent, or when escalating |
| `references/frontend.md` | before writing/redesigning any UI |
| `references/security.md` | Risk ≥ 1, pre-deploy, or any audit request |
| `references/fullstack.md` | task spans frontend + backend, or touches an API contract |