I keep a small block of text at the top of every Claude session I run for more than a few turns. It looks like project boilerplate, but it is not. It is a behavioral rule that flips a default I would otherwise be fighting every time the model thinks my prompt is fuzzy.
Before I added the rule, Claude would pause and start a back-and-forth about my goals whenever I asked for a draft. Book chapter outline. Same thing. Email draft. Same thing. Quick research summary. Same thing. I was paying for intake interviews I did not want, on prompts where I already knew what I wanted and just needed something to react to.
Adding one short paragraph at the top of my prompts changed the default. The model now leans toward answering instead of asking, and I only get the clarifying questions when I have asked a question that genuinely cannot be answered without more context.
Why a model pauses for a clarification round
Large language models are trained to be helpful, and one of the cheapest ways to look helpful is to ask. If my prompt has more than one reasonable answer, asking me to choose is a safe move that does not commit the model to a path that might be wrong. That is fine when I am actually lost. It is expensive when I am not.
The asymmetry is the part that bothered me. Asking is cheap for the model and free for the user, but answering is also free for the model and what I actually wanted in the first place. Every clarification round burns a turn I could have spent on the real answer, and I started measuring that cost in time.
Across a few months of using Claude daily I landed on a simple split:
- Some prompts are genuinely ambiguous and need a back-and-forth. Those prompts deserve the clarifying round.
- Some prompts are clear to me and look fuzzy only because the model has never seen the project. Those prompts should answer first and ask only if the guess fails.
- The model cannot tell those two cases apart without help from me.
- The help is one short paragraph at the top of the conversation.
That split is what the standing rule encodes.
The rule I paste at the top of long sessions
The instruction is plain English, three short lines, no hidden syntax. It tells the model to make a reasonable assumption and proceed when my ask is fuzzy, and to ask a clarifying question only when the answer really cannot be guessed from context. That is the whole idea. Paste the three lines once at the top of a long session, or once at the top of a project prompt, and the model reads it as a project header rather than a one-time comment. I also drop the same three lines at the bottom of the prompt if I want to be doubly sure the rule survives a long conversation.
Position matters more than the exact wording. I tried “just answer” at the bottom of long prompts and the model kept asking anyway. I tried “do not pause to clarify” in the middle of a request and it was ignored. The rule has to be set apart from the task, at the top of the prompt, with a blank line between it and the actual request. That is what gets the model to treat it as a header.
Plain English also matters. The model is good at reading intent, and a sentence like “do not ask questions” alone gets interpreted loosely. A specific phrasing that names the behavior I want is harder for the model to ignore, which is exactly the goal.
A worked example before and after the rule
To make the difference concrete, here is the same outline request, twice. First with no instruction, then with the standing rule pasted at the top.
Without the rule, I asked for an outline of a chapter. Claude came back with three questions. Which audience I was writing for. Which angle I wanted on the dependency story. Whether the chapter should land on a how-to or a why-it-matters ending. All reasonable questions. None of them what I needed at that moment, which was a draft I could react to and tighten.
With the rule pasted at the top, the same prompt came back as a six section outline, an explicit assumption that the audience was developers who already knew what a database was, and a flag at the end saying the dependency angle was the section I would probably want to rewrite. That was useful. That was what I was actually asking for.
Same prompt. Same model. The only thing that changed was which default the model was leaning on.
Where I drop the rule on purpose
There are tasks where I want the clarifying questions back. If I am kicking off a new project with a half-formed idea, three questions from the model save me from starting in the wrong direction. If I am asking for help with a decision I am genuinely stuck on, the questions are the point. If I am writing for a domain I do not know well, the model catching my blind spots is the value I am paying for.
For those prompts, I leave the rule off. I keep it on for tasks where a wrong first answer is cheap and I want to keep moving. I drop it entirely for any deliverable I cannot easily throw away, and I write a tighter prompt instead. The decision is per session, not per user, and it is fine to flip it.
I also keep a few words of variation in my back pocket. If the default is still firing after I paste the rule, I tighten the wording to name the kind of clarification I want to skip. A more specific instruction reads as sharper than the general “do not ask,” and the model will lean on the sharper version. It just needs a more concrete default than the one it ships with.
Trade-offs
The instruction costs nothing to add and almost nothing to remove. The real cost is that I now own the ambiguity in my prompts. If I write a vague ask with the instruction in place, the model will guess, and I have to be ready to rerun the prompt with a tighter version. For most of my day-to-day writing this is fine. For tasks where a wrong first draft is expensive, the instruction is the wrong default.
There is also a small consistency risk across sessions. The rule lives in the prompt, not in the model. A new session means pasting it again, or the model falls back to its default behavior. That is a feature if I want different defaults for different projects, and a small annoyance if I forget to paste it.
The third cost is judgment. The rule shifts the burden from the model back to me, and I have to be honest about whether the prompt was actually clear. A vague prompt with the rule in place is a vague prompt the model will guess at. If the guess is wrong, the fix is in the prompt, not in the model.
If you write drafts all day and the interview loop is costing you speed, this is a clear win. If most of your prompts are deliberately open-ended brainstorming where you want the model to surface options, leave the default alone and skip the instruction.
What I would tell past me
Start small. Pick one Claude session today and paste the three line rule at the top before your first real prompt. Watch whether the clarifying round fires or not. If it disappears, you have your answer for that session. If it still fires, tighten the wording to call out the specific kind of clarification you want to skip and try again.
Once the rule is working in your long sessions, build a small text snippet in whatever tool you live in. I keep mine in a plain text file I can paste from with a shortcut. Some people keep it in a custom slash command. The point is to make the rule cheap enough that you will actually paste it, not so polished that you forget to.
If your prompts are mostly open-ended brainstorming and you want the questions back, leave the rule off and skip the rest of this article. If your prompts are mostly drafts where you want a starting point, the rule is the closest thing to a free speed boost I have found for Claude work this year.