I run demand generation at Docket, and a large part of my actual GTM work now happens through Claude: drafting and editing copy, tearing apart positioning, summarizing call transcripts, cleaning lists, writing the small scripts that glue my stack together. After enough reps, you start to notice something uncomfortable about most prompting advice. It is superstition. People trade 'tricks' the way gamblers trade lucky socks, and almost none of it survives contact with a controlled before-and-after test.
Here is my actual position, and the whole point of this guide: a handful of things genuinely move the needle, and they are almost entirely about structure and context, not magic words. You do not need a secret phrase. You need to give Claude the real material, tell it precisely what you want, and show it the shape of a good answer. Everything else is noise that people mistake for signal because the model is forgiving enough to produce something decent anyway.
So this is a Claude-specific sorting exercise. I am going to separate the levers that change output quality from the rituals that do nothing, give you concrete before-and-after examples, and bust the myths that keep getting passed around. The goal is to get you to stop cargo-culting and start getting reliably better results. Verify fast-moving specifics on the official docs, but the core principles here have been stable for a long time and are not going anywhere.
What actually matters, in rough order of impact
If you only remember one thing, remember the order. The levers below are sorted by how much they change the output in practice. The top of this list is doing the heavy lifting on basically every good result I get; the bottom is fine-tuning. People obsess over the bottom and ignore the top, which is exactly backwards.
Notice what is not on this list: clever phrasing, persona stacking, or any specific incantation. The ranking is about what you feed the model and how you frame the job, because that is what the output is actually a function of.
- 01 / Give real context. Paste the actual document, transcript, spreadsheet, or code. Do not describe it. This is the biggest lever by a wide margin.
- 02 / State the goal, the audience, the constraints, and the exact output format. Ambiguity in equals slop out.
- 03 / Show an example or two of the output shape when format matters (few-shot). One good example is worth a paragraph of instructions.
- 04 / Structure the prompt with clear delimited sections or simple tags, so Claude can tell context from task from format.
- 05 / Put long reference material near the top and the actual instruction near the end.
- 06 / Iterate in follow-ups instead of trying to write one perfect prompt.
- 07 / When the task is ambiguous, ask Claude to ask you clarifying questions before it answers.
- 08 / For reasoning-heavy work, raise the effort setting and rely on adaptive thinking, rather than typing 'think harder'.
- 09 / Hold persistent role and context in a system prompt or a Project so you stop re-pasting it.
- 10 / For agentic work in Claude Code, describe the goal and constraints and let it plan, instead of dictating every step.
TipIf an output is disappointing, walk down this list before you touch the wording. Nine times out of ten the fix is higher up than 'rewrite the sentence', usually 'I did not actually give it the source material'.
Lever one: paste the real thing, do not describe it
This is the lever that separates people who get useful work out of Claude from people who get a confident-sounding average of the internet. When the task involves a specific artifact, your draft, a call transcript, a competitor page, a CSV, the worst thing you can do is summarize it in your prompt and ask Claude to work from your summary. You have just thrown away all the detail that mattered and asked the model to hallucinate the rest.
Claude's frontier models carry a very large context window (up to 1M tokens on the current top models, verify the exact number on the docs as it shifts). That window exists so you can paste the whole thing. Use it. I routinely drop entire documents, full transcripts, and long threads straight into the prompt rather than paraphrasing them, and the quality difference is not subtle.
Here is the contrast. Weak prompt: 'Write a follow-up email to a prospect who seemed interested in our analytics product but had some pricing concerns.' That produces a generic email because you gave it a generic situation. Strong prompt: paste the actual call transcript or the actual thread, then say 'Write the follow-up email. The pricing concern was specifically about per-seat cost scaling on their 40-person team; address that directly, keep it under 120 words, and match the casual tone they used.' The second one writes itself off the real facts. The first one invents a prospect that does not exist.
TipA good gut check before you hit enter: 'Does this prompt contain the actual information needed to do the job, or am I asking Claude to guess at facts only I have?' If it is guessing, paste more.
Lever two: state the goal, the audience, the constraints, and the format
The most common reason people complain that Claude's answers are generic is that they asked a generic question. 'Make this better' has no target. Better for whom, toward what end, in what shape, under what limits? You know all of that in your head. Claude does not, and it will not read your mind; it will produce the safe, median version that is technically responsive and useless to you.
Four things, every time the output shape matters. Goal: what is this for. Audience: who reads it and what they already know. Constraints: length, tone, what to avoid, must-haves. Format: the exact structure you want back. You do not need to write an essay. A few clauses is enough.
Compare. Weak: 'Summarize this report.' Strong: 'Summarize this report for our VP of Sales who has not read it. Goal: she needs to decide whether to greenlight the pilot. Five bullets max, lead with the recommendation, flag the one number she should be skeptical of, no jargon.' Same model, same report. The second prompt produces something you can forward without editing, because you specified the job instead of gesturing at it.
The format clause does more work than people expect. 'Give me a table with columns X, Y, Z', 'reply with only the rewritten paragraph and nothing else', 'output valid JSON matching this shape', these constrain the answer in ways that save you the back-and-forth of reshaping a wall of prose.
When the format is specific or unusual, stop describing it and show it. This is few-shot prompting, and you do not need many shots: one or two examples of the exact output shape pin Claude to a pattern far more reliably than a paragraph trying to describe that pattern in words. If I want a set of LinkedIn hooks in a particular rhythm, I paste two hooks I already like and say 'more like these, same length and cadence, for this topic.' For extracted data, I show one filled-in example row. The same trick quietly solves tone: instead of arguing about what 'punchy but not salesy' means, paste two paragraphs in the voice you want and say 'write in this voice.' Examples are unambiguous in a way adjectives never are.
TipExamples beat adjectives. Every time you find yourself piling up descriptors ('crisp, confident, a little contrarian, not corporate'), stop and paste a sample of the thing instead.
Lever three: structure the prompt, and put the instruction last
Once a prompt has several moving parts, source material, instructions, an example, constraints, it helps to label them so Claude can tell which part is which. Claude follows clearly delimited sections well. You can use plain headers (a Context section, a Task section, a Format section) or simple XML-style tags like
The companion rule is ordering: when you paste a lot of reference material, put it near the top and put the actual ask near the end. The model reads the whole thing, but ending on a clear instruction leaves it pointed at the task rather than trailing off into the material. The skeleton of a heavy prompt looks like: here is the source material (long), here are the constraints, and now, finally, here is exactly what to do with it. I have watched ambiguous results clean up just by moving the instruction from the middle of a giant paste to the very bottom.
This is also why prompt caching on the API rewards the same layout. Stable, reusable context first so it can be cached and replayed cheaply; the per-request instruction last where it changes. You do not have to think about caching to benefit, but it is a nice tell that the structure is sound: what makes a prompt readable to a human is the same thing that makes it efficient for the machine. A repeatable prompt with a CONTEXT block, a TASK block, and a FORMAT block is easy to maintain, easy to tweak, and easy to hand to a teammate.
Lever four: iterate in follow-ups, do not chase the perfect prompt
The single biggest time-sink I see is people trying to engineer one flawless mega-prompt that produces a perfect answer on the first try. It is a trap. You will spend twenty minutes crafting it and the output will still be 80% right, because you cannot anticipate everything you want until you see a draft.
Treat it as a conversation, which is what it is. Get a fast first pass, then steer: 'make it shorter.' 'More skeptical.' 'Cut the intro, it is throat-clearing.' 'Lead with the second point.' 'Drop the third bullet and expand the first.' Each follow-up is cheap, specific, and lands because the model already has all the context from the first turn. I get to a finished piece far faster this way than I ever did trying to front-load every instruction.
There is a real skill here, and it is editorial, not technical: knowing what is wrong with a draft and saying so plainly. 'This is too generic' is a weak note. 'Cut the adjectives, name the specific objection, and end on the ask' is a strong one. The better you are at editing, the better Claude looks, because you are giving it precise corrections instead of vague dissatisfaction.
TipIf your second prompt is 'no, do it better', that is on you, not the model. Tell it what specifically to change. Vague feedback gets vague revisions.
Three smaller levers that are still real: clarifying questions, effort, and Projects
These are lower-impact than the ones above, but they are genuine controls, not folklore, so they belong on the list. First, when the task is genuinely underspecified and you know it (you want a strategy memo but have not decided the scope, a rewrite but not the angle), do not force a first draft and then fight it. Add one line: 'Before you answer, ask me any clarifying questions you need.' Instead of the model guessing at your intent and you correcting five wrong guesses, it surfaces the real decision points up front, and half the time its questions reveal things I had not thought through. Skip it for mechanical tasks with an obvious output; the questions would just be friction.
Second, for reasoning-heavy work, raise the effort setting rather than typing 'think harder'. Telling a model to 'think step by step' or 'take a deep breath' was a real coaxing technique on older, weaker models; on current Claude models it is mostly a placebo people reach for instead of the actual control. Effort is a genuine knob (low, medium, high, xhigh, max on the current models, Opus 4.6 and up and Sonnet 4.6): higher effort means the model reasons more before answering. Adaptive thinking lets it decide how much to reason on its own, scaling up for the hard parts. In Claude Code, xhigh is the sweet spot for coding and agentic work and high is a sensible minimum for anything intelligence-sensitive. Verify the exact levels and model support on the docs, since this surface moves. The point: use the control, not the incantation.
Third, stop re-pasting context. If you open every chat with the same three paragraphs (who you are, what your product does, your voice and constraints), that persistent context belongs in a system prompt or a Claude Project, set once and applied to every conversation inside it. I keep a Project for Docket work with the company context, our positioning, the no-go words, and the tone, loaded in once, so every chat starts already knowing all of it and I only type the actual task. This is the same idea as a good CLAUDE.md in a codebase: treat reusable context as configuration, not as something you retype. It is the difference between re-briefing a new contractor on every task and having a teammate who already knows the account.
Prompting agents and Claude Code is a different game
Everything above assumes a chat box where you want a specific output back. Agentic work, Claude Code and similar, flips the relationship: you are not asking for a paragraph, you are handing off a goal and letting the model plan, use tools, and execute across many steps. The prompting instinct that works in chat actively hurts you here.
In chat you specify the output. With an agent you specify the outcome and the constraints, then get out of the way. 'Refactor this module to remove the duplicated validation logic, keep the public API unchanged, and run the tests after' beats a numbered list of fifteen micro-steps. If you dictate every step, you have not delegated, you have just typed slowly, and you lose the model's ability to adapt when step three turns out to be wrong.
Two things matter most for agents. First, a good CLAUDE.md (or equivalent project context) beats a long chat prompt, because it gives the agent the standing rules, conventions, and constraints it needs on every task instead of you re-explaining them. Second, give the full goal up front in one well-specified ask. Current models are strongly autonomous and reward a clear target with a clean run; ambiguous goals dribbled out over many turns make them flail. State what 'done' looks like, set the guardrails, and let it work.
TipThe tell that you are over-specifying an agent: your prompt reads like a script the model has to follow exactly. The tell that you are under-specifying: you cannot say what 'done' looks like. Aim for a clear outcome plus hard constraints, and leave the path to the model.
What does not work, and why people think it does
Now the part nobody wants to hear. A large chunk of popular prompting advice is theater. It persists because the model is good enough to produce a decent answer regardless, so people credit whatever ritual they happened to perform. Correlation, not causation. Here is what I have stopped doing, and what you can drop too.
Flattery: 'You are the world's best copywriter.' This does nothing useful. The model is not holding back its good work pending a compliment. It already writes at its capability; telling it that it is a genius does not unlock a hidden tier. At most it nudges tone in ways a single clear instruction would do better and more precisely.
Threats and fake urgency: 'This is extremely important, my job depends on it', 'you must get this right or else.' No. The model does not have a job to lose and is not motivated by your stakes. These just add tokens and noise. Worse, they can make people feel they have done something rigorous when they have skipped the one thing that mattered, giving it the actual context.
Offering a tip, ALL-CAPS shouting, 'take a deep breath', and repeating the same instruction five times in slightly different words: all variations of the same superstition, that intensity or insistence changes output quality. It does not. Repeating yourself can even hurt, because now the model is parsing five overlapping instructions and you have buried the signal. Say it once, clearly.
Padding with politeness: 'please', 'thank you', 'if you would be so kind.' Harmless, and being civil is fine if it is your habit, I do it out of reflex. Just be clear that it is for you, not for the output. Courtesy is not a performance lever. And the big one: pasting a giant prompt template you found online and do not understand. A 600-word template full of role-play scaffolding and rules you cannot explain is mostly dead weight. It dilutes your actual ask, you cannot debug it when it misfires, and it makes you feel like a prompt engineer while doing less than three clear sentences would.
- Flattery ('you are a world-class expert') changes nothing the model was not already doing.
- Threats and fake stakes ('my job depends on this') are noise; the model has no stakes.
- Bribes ('I will tip you $200'), ALL-CAPS, and 'take a deep breath' are rituals, not controls.
- Repeating an instruction five times buries the signal instead of strengthening it.
- Politeness is fine for you but does nothing for output quality.
- Pasting a long template you do not understand dilutes your ask and is impossible to debug.
TipA useful filter: if a 'trick' is a phrase you add rather than information you provide or a control you set, be suspicious. Real levers change what the model has to work with. Rituals just change how you feel about the prompt.
Prompting cannot fix the wrong model or the wrong surface
One last thing, because no amount of prompt craft saves you here. Prompting operates on top of two choices you make before you type a word: which model, and which surface. Get those wrong and the best prompt in the world underperforms.
On model: default to Sonnet 4.6 for most work. It is the best balance of speed and intelligence, and it handles the large majority of GTM tasks, drafting, editing, summarizing, extraction, without making you wait. When the task is genuinely hard, deep analysis, gnarly reasoning, long agentic runs, step up to Opus 4.8, the current top usable model. Reaching for the heaviest model on every trivial task just costs you latency; using a light model on a hard task gives you a worse answer no prompt can rescue. (You may see Fable 5 referenced elsewhere as briefly the most capable model; it has been withdrawn from availability, so treat Opus 4.8 as the top model you can actually use today, and verify on the docs.)
On surface: a one-off question belongs in chat. Recurring context belongs in a Project. Multi-step work that touches files and tools belongs in Claude Code with a good CLAUDE.md. Matching the surface to the job does more for your results than any phrasing tweak, because the surface determines what context and tools are even available to the prompt. Pick the model and the surface deliberately, then apply the ten levers. That order, model and surface first, then real context and clear structure, then iteration, is the whole game. The magic words were never the point.
Frequently asked questions
How do I write a good Claude prompt?
Give it the real material instead of describing it (paste the document, transcript, or data), then state the goal, the audience, the constraints, and the exact output format you want. If the shape is specific, show one or two examples. Structure longer prompts into labeled sections with the reference material near the top and the instruction at the end. Then iterate with short follow-ups rather than trying to get it perfect on the first try.
Does being polite to Claude help the output?
No. Politeness does not change output quality. Saying 'please' and 'thank you' is harmless and fine if it is your habit, but it is for you, not for the model. The model is not withholding better work pending courtesy. Spend that effort on giving it more context and a clearer instruction instead.
Should I tell Claude to think step by step or to think harder?
Mostly no, on current models. 'Think step by step' and 'think harder' were coaxing techniques for older, weaker models. On current Claude models the real lever is the effort setting (low, medium, high, xhigh, max) combined with adaptive thinking, which lets the model decide how much to reason on its own. Raise the effort level for hard reasoning tasks instead of typing motivational phrases.
What is the best prompt structure for Claude?
For anything with multiple parts, label them: a Context section with the source material, a Task section with the instruction, and a Format section with the output shape. You can use plain headers or simple XML-style tags like
Why are my Claude answers so generic?
Almost always because the prompt was generic. If you describe a situation in vague terms ('write a follow-up to an interested prospect'), you get a vague, average answer. Fix it by pasting the actual material (the real transcript, the real thread) and specifying the goal, audience, constraints, and format. Generic in produces generic out; the model is rarely the problem.
Do tricks like offering a tip or threatening Claude improve results?
No. Offering a tip, claiming your job depends on it, ALL-CAPS, and 'take a deep breath' are rituals, not controls. They do not change output quality; they just add tokens and can make you feel productive while you skip the thing that actually matters, giving the model real context and a clear ask. If a 'trick' is a phrase you add rather than information you provide, be suspicious of it.
How much context can I paste into Claude?
A lot. The current frontier Claude models carry a very large context window (up to 1M tokens on the top models, verify the exact figure on the official docs since it shifts). That window exists so you can paste whole documents, full transcripts, and long threads rather than summarizing them. Pasting the real source material instead of describing it is the single biggest lever on output quality.
Should I write one perfect prompt or iterate?
Iterate. Trying to engineer one flawless mega-prompt is a time-sink and rarely beats a fast first pass followed by specific follow-ups like 'make it shorter', 'more skeptical', or 'cut the intro'. The model keeps the context from the first turn, so corrections are cheap. The skill is editorial: tell it precisely what to change rather than just 'do it better'.
Sources & further reading
Claude ships fast. This page was last reviewed Jun 16, 2026; verify time-sensitive details against the official docs above before relying on them.