Autopilot prompts must not just say “don’t ask questions” — they must redirect the asking instinct, eliminate phase-boundary pause points, and pre-decide every fork that would otherwise become a question.
Why: Claude’s training pushes hard toward “ask before ambiguous/risky action.” Saying “don’t ask” once at the top is too weak — every fresh decision point regenerates the asking instinct locally. The instinct cannot be suppressed globally; it has to be redirected (to log files, ntfy, commit messages) and the boundaries that trigger it have to be eliminated. The most-frustrating question is “Do you want to proceed?” because it surfaces at phase transitions — which is exactly where good prompts are most explicit it shouldn’t appear. Rich has been frustrated repeatedly by autopilot prompts that fail this way; this memory codifies the techniques that work.
How to apply: When writing any autopilot prompt (autonomous run, unattended session, “I am going for a run” prompt), include AS MANY of the techniques below as fit. Five most essential, in priority order:
1. Pre-decide the forks — Decision Matrix block
Most “shall I?” questions are forks Claude can’t resolve from context. Brainstorm the 5–10 likely forks BEFORE launch, write each pre-decision into the prompt:
DECISIONS PRE-MADE:
- If <command> errors with X, switch to Y and log as Phase-N finding (do NOT halt).
- If <tool> segfaults, capture trace and try <fallback> once before logging blocker.
- If git push rejects (non-fast-forward), pull --rebase, retry once, then ntfy
HALT-CANDIDATE; do NOT --no-verify.
- If a phase exceeds <T> min wall clock, commit partial + ntfy + move on.
2. Banned-phrasing list — concrete, not abstract
“Don’t ask questions” is too abstract. Claude paraphrases. Enumerate the actual phrasings:
ABSOLUTE PHRASE BAN (entire semantic family — Claude rephrases otherwise):
proceed / continue / ready / move on / next step / next phase / shall we /
shall I / let's / want me to / should I / good to go / carry on / press on /
advance / go ahead / on to / ok to / is it OK if / would you like / let me know
If you catch yourself about to type any of these — stop, delete, fire the next tool call.
3. Eliminate the boundary — phases as continuous chain
“Do you want to proceed?” surfaces at COMPLETION moments. Remove the boundary:
PHASE TRANSITIONS ARE AUTOMATIC, NOT GATED.
Completion of [N/7] IS the trigger for [N+1/7]. There is no pause between phases.
The only text you may emit at a phase boundary is exactly one line:
"[N/7] done → [N+1/7] starting"
— then the next tool call fires immediately in the same response.
4. “User unavailable” framing — make cost concrete
USER STATE: Rich is out for a 90-min run/swim. There is no return path during
this window. Any question = at least 90 min of blocked progress + a frustrated
user. Treat every moment you'd ask a question as a moment to (a) make the best
decision, (b) document it in the closure note, (c) carry on. The closure note
is where Rich will read your reasoning.
5. Redirect uncertainty to artifacts — write, don’t ask
IF UNCERTAIN, document — do NOT ask. Specifically:
- Decision uncertainty → rationale into the commit message.
- Findings ambiguity → raw-output/decisions.log with timestamp.
- Halt-candidate → ntfy "DECISION-NEEDED [N/7]: <one-sentence>" + chosen
default + carry on under that default. Do NOT block.
Other high-value techniques (include when applicable)
-
Narrow halt list — explicit list of conditions that halt; everything else continues:
HALT CONDITIONS (only these): 1. Data corruption / data loss imminent. 2. Legal / licence violation imminent. 3. Prompt contains literal <HALT> token. 4. Time-box exceeded. -
Output budget between phases — strictest version of #3: “exactly one line, no summaries, no questions, no reflections.”
-
Pausing IS the bug — flip the polarity: “If you find yourself at a ‘do you want to proceed’ moment, that moment is itself an error state. The correct recovery is: do not type; fire the next tool call.”
-
TodoWrite as commitment device — at session start, TodoWrite each
[N/7]item. Claude marches them off rather than inventing fresh questions. -
ntfy as ask-replacement — for genuinely consequential decisions, ntfy with
DECISION-MADE [N/7]: <what> (alt: <other>) — <rationale>. The decision is made; the ntfy is informational. -
Auto-halt time-box —
5h: ntfy "T-30min". 5.5h: commit-what's-done + ntfy "TIMEBOX HIT" + halt. -
Top-of-prompt and end-of-prompt restatement — repeat AUTOPILOT framing twice. End of prompt last line: “Final reminder: there is no ‘do you want to proceed’ step. Phase completion IS the proceed signal. Rich is on a run. Fire the next tool call.”
-
Pre-allow tool calls — for autopilot runs, either launch with
claude --dangerously-skip-permissionsOR add apermissions.allowallowlist to.claude/settings.jsoncovering the runbook’s tool calls (theupdate-configskill helps). -
Brainstorm-then-execute split — interactive brainstorming session BEFORE the autonomous run surfaces decisions that would otherwise become mid-run questions. Lock those in advance.
Diagnostic — when a prompt still asks
When a prompt asks despite all the above, look at the exact question. It identifies a fork the prompt didn’t pre-decide. Append the pre-decision to the Decision Matrix block of your prompt template. After ~5–10 runs, the template covers ~95% of forks.
Two passive signals that autopilot is working (without supervising)
- Heartbeats every 15 min with
[N/7]advancing — if they stop, something’s wrong. - No question-shaped ntfys — if you start seeing
DECISION-NEEDED [N/7]rather thanDECISION-MADE [N/7], refine the decision matrix for next time.
Boundary test
Before sending an autopilot prompt: count how many of techniques 1–5 are present. Fewer than 4 = NOT ready to send. Add the missing ones.