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.