# Fable Mode > Execute a whole job end-to-end autonomously from a loose goal, self-verify, and hand back the deliverable plus a review queue. Use when the user says "fable mode", "hand this whole job to Claude", "run this end to end and come back to it", "do the whole thing, don't hover", gives a /goal-style outcome and walks away, or wants a batch/multi-step deliverable produced unattended. Not for quick single answers or turn-by-turn work. - Skill: `campbellsmurphy/fable-mode` (Agent Skill) - Install (CLI): `npx skillmds@latest add campbellsmurphy/fable-mode` - Raw SKILL.md: https://api.skillmd.com/api/skills/campbellsmurphy/fable-mode/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: campbellsmurphy (https://skillmd.com/u/campbellsmurphy) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/campbellsmurphy/fable-mode --- # Fable mode: handing Claude a whole job Adapted from **Nate Herk**'s "handing AI whole jobs" pattern: a `/goal` prompt, walk away, come back to a finished deliverable. The thesis: the model is no longer the bottleneck, our habit of handing it *ask-size* prompts is. The learnable skill is **detailed task imagination**: specify the whole job an operator would do, set the bar for "done", then get out of the way. This skill is the *discipline* around autonomous execution, not a new engine. It assumes a harness with sub-agents, some form of workflow or fan-out, and a verification step available; use whichever of those your setup has. ## When this fires vs when it doesn't - **Fires:** a bounded but multi-step deliverable that a competent operator could finish alone: build or refactor a thing, produce a report, migrate or sweep a corpus, wire a pipeline, generate a batch of artifacts. Something with a checkable "done". - **Doesn't:** a single question, a decision that needs the user's judgment first (grill it out with `grill-me` instead), or anything where they want to review each step. If the goal is genuinely ambiguous or the stakes are irreversible-and-unclear, stop and clarify. Don't imagine a job nobody asked for. ## Step 1: Write the Whole-Job Spec Expand the loose goal into a spec before touching anything. Nine fields: 1. **Goal**: the outcome in one sentence, as a done-state ("X exists and passes Y"), not a task list. 2. **Deliverable**: the concrete artifact(s) handed back, and exactly where they land (file paths, a PR, a note). 3. **Acceptance criteria**: a checklist that *defines* done. Each item independently verifiable (a command runs clean, a page renders, a number reconciles). This is the contract; if you can't write it, the job isn't specified yet. 4. **Context and inputs**: where the needed context already lives (files, MCP connections, CLIs). Point at sources; don't re-ask for what's on disk. 5. **Constraints and guardrails**: scope boundaries, what NOT to touch, budget or token ceiling, and the **permission layer**. A prompt is never a permission boundary: if a credential *can* do a thing it *will*, so prefer scoped, read-only or draft-not-send access and say which destructive actions are off-limits. 6. **Autonomy and stop conditions**: how far to run unattended, and the explicit conditions that force a stop-and-surface (spend cap hit, an acceptance criterion provably unmeetable, a guardrail would be violated, or data loss risk). 7. **Review queue**: decisions it is genuinely unsure about get **logged, not guessed, and not blocked on**. The job keeps moving; uncertain calls collect for the user at the end. 8. **Verification method**: how each acceptance criterion gets *proven*. Run the tests, drive the flow, open a browser and click through, re-read the output as a fresh persona (beginner, engineer, owner). 9. **Handback format**: the summary returned at the end (see Step 4). **Confirm the spec once before running.** Autonomous end-to-end work is hard to unwind, so show the spec (tight, not ceremonial) and get a single go-ahead, unless the user already said "just go, don't check in", in which case proceed and note the assumptions inline. This is the one checkpoint; after it, run. ## Step 2: Run the whole job, don't hover - Execute end-to-end toward the acceptance criteria. Keep working; don't stop after each step to ask "shall I continue?". - Fan out with a workflow or sub-agents when the job decomposes (parallel items, independent sections). Each sub-agent does one thing and returns a clean summary to the orchestrator, to avoid context rot. Reserve the main context for assembly and verification. - Respect the token ceiling from field 5. If the user gave a budget, scale depth to it and stop cleanly when it is spent rather than half-finishing. - When you hit an uncertain call, **log it to the review queue and keep going**. Only a stop-condition (field 6) halts the run. ## Step 3: Self-verify before handing back Do not report "done" on assertion. For **each** acceptance criterion, actually prove it by its verification method: run the command and show output, drive the flow, click through the rendered artifact, reconcile the numbers. If a criterion fails, fix and re-verify; that loop is the job, not an optional extra. A criterion you couldn't verify is reported as *unverified*, never as passed. ## Step 4: Handback Return a tight report: - **Goal** (one line) and **verdict**: done, partial, or blocked. - **Acceptance criteria**: each with verified (and how), unverified, or failed. - **Deliverable**: what was produced and where it lives. - **Review queue**: the uncertain calls, each as decision plus what you assumed plus why it needs human eyes. - **Skipped or out of scope**: anything deliberately not done, and why. No silent truncation. ## Guardrails - **Never invent the job.** Expanding an ask into a whole job is "detailed task imagination", not scope creep. Stay inside what the user actually wants. When the expansion is non-obvious, the Step 1 confirmation is where it gets caught. - **Keys, not prompts.** Assume any capability the run has, it may use. Prefer scoped, read-only or draft access; call out irreversible actions in the spec and don't take them without explicit sign-off. - **Verify honestly.** Report failures and unverified criteria plainly with the evidence. A passed-looking summary over a broken deliverable is the worst outcome. - **The spec is the IP.** A good Whole-Job Spec is reusable: if this job will recur, offer to save the spec (as a project note or its own skill) so next time is a one-liner.