How to prompt Claude
Lightbridge Labs defines prompting Claude as the practice of writing instructions that produce consistent, high-quality results from the model. Strong prompts answer five questions: who the model is, what you want, what context it needs, what good looks like, and what to avoid. This guide is the free primer to prompt engineering.
Every strong Claude prompt answers five questions.
Lightbridge Labs teaches prompting through a five-part mental model. You do not need all five for a simple request. For anything complex or repeated, a missing layer degrades quality in predictable ways, and the model fills the gap with a plausible guess. The five questions are the fastest way to diagnose a disappointing answer: find the layer you left out.
Who are you?
Sets the role and domain expertise the model should write from. A persona shifts the whole forward pass toward expert-consistent language, vocabulary, and reasoning moves.
What do you want?
The actual task, stated as one verb and one outcome. Bury it under preamble and the model anchors on the wrong framing.
What context is needed?
Background, constraints, and prior decisions the model cannot infer from the task alone. Prior decisions you omit get re-suggested.
What does good look like?
A format specification, success criteria, or a single worked example. One concrete example removes more ambiguity than a paragraph of description.
What should be avoided?
Tone, content, and scope that are out of bounds. Constraints on exclusions are often more powerful than constraints on inclusions.
A well-structured Claude prompt has four layers: role, context, task, constraints.
None of the layers is mandatory, but the more complex the task, the more of them you need. The role tells the model who it is for this task. The context supplies what it cannot infer on its own. The task is the single clear instruction. The constraints govern format, length, tone, and what to leave out. A request like "summarize this email in two sentences" already carries all four implicitly, which is why it works without ceremony.
Most weak prompts fail on structure, not effort. Three patterns recur. Burying the task five sentences into a paragraph lets the model anchor on the wrong framing before it ever reaches the request. Compound prompts ("review this, fix the bugs, add tests, and suggest a new design") get five things done poorly instead of one done well, so split them into separate messages. Leaving the format unstated invites three paragraphs of prose when you wanted a table. State the structure you want and you remove the guess.
Context, tone, and format are how you control a Claude response.
Context covers the facts the model has no way to deduce from the task alone: the relevant domain and its version, the audience for the output, the options you have already ruled out, and what you have already tried. The discipline is to include what changes the answer and exclude what does not. A sentence of company background rarely changes a code review, and noise in the context produces noise in the response.
Tone is matched to context unless you say otherwise, so name it when it matters: professional and concise for a client update, brief and direct for an internal note, balanced and analytical when you do not want the model to advocate a position. The model also tends to open with an affirmation and close with a summary, and you can suppress both by asking it to begin with the first line of the actual answer.
Of every change you can make, naming the output format gives back the most for the least effort, and most prompts skip it. When you need JSON, give the exact schema rather than the word "JSON," or the model invents field names. When you need a comparison, ask for a table with named columns. When you want brevity, give a sentence or word count, because "brief" means different things to different readers. The teams who get reliable output from Claude are almost always the ones who specify the shape of the answer.
Reducing ambiguity is the core skill of prompting Claude well.
Every ambiguous prompt opens a gap between the answer you pictured and the one the model produces. Six techniques close that gap. Read your own prompt as if you knew nothing about your domain: every place you would need more information to follow the instruction is a place the model needs it too. Then build the prompt iteratively. Start minimal, run it once, add one constraint at a time to fix the specific thing that went wrong, and stop when the output is consistently right. A fast feedback loop beats trying to write the perfect prompt in one pass.
Define your terms
Any word that could mean two things in your domain should be pinned down. A verb like "update" can mean overwrite, merge, or patch, and the model will pick one. Name the one you mean.
Specify what you do not want
Telling the model what to exclude is often sharper than listing inclusions. "Do not add a summary at the end" removes a whole category of unwanted output in one line.
Anchor with one example
Show the exact output shape you expect. A single representative example invokes the pattern-matching circuitry that copies and continues your format far more reliably than an abstract description.
Name the edge cases
State what should happen when a field is missing, when there are no results, or when the model is unsure. "If a value is absent, return null, do not skip it" forecloses a guess.
Ask for a plan first
For multi-step work, ask for a short outline before any output. Reviewing a five-bullet plan catches a misunderstanding at the cheapest possible moment, before the model commits effort to the wrong approach.
Test on a small input
Verify the output shape against a short excerpt before running a prompt across a large document. Confirm the form is right, then scale the input.
Ready-to-use Claude prompt templates put the mental model to work.
Templates work because the structure around the blanks is what does the job. Copy one, replace the bracketed content, and keep the scaffolding. For a document summary, ask for one short paragraph of the main point followed by three to five bullet takeaways, and name the audience. For a decision, state the two options and the use case, give two facts about your situation, and ask for a recommendation with three bullets of rationale and an instruction not to hedge.
Extract fields from a document
Extract the following fields from the text below. Return them as a table with two columns, Field and Value. Fields to extract: - [field one] - [field two] If a field is not present, write "not found". Do not guess. Text: [paste document here]
Improve a piece of writing
Improve the following text. Keep the meaning and all key facts exactly the same. Goals: [clearer / more concise / more professional / simpler for a non-technical reader] Return the improved version only. Do not explain what you changed. Text: [paste text here]
These cover common business work: summarizing, comparing options, drafting communication, extracting information, reviewing documents, and preparing data. When an answer comes back ninety percent right, add one correction in the next message rather than rewriting the prompt from scratch.
Identical prompts can give Claude different answers, and that is expected.
Practitioners arriving from traditional software, where a function returns the same value every time, find this disorienting and assume something is broken. Nothing is broken. At each step the model produces a probability distribution over its vocabulary and a decoding strategy samples from it. Any temperature above zero introduces deliberate randomness, which is what lets the model write creative, non-repetitive prose. For factual or extraction work, set temperature near zero. For exploratory work, leave it near the default.
Even at temperature zero you may see variation, and the reason is the hardware. Floating-point addition on a GPU is not associative, so the order in which thousands of parallel threads combine partial sums can shift the last bits of a calculation. Most of the time that changes nothing. When two candidate tokens are nearly tied, it can flip which one ranks first, and the output diverges from there. A busy inference server batches your request with different neighbors each call, which selects different computation paths. That is the honest answer to why a fixed model can still vary between requests.
The practical response is to design for it. Build retries and idempotency into automated loops so a retry converges to the same end state, not the same intermediate path. Pin a model snapshot (for example a dated identifier like claude-haiku-4-5-20251001 rather than a floating alias) when you need consistency within a version. Run evaluation prompts several times and report the distribution, because a single sample is not a measurement. For any irreversible step, a financial posting or a system-of-record event, keep the model in the preparation and let a human commit the action.
The science of prompting explains why structure, personas, and examples change Claude behavior.
Recipes work, but knowing the mechanism is what lets you tell when a technique will help, when it will do nothing, and when it will make things worse. A trained model is a fixed-weight function that maps a sequence of tokens to a distribution over the next token. Those weights stay frozen during inference. The only lever a prompt has is the text that precedes the answer, and that preceding text steers which region of the model vast learned space the next token comes from.
Personas work by shifting the entire forward pass toward the part of that space consistent with expert writing, not by activating a discrete module that does not exist. Structure works two ways: the model has extensive practice with structured text, and a named schema narrows the field of plausible next tokens. Chain-of-thought works by giving the model intermediate tokens as scratch space, which is why it helps most on multi-step problems and least on one-shot ones. Few-shot examples work through the same pattern-copying circuitry, which is why one clean example beats five sloppy ones whose artifacts get reproduced.
The corollary is the most useful fact in the guide: none of these techniques adds a capability the model does not already have. When a task fails because the model lacks the underlying competence, a domain it never learned or a fact it does not know, no prompt will fix it. That is a model-selection problem, not a prompting problem, and knowing the mechanism is what lets you tell the two apart. Lightbridge Labs grounds its prompt engineering training in these mechanisms so practitioners can generalize past canned templates.
Choosing a Claude model is a separate decision from writing the prompt.
As of mid-2026 the Claude lineup spans Claude Fable 5 (the most capable), Claude Opus 4.8, Claude Sonnet 4.6, and Claude Haiku 4.5. A faster model can be the right answer for high-volume, well-specified work, while a more capable model earns its place on harder reasoning. Model surfaces change quickly, so confirm current capabilities and identifiers against the canonical Anthropic documentation at docs.anthropic.com before you commit a production choice.
Lightbridge Labs teaches prompt engineering as a practiced skill, not a one-off read.
This guide is the free primer. The Lightbridge Labs prompt engineering bootcamp is the hands-on program: teams practice on their own work with feedback, build a reusable prompt library, and standardize the practice across the organization. The two are complementary, the guide gives you the model and the bootcamp builds the muscle. Developers who want to apply the same discipline inside code and tooling can start with AI for developers.
When the question moves from individual technique to where AI belongs in the business, AI strategy consulting from Lightbridge Labs sets the direction: which work to automate, where to keep a human in the loop, and how to measure whether it is paying off.
This guide is independent, general educational content from Lightbridge Labs. Claude and Anthropic are trademarks of Anthropic, PBC. Lightbridge Labs is not affiliated with, endorsed by, or sponsored by Anthropic.
How to prompt Claude: frequently asked questions
- How do I write a good prompt for Claude?
- A good prompt answers five questions: who the model is for this task, what you want stated as one clear instruction, what context the model needs, what a good answer looks like, and what to avoid. Simple requests rarely need all five, but for anything complex or repeated, a missing layer degrades quality in predictable ways. Lightbridge Labs teaches this five-part mental model as the foundation of prompt engineering, then layers structure, format, and ambiguity-reduction techniques on top of it.
- What is the five-part mental model for prompting?
- The five-part mental model frames every strong prompt around five questions: Who are you (role and expertise), What do you want (the task, one verb, one outcome), What context is needed (background and prior decisions), What does good look like (examples and format), and What should be avoided (tone, content, and scope out of bounds). Lightbridge Labs uses this model because it maps cleanly onto the layers of an effective prompt and makes it easy to diagnose which layer is missing when an answer disappoints.
- Why does the same prompt give Claude different answers?
- Variation is a property of how language models work, not a defect. At the math layer, the model samples the next token from a probability distribution, and any temperature above zero introduces deliberate randomness. Even at temperature zero, floating-point arithmetic on parallel GPUs is not associative, so the order in which partial sums combine can shift the last bits of a calculation and occasionally flip which token ranks first. Batch composition on a busy server changes that order between requests. The practical response is to design workflows that tolerate or measure variation rather than demand reproducibility the technology cannot promise.
- Why does asking for a specific format improve Claude responses?
- Naming the output format gives back more than almost any other change, and most prompts skip it. Two mechanisms are at work. First, the model has seen enormous quantities of structured text in training, so the next-token distribution for valid JSON or a fixed table is sharper than the distribution over free prose. Second, structure narrows the search space: asking for a JSON object with named keys eliminates competing impulses to summarize, enumerate, or hedge. For automated workflows, structured output can also be parsed deterministically even when the content varies between runs.
- Do I still need to tell Claude to think step by step?
- Less than you used to. Chain-of-thought prompting, asking the model to produce intermediate reasoning before a final answer, was shown to improve performance on multi-step tasks because the intermediate tokens act as scratch space that gives the model more compute per problem. Modern Claude models already do the equivalent internally through adaptive thinking on tasks that warrant it, so a manual instruction adds less than it did in 2022. Forcing step-by-step reasoning on a task that does not need it can actually degrade quality and inflate cost.
- What is the difference between a system prompt and per-request context?
- A system prompt holds instructions that apply to every task in a project: the tech stack, the house style, the output preferences, the domain conventions. Per-request context applies only to the task in front of you: the specific document, the goal of this particular output, a constraint unique to this request. Keeping the two separate prevents project-level rules from cluttering a single message and keeps per-task details from leaking into work where they do not belong. Lightbridge Labs covers both in its prompt engineering training.
- How is this free guide different from the Lightbridge Labs prompt engineering bootcamp?
- This guide is the free primer: the mental model, the structure, the techniques, and the mechanisms, written to be read and applied immediately. The prompt engineering bootcamp at lightbridgelabs.ai/training/prompt-engineering-bootcamp is the hands-on program, where teams practice on their own work with feedback, build a reusable prompt library, and standardize the practice across an organization. They are complementary: the guide gives you the model, the bootcamp builds the muscle.
From a good prompt to a practiced team.
Read the primer, then build the skill. Lightbridge Labs trains teams to prompt with structure, measure what works, and standardize the practice across the organization.