The single most common reason new users get poor answers from Claude is that they ask in a way that gives Claude no chance of answering well. The model is capable, but it is not psychic. If you supply two sentences of context for a task that needs five, you get a generic response. If you ask "is this good?" without saying what "good" means in your situation, you get a hedged answer that helps no one.
This guide covers the four things that turn a vague request into a useful one: context, examples, constraints, and output format. Apply them and your hit rate goes up immediately.
1. Context: who is asking, why, and for whom
Claude has no memory of who you are or what you do unless you tell it (or it has stored it in Memory or CLAUDE.md). Every conversation in the web app starts blank. Every Claude Code session loads only what is in your CLAUDE.md and auto memory. Anything else has to come from the message you send.
Compare these two prompts for the same task:
Weak:
Write a follow-up email to a client.
Strong:
I run a small accountancy practice in Dublin. I had a discovery call with a prospective client last Wednesday — a builder with two staff, looking to switch from his current accountant. He has not replied to my proposal email sent on Friday. Write a short follow-up email that is friendly, low-pressure, gives him an easy out if he has decided to stay where he is, and asks if he wants a brief call to clarify anything.
The strong version is not longer for the sake of length. Every detail changes the output: Dublin sets the register, builder with two staff sets the technical level, has not replied + low-pressure sets the tone, easy out tells Claude what to not do.
2. Examples: show, don't just tell
If the output needs to match a particular style, voice, or format, give Claude an example of what right looks like. Two or three examples are dramatically more effective than describing the style in adjectives.
Less effective: "Write in a punchy, direct, no-fluff style."
More effective: "Write in this style: [paste a paragraph of writing you like]. Keep the same sentence rhythm and directness."
This applies to almost any structured output — emails, reports, summaries, social posts, even code. If you have a few past examples that you consider good, paste one or two. Claude pattern-matches to them more reliably than to descriptions.
3. Constraints: tell Claude what NOT to do
Constraints are often more useful than positive instructions. They prevent the most common failure modes.
- Do not use bullet points. (When you want flowing prose.)
- Do not start with "I'd be happy to..." or any acknowledgement. (When you want straight answers.)
- Do not mention pricing. (When pricing is handled separately.)
- Do not invent statistics — if you cite a number, tell me where it came from. (When you need verifiable claims.)
- Do not use em-dashes; they are a tell that AI wrote it. (When you want to obscure that an AI was involved.)
Claude follows negative constraints reliably when they are clear. Vague positive instructions ("be concise") are interpreted differently every time; specific negative instructions ("max 150 words, no preamble") leave less room for drift.
4. Output format: say what you want at the end
If you want a specific format, ask for it explicitly. Claude defaults to whatever it judges most appropriate — which is usually paragraphs of medium length with some bolding. If you want something different, say so.
- "Return as a numbered list."
- "Return as a markdown table with three columns: name, deadline, status."
- "Return only the rewritten paragraph — no commentary, no explanation of changes."
- "Reply in two parts: a one-sentence verdict, then up to five supporting points."
Specifying format is often the difference between a response you can use as-is and one you have to clean up before using.
The four-part recipe
Template
Context: [who you are, what the situation is, what just happened]
Task: [what you want Claude to produce]
Constraints: [what to avoid, length limits, things to leave out]
Format: [structure of the output you want back]
You will not always need all four — a quick factual question rarely does. But for any task where you have ever felt the response was generic, vague, or off-key, the answer is almost always that one of the four was missing.
When to push back vs. start over
If Claude's first response is close but not right, the right move is usually to refine in the same conversation. Tell Claude what is off and what to do differently. The conversation context carries the original instructions forward; you are layering corrections on top.
If the response is fundamentally wrong — wrong genre, wrong audience, wrong purpose — start a new conversation with a better-framed prompt. Trying to redirect a far-off response wastes more time than restarting. The rule of thumb: if you are typing your second correction in a row and it is still not right, restart with a sharper opening prompt.
What changes for Claude Code
Everything above applies to Claude Code too, but with one addition: Claude Code can find context for itself. Instead of explaining your file structure in the prompt, you can say "look at how this is organised and then tell me X." For tasks that involve files Claude can read, let Claude read first and ask second — the response will be more grounded than anything you could brief from memory.
The flip side: if your CLAUDE.md and rules are well-written, you can use shorter prompts in Claude Code than in Desktop, because the persistent instructions cover the context that you would otherwise have to repeat each time. Investment in CLAUDE.md pays back every prompt thereafter.