Claude Fable 5 is built for long-running coding and knowledge work. That changes what a useful prompt needs to control.

A short chat answer fails in front of you. A long agent run can spend hours following a wrong assumption, modify a wide surface, and return a polished completion summary.

I now write prompts as execution contracts, not requests for effort.

Define the boundary before the goal

“Improve authentication” gives a capable model room to redesign policy, data, API behavior, and UI at once.

I name the outcome and the boundary separately:

Outcome: Add passkey sign-in for existing accounts.
In scope: WebAuthn registration, sign-in, migrations, tests.
Out of scope: Account recovery, UI redesign, session policy.
Preserve: Existing password sign-in and API response shapes.

The out-of-scope list matters more on long runs. It prevents the model from treating nearby improvements as implied work.

Ask for a preflight plan

Before implementation, I ask the model to inspect the repository and return:

  • the current request and data flow;
  • files and interfaces likely to change;
  • migrations or compatibility risks;
  • the verification ladder;
  • unresolved decisions that require me.

The model should stop after preflight when an answer could change architecture or user behavior. Silence is not permission to pick a convenient default.

Once the plan is accepted, I ask it to execute in small checkpoints. Each checkpoint should leave a testable state, not a pile of half-edited files.

Write stop conditions

Autonomy needs brakes. I tell the agent to stop when:

  • required credentials or external access are missing;
  • tests expose a requirement conflict;
  • the task requires a public API or schema change outside scope;
  • existing user edits overlap the target;
  • verification cannot run in the current environment.

Without a stop condition, a proactive model may invent a workaround. That can hide the exact decision a person needed to make.

Require evidence, not a completion story

My prompt defines the proof before coding begins:

Verification:
1. Run focused unit tests.
2. Run integration tests for registration and sign-in.
3. Build the application.
4. Exercise the flow in a browser.
5. Inspect the final diff for unrelated changes.

Report:
- commands and exit results;
- behavior checked manually;
- unverified assumptions;
- files changed and why.

“Tests pass” is not enough. I want the command, the scope of the tests, and any part that could not run.

For visual work, a build proves compilation, not appearance. For database work, compilation proves neither the migration nor rollback. Match the evidence to the failure mode.

Protect the working tree

Long runs touch more files and are more likely to meet unrelated work. I explicitly tell the agent to inspect Git status, preserve user changes, and avoid cleanup outside the task.

I also request small semantic commits only after verification. A readable history gives me checkpoints for review and recovery.

Review the right artifacts

I do not read only the final answer. I inspect:

  1. the accepted plan;
  2. the changed public contracts;
  3. migrations and security-sensitive code;
  4. new tests and whether they can fail for the right reason;
  5. the complete diff;
  6. the verification output.

The stronger the model, the easier it is to trust fluent explanations. The review should become more evidence-based as the run becomes more autonomous.

Fable 5 can carry a larger task. I get better results when the prompt makes the task’s limits, decision points, and proof just as large.