Plain-English Explainer
How to Prompt Claude So You Get the Answer You Actually Wanted
The gap between a mediocre answer and a great one is usually three sentences of missing context.
Most bad Claude answers aren't a model problem, they're a prompt problem. This guide covers the small number of patterns that consistently improve results: what context to include, how to show Claude what you mean instead of describing it, how to ask for a specific output format, and what to do when the first answer misses.
Prompting Claude well means giving it three things most people skip: the situation (who this is for, what it's used for), an example of the output you want if the format matters, and a clear statement of what "good" looks like. Claude does not know your context unless you write it down. A one-line question gets a generic answer; a prompt with role, audience, constraints, and an example gets a specific, usable one. When an answer misses, don't restart the conversation, tell Claude exactly what was wrong and let it revise in place.
Published
Key Takeaways
- Claude has no memory of your situation unless the prompt states it. Vague questions get generic answers because there's nothing else to work from.
- Showing one example of the output format you want (a sample email, a sample table row) works better than describing the format in words.
- Long, unstructured prompts get muddled results. Breaking context, task, and constraints into separate labeled chunks or simple headers helps Claude weight each part correctly.
- Asking Claude to think through a problem step by step before answering improves accuracy on anything with multiple steps or trade-offs, not just math.
- When an answer misses, correcting it in the same conversation is almost always faster and more accurate than writing a longer prompt from scratch.
- Claude follows format instructions literally. If you want three bullet points and one paragraph, say that instead of just asking to be 'concise.'
Vague Prompt vs. Specific Prompt
| Situation | Vague Prompt | Specific Prompt |
|---|---|---|
| Writing an email | "Write a follow-up email" | "Write a follow-up email to a client who went quiet after a proposal, keep it short, no guilt-tripping, end with a low-pressure next step" |
| Summarizing a document | "Summarize this" | "Summarize this in five bullets for someone who wasn't in the meeting, focus on decisions made and who owns what" |
| Reviewing code | "Check this code" | "Review this for anything that would break under concurrent requests, I don't need style feedback, only correctness issues" |
| Making a decision | "Should I do X or Y?" | "Walk through cost, speed, and risk for X vs Y given a two-person team and a six-week deadline, then recommend one" |
Copy and Paste
Prompts You Can Use Today
Give Claude the missing context before asking the actual question
I run a two-person marketing team at a B2B software company that sells to IT directors. I need to write a launch email for a new integration feature. Our audience has seen a lot of feature-announcement emails and tends to skim, so the email needs to lead with the outcome, not the feature name. Draft a 150-word email with a subject line, and explain briefly why you structured it that way.
Swap the role, audience, and product detail for your own situation.
Show an example instead of describing the style
Here is a sample of how I write customer support replies: 'Hi Alex, totally get the frustration here, sorry about that. Here's what's happening: [cause]. Here's the fix: [steps]. Let me know if it doesn't resolve, happy to dig further.' Using that same tone and structure, write a reply to a customer whose export feature is timing out on files over 500 rows.
Paste one real example of your own writing or past output before the request.
Ask for a specific format up front
Compare three project management tools, Asana, Linear, and Notion, for a 12-person engineering team currently using spreadsheets. Return the answer as a markdown table with columns for tool name, best for, biggest limitation, and rough learning curve. Keep each cell to one sentence.
Name the exact structure: table, columns, length per cell, not just 'organized.'
Force step-by-step reasoning before the final answer on anything with trade-offs
I'm deciding between hiring a full-time content writer or using two freelance contractors for the next two quarters. Walk through the trade-offs in terms of cost predictability, ramp-up time, and quality consistency before giving me a recommendation. Show your reasoning for each factor separately, then state your final recommendation in one sentence at the end.
Useful for any decision with more than one factor, not just technical or math problems.
Fix an answer that missed, without restarting the conversation
This is close but too formal for the audience, they're internal engineers, not external customers. Also cut the second paragraph entirely, it repeats the first. Rewrite just the email body with those two changes, keep everything else the same.
Name exactly what was wrong and what to keep, rather than re-explaining the whole task.
Constrain scope so Claude doesn't over-deliver or under-deliver
Summarize this meeting transcript in exactly five bullet points: what was decided, what's still open, and who owns each open item. Do not include a general overview paragraph, do not include anything that wasn't explicitly discussed, and flag anything ambiguous with a question mark instead of guessing.
Paste the transcript or document text above this prompt.
Give Claude a role to calibrate depth and vocabulary
Act as a skeptical technical reviewer, not a cheerleader. Review this API design description and point out anything that would cause problems at scale, anything ambiguous about error handling, and anything you'd push back on in a design review. Be direct, don't soften the criticism, and don't compliment anything unless it's genuinely well designed.
Roles work best when paired with a specific stance, like 'skeptical reviewer,' not just 'expert.'
The Core Patterns
Four habits that improve almost every prompt
These aren't tricks specific to one task type. They apply whether you're writing an email, debugging code, or working through a decision.
State the context Claude can't see
Who is this for, what has already been tried, what constraints exist. Claude only knows what's in the conversation, not your inbox, your team, or your history with this problem.
Show, don't just describe
One example of the tone, format, or style you want is worth several sentences of description. Paste a sample if you have one.
Separate the parts of the prompt
Background, the actual task, and any constraints get followed more precisely when they're visually distinct, even just with line breaks or short headers, instead of one dense paragraph.
Name the output shape
Bullet points, a table, a specific word count, a particular section order. Claude follows explicit format instructions closely. Vague requests like 'be concise' get inconsistent results.
Why Context Does the Heavy Lifting
The most common prompting mistake is assuming shared context
A one-line question like "write me a marketing email" is answerable in thousands of ways, and Claude has to guess at all of them: what product, what audience, what tone, how long, what's already been tried. Every guess is a chance to miss what you actually wanted, and the more guesses required, the more generic the output tends to be, because Claude is optimizing for something broadly reasonable rather than something specific to your situation.
The fix isn't a longer prompt for its own sake, it's a more complete one. Naming the audience, the constraint that matters most, and what "done" looks like usually takes two or three extra sentences and removes most of the guesswork. This matters more than clever phrasing or special commands. A plain, specific prompt beats a terse, clever one almost every time.
This becomes more important, not less, in longer working sessions. If you're several messages into a conversation about a project, Claude has the context from earlier in that thread. But if you open a new conversation to ask a follow-up question, that context is gone unless you restate it or you're working inside a Claude.ai Project, where files and instructions you've added stay available across chats in that project.
Examples Over Descriptions
Why showing an example works better than explaining a style
Style, tone, and format are hard to describe precisely in words but easy to demonstrate. "Write in a friendly but professional tone" is open to interpretation. Pasting one paragraph of writing that already has the tone you want, and asking Claude to match it, removes the interpretation gap almost entirely.
This works for more than writing style. If you want data extracted into a specific structure, show one filled-in row of that structure and ask Claude to continue the pattern. If you want code that follows a particular convention, paste a short snippet of existing code in that style. Claude is good at pattern-matching from a concrete example, and a single well-chosen example often outperforms several sentences of abstract instruction.
One example is often enough. Two or three examples help more when the task has real variation, like several different customer scenarios that should be handled differently. Beyond that, more examples usually add length without adding much accuracy.
Structuring Longer Prompts
When your prompt has multiple parts, label them
Short questions don't need structure. Prompts that include background material, a task, and constraints benefit from making each part visually distinct.
Background first
Put reference material, a document to work from, or situational context at the top, clearly separated from the actual instruction that follows it.
The task, stated plainly
One or two sentences saying exactly what you want done. Put this after the background, not buried inside it.
Constraints last
Length limits, things to avoid, tone requirements. Stating these explicitly, rather than assuming Claude will infer them, prevents the most common misses.
Headers or line breaks, not paragraphs
You don't need special syntax. Simple labels like 'Context:' and 'Task:' on their own lines are enough to keep a long prompt organized and easy for Claude to parse correctly.
Reasoning Through Harder Problems
Ask Claude to think before it answers
For anything with more than one factor, a decision with trade-offs, a plan with dependencies, a piece of analysis, asking Claude to reason through the problem before giving a final answer tends to produce a better final answer. This isn't unique to math or logic puzzles. A prompt like "walk through the trade-offs before recommending one option" gives Claude room to weigh factors explicitly instead of jumping straight to a conclusion that skips steps.
This is especially useful when you disagree with an answer and aren't sure why. Asking Claude to show its reasoning, rather than just restating the question, often reveals the specific assumption that led to the wrong conclusion, which is much easier to correct than the conclusion itself.
You don't need special phrasing to trigger this. Plain instructions like "think through this step by step" or "consider the downsides of each option before deciding" work. The key is asking for the reasoning explicitly rather than assuming it happens automatically.
Fixing a Missed Answer
The answer missed. Now what?
The instinct when an answer isn't right is often to rewrite the whole prompt from scratch, longer and more detailed this time. That's usually the slower path. Claude has the full conversation in front of it, so the faster fix is telling it precisely what was wrong with what it just produced and what to keep.
Vague feedback like "make it better" or "try again" gives Claude almost nothing to work with, and it will often just change things at random. Specific feedback, "this is too long, cut the second paragraph," "the tone is too formal, this is for a coworker not a customer," "you missed that the deadline is fixed, that's not negotiable", gives it something concrete to correct.
It also helps to say what to leave alone. If most of the answer was right and only one section was off, say so, otherwise Claude may rewrite parts that were already fine along with the part that wasn't. This back-and-forth correction is a normal, expected part of using Claude well, not a sign the first prompt failed.
Where Prompting Meets the Product
Prompting habits change slightly depending on where you're working
In Claude.ai, a Project lets you attach reference documents, style guides, or standing instructions that apply to every conversation inside that project, which removes the need to re-explain context in each new chat. This is worth setting up for any recurring task, a weekly report, a specific type of customer response, rather than re-pasting the same background every time.
When Claude is asked to produce something substantial, a document, a piece of code, a long piece of writing, it can generate that content in Artifacts, a separate editable pane alongside the conversation. Prompting for artifact-worthy output benefits from the same format specificity as any other prompt: say what the finished thing should look like, not just what topic it should cover.
For developers working in Claude Code or through the API directly, the same core habits apply, context, examples, explicit format, but system prompts and structured tags become tools for enforcing those habits consistently across many requests rather than restating them by hand each time.
Reading about prompting and being good at it are different things
These patterns are simple to describe and take real practice to apply without thinking about them. The free Nightschool AI curriculum is hands-on from the first lesson, you write real prompts, see how Claude responds differently, and build the instinct for what to include before you ask.
Frequently Asked Questions
What is the single most important thing to include in a Claude prompt?
Context that Claude can't otherwise know: who the output is for, what constraints matter, and what you've already tried. A short prompt with the right context usually beats a long prompt without it. Most weak answers come from missing context, not from Claude's limitations.
Should I use special formatting like XML tags in my prompts?
For everyday use in Claude.ai, plain labeled sections (like 'Context:' and 'Task:' on separate lines) work well and are easier to write. Structured tags become more useful for developers building repeatable prompts through the API, where consistent structure across many requests matters more than it does for a one-off chat.
How long should a good prompt be?
As long as it needs to be to convey the context, and no longer. A simple factual question needs one sentence. A request involving audience, tone, format, and constraints needs several. Padding a prompt with unnecessary detail doesn't help, but omitting relevant context does hurt, so err toward including anything that would change the right answer.
What should I do if Claude's answer is close but not quite right?
Correct it in the same conversation rather than starting over. State specifically what was wrong (too long, wrong tone, missed a requirement) and what to keep unchanged. Claude has the full context of what it already produced, so targeted feedback is faster and more accurate than a fresh, more detailed prompt from scratch.
Does giving Claude a role or persona actually help?
It helps when paired with a specific stance, not just a job title. "Act as a skeptical editor who cuts anything vague" changes the output more than "act as an editor" alone. The role works by narrowing what counts as a good answer, so make the narrowing specific.
How do I get Claude to stop giving overly long answers?
State the length or format explicitly rather than asking it to be 'concise,' which is subjective. "Answer in three bullet points" or "one paragraph, under 100 words" gives Claude a concrete target to follow instead of an impression to interpret.
Is it better to ask one big question or break it into smaller steps?
For tasks with a clear sequence (research, then draft, then revise), breaking it into steps across a conversation usually produces better results than one large request, because you can check and correct each stage before building on it. For a single well-defined task, one clear, complete prompt is fine.
Why does Claude sometimes ignore part of my prompt?
This usually happens when a prompt is long and unstructured, with the important constraint buried in the middle of a dense paragraph. Separating background, task, and constraints into distinct, clearly labeled parts makes it much less likely that a specific instruction gets lost.
Do examples work better than instructions for getting a specific format?
Often, yes. Describing a format in words leaves room for interpretation. Pasting one example of the format you want and asking Claude to follow that pattern removes most of the ambiguity, especially for things like tone, structure, or a specific data layout.
What's the difference between prompting Claude in a chat versus through a Project?
A chat only has the context of that conversation. A Claude.ai Project lets you attach standing documents, style guides, or instructions that carry across every conversation inside it, which is useful for recurring tasks where you'd otherwise restate the same context each time.
Better prompts start with practice, not theory
The fastest way to internalize this is to try it on something you actually need done.