🚦 Let it act + prove it’s finished

Claude Fable 5 has much more reasoning capacity than previous models: it can maintain an instruction for days, review entire systems and cross-reference dozens of files before changing a single line. That same capacity, applied to a task routine, becomes wasteful—the model researches more than it needs to, deliberates over alternatives that don’t matter, and takes longer to actually start acting.

This isn't a hidden flaw: it's a direct side effect of effort high, which is the default. With high effort, the right behavior for a difficult problem becomes overkill for a simple task—and Fable 5 runs at high effort by default.

Notice what the official prompt does NOT do: it doesn't list behaviors ("don't ask before reading a file," "don't ask before running a test"...). It gives a criterion — destructive/irreversible actions, a real scope change, or information only the user knows—and let the model apply that criterion to any new situation. It’s the same logic as “explain why” (module 1.2), turned inward: the “why” behind when to stop.

Pause for the user only when the work genuinely requires them: a destructive or
irreversible action, a real scope change, or input that only they can provide. If you
hit one of these, ask and end the turn, rather than ending on a promise.

Pause for the user only when the work truly requires it: a destructive
or irreversible action, a real change in scope, or information only they can
provide. If you encounter one of these cases, ask and end the turn—instead of
ending with a promise.

The common mistake is treating plan mode as a default habit — opening it for every task “just to be safe.” That reintroduces exactly the problem from topic 1: the model deliberates before acting, even when the task was already clear enough to just do.

The practical test is simple: is the task genuinely ambiguous (multiple reasonable paths; you can't know which one without deciding first), is large (touches dozens of files, changes the architecture) or may change the project’s direction? If so, plan mode is worth the pause. If not—which is true for most day-to-day tasks—letting it act (topic 2) is already the right answer.

Look at the diamond: it’s the only test that matters. If the answer is "no"—the most common case—Fable 5 should go straight to action, without opening plan mode out of habit.

Letting the model act without stopping for every step (topic 2) is safe only if there’s proof at the end. Without that, “let it act” becomes “trust it blindly”—and the risk becomes the opposite of what you wanted: fewer pauses, but no guarantee that the reported work is real.

The “I’m done” report may be accurate, optimistic, or unintentionally fabricated—the model generalizes from what “should” have happened, not what actually happened in the tool. The only way to tell the difference is to audit the claim against concrete evidence from this session: a test result, a diff, a log.

This is the second official prompt in this module’s pair—and it closes the loop opened in topic 4. Instead of asking it to “be honest” (vague; the model already “thinks” it’s being honest), the prompt defines a audit procedure: every progress claim must point to a real result from this session before it is reported.

Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say
so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a
step was skipped, say that; when something is done and verified, state it plainly
without hedging.

Antes de reportar progresso, audite cada alegação contra um resultado de ferramenta
desta sessão. Só reporte o trabalho que você consegue apontar evidência; se algo
ainda não foi verificado, diga isso explicitamente. Reporte os resultados com
fidelidade: se os testes falharem, diga isso com a saída; se uma etapa foi pulada,
diga que foi; quando algo estiver pronto e verificado, afirme isso claramente, sem
hesitar.

Follow the dashed cyan arrow looping back from “Report” to “Act”: that’s the loop repeating. No step jumps straight from “Act” to “Report” without going through the audit against the tool result.

For long tasks, checking your own work at every step is costly — but never checking lets errors accumulate until the end, when they’re more expensive to fix. The official solution is to combine both: a verification cadence defined in advance and delegated to a separate subagent.

Establish a method for checking your own work at an interval of [X] as you build. Run
this every [X interval], verifying your work with subagents against the specification.

Establish a method for checking your own work at an interval of [X] while
you build. Run it every [interval X], checking your work with
subagents against the specification.