Writing a prompt that works once is easy. Writing prompts that reliably produce the behaviour you want — across formats, tool calls, long tasks, and edge cases — is a craft with real, learnable technique. This guide walks through the practical best practices for prompting large language models (LLMs) like Claude, from the fundamentals of clear instructions all the way through orchestrating multi-agent systems. It's written primarily around Claude's own prompting guidance, since Anthropic publishes some of the most detailed, current documentation on the subject, but the underlying principles apply broadly to modern LLMs.

01. General Principles:

Before touching formatting, tools, or agentic loops, get the fundamentals right. These principles apply to virtually every prompt you write.

1.1. Be clear and direct:

• Models respond best to explicit, unambiguous instructions. If you want a particular output format, tone, or level of effort, say so — don't rely on the model to infer it. A useful mental model: think of the LLM as a brilliant but brand-new employee who has zero context on your norms, your codebase, or your preferences. The more precisely you explain what "good" looks like, the better the result.
• A simple gut-check: show your prompt to a colleague who has minimal context on the task, and ask them to follow it exactly. If they'd be confused about what to do, the model will be too. In practice, this means being specific about your desired output format and constraints, and providing instructions as sequential, numbered steps whenever order or completeness matters.

1.2. Add context to improve performance:

• Explaining why you want something — the motivation behind an instruction — helps the model generalise correctly rather than pattern-matching too narrowly. For example, instead of just saying "keep responses under 200 words," explaining that the output will be read aloud by a voice assistant helps the model make better judgment calls in edge cases you didn't explicitly cover. Modern LLMs are smart enough to generalise from an explanation, not just follow a rule literally.

1.3. Use examples effectively:

Examples — also known as few-shot or multishot prompting — are one of the most reliable levers for steering output format, tone, and structure. A handful of well-chosen examples reliably improves accuracy and consistency more than additional prose instructions do.

Effective examples share three qualities:

• Relevant — they mirror your actual use case closely.
• Diverse — they cover edge cases and vary enough that the model doesn't pick up unintended, accidental patterns.
• Structured — wrapping each example in tags (like <example>, with multiple examples inside <examples>) helps the model clearly distinguish demonstrations from instructions.

As a rule of thumb, three to five well-crafted examples outperform a long list of edge-case instructions. You can even ask the model itself to evaluate your examples for relevance and diversity, or to generate more based on your initial set.

Few-shot in practice: a prompt with three to five annotated examples (input → desired output) conditions the model to mimic that mapping on new, unseen inputs — a technique known as in-context learning. Adding a worked reasoning trace to each example (chain-of-thought) further improves performance on multi-step problems, since the model generalizes the reasoning pattern, not just the output format.

1.4. Structure prompts with XML tags:

When a prompt mixes instructions, background context, examples, and variable inputs, XML tags help the model parse each part unambiguously. Wrapping each type of content in its own tag — for example <instructions>, <context>, <input> — dramatically reduces the chance the model conflates one section with another.

Best practices for tagging:

• Use consistent, descriptive tag names throughout a single prompt.
• Nest tags when content has a natural hierarchy — for example, wrapping multiple source documents inside <documents>, with each individual document as <document index="n">.

1.5. Give the model a role:

Setting a role in the system prompt — even a single sentence — focuses tone and behavior for your specific use case. A system prompt like "You are a helpful coding assistant specializing in Python" immediately narrows the model's frame of reference before the first user message even arrives, producing more consistent, on-topic responses than an unset system prompt would.

1.6. Long context prompting:

When working with large documents or data-heavy inputs (roughly 20,000+ tokens), how you arrange the prompt matters as much as what's in it:

• Put long-form data near the top. Place documents and inputs above your query, instructions, and examples. In testing, moving the query to the end of a long prompt — after all the reference material — improved response quality by up to 30%, especially on complex, multi-document tasks.
• Structure documents with XML metadata. When passing multiple documents, wrap each in <document> tags with <document_content> and <source> subtags (plus any other useful metadata), so the model can keep sources distinct and cite them accurately.
• Ground responses in quotes first. For long-document tasks, ask the model to quote the relevant passages before carrying out its actual task. This anchors its attention on what actually matters in the document and reduces the odds it draws on irrelevant sections.

1.7. Model self-knowledge:

If your application needs the model to correctly identify itself — its name, or the exact API model string — state that explicitly in the system prompt rather than assuming the model already knows. For example: "The assistant is Claude, created by Anthropic. The current model is Claude Opus 5." This matters especially for apps that route between multiple models or need to report which model produced a given response.

2. Output and Formatting:

Once the model understands what you want, the next lever is controlling how it presents the answer.

2.1. Communication style and verbosity:

• Modern models tend toward a more concise, natural, conversational style by default — more direct and fact-based, less self-celebratory, and often less verbose than older models. In practice, this means a model might skip a written summary after a tool call and jump straight to the next action. If you want more visibility into its process, ask explicitly: "After completing a task that involves tool use, provide a quick summary of the work you've done." Verbosity behavior also varies by model generation, so if a specific model's default responses run longer or shorter than you'd like, prompt for the length you want rather than assuming a setting like reasoning effort will change it.

2.2. Control the format of responses:

A few techniques reliably steer output formatting:

• Say what to do, not what to avoid. Instead of "Do not use markdown," try "Your response should be composed of smoothly flowing prose paragraphs." Positive instructions are easier for a model to act on than negative constraints.
• Use XML tags as format indicators. For example, ask the model to write prose sections inside <smoothly_flowing_prose_paragraphs> tags.
• Match your prompt's style to your desired output's style. Models are influenced by the formatting of the prompt itself — a prompt written in heavy markdown tends to produce markdown-heavy output, and vice versa.
• Use a detailed, explicit block for persistent formatting preferences, such as an instruction telling the model to favor complete prose paragraphs over bullet points for long-form writing, and to reserve markdown for code and simple headings.

2.3. LaTeX output:

• Many current models default to LaTeX for mathematical notation. If you need plain text instead, say so explicitly: "Format your response in plain text only. Do not use LaTeX, MathJax, or markup notation... Write all math expressions using standard text characters."

2.4. Document creation:

• For generating presentations, documents, or other structured visual output, be specific about the level of polish you expect — for example, asking for "thoughtful design elements, visual hierarchy, and engaging animations where appropriate" produces noticeably better first-attempt results than a bare topic request.

2.5. Migrating away from prefilled responses:

• Older prompting workflows sometimes used prefilled responses — providing a partial assistant message for the model to continue from — to control formatting, skip preambles, avoid unwanted refusals, or maintain a persona across a conversation. Current-generation models are strong enough at instruction-following that most of these use cases no longer require prefill; instead, achieve the same outcomes with explicit formatting instructions, clear system prompts establishing tone and role, and direct requests for the output structure you want. Many newer models no longer support prefilled assistant turns at all, so it's worth migrating this pattern out of your prompts proactively rather than waiting for a breaking change.

3. Tool Use:

3.1. Tool usage:

Models trained for precise instruction-following will sometimes take you literally. If you ask "can you suggest some changes," the model may offer suggestions rather than implementing them — even if implementation is what you actually wanted. When you want the model to take action, be explicit about it rather than phrasing the request as a question.

If you want a model to default toward action, add explicit guidance to the system prompt, such as an instruction to implement changes rather than only suggesting them, and to infer the most useful action when intent is ambiguous rather than guessing blindly. Conversely, if you want more caution — research and recommendations before any implementation — state that instead. Either way, avoid over-aggressive language like "CRITICAL: you MUST use this tool"; modern models are highly responsive to system prompts, and inflated urgency tends to cause over-triggering rather than helping.

3.2. Optimize parallel tool calling:

Capable agentic models can run independent tool calls in parallel — reading several files at once, firing off multiple searches simultaneously, or running independent bash commands together — which meaningfully speeds up agentic workflows. This behavior is steerable in both directions:

• To maximize parallel execution, instruct the model to make all independent tool calls simultaneously whenever there's no dependency between them, and to only fall back to sequential calls when one call's parameters depend on a previous call's result.
• To reduce parallel execution — for example, if concurrent operations are straining a downstream system — instruct the model to execute operations sequentially with brief pauses between steps.

Show Image Source: Anthropic, "How we built our multi-agent research system" — parallelising tool calls, both within a single agent and across subagents, is one of the most effective levers for agent speed.

4. Thinking and Reasoning:

4.1. Overthinking and excessive thoroughness:

Reasoning-capable models sometimes do more upfront exploration than a task strictly requires — gathering extensive context or pursuing multiple research threads without being asked. If your prompts previously nudged a model toward being "more thorough," that guidance may now cause overtriggering rather than helping. A few fixes:

• Replace blanket defaults ("Default to using [tool]") with targeted conditions ("Use [tool] when it would enhance your understanding of the problem").
• Remove excessive hedge-language like "if in doubt, use [tool]," which reliably causes overuse in models already tuned toward proactive tool use.
• If a model continues to over-explore, lower its reasoning effort setting as a fallback, or add an explicit instruction to commit to an approach and avoid revisiting decisions absent new contradicting information.

4.2. Leverage thinking and interleaved thinking capabilities:

Modern reasoning-capable models can think — producing intermediate reasoning before a final answer — and, critically, can think between tool calls (interleaved thinking), reflecting on a tool's result before deciding the next step. This is especially valuable for multistep agentic tasks, complex coding problems, and long-horizon agent loops, where the "right" next action genuinely depends on what a previous tool call just returned.

Several practices make thinking more effective:

• Prefer general instructions over prescriptive step-by-step plans. A prompt like "think thoroughly" often outperforms a hand-written checklist, because the model's own reasoning frequently covers more ground than a human-authored plan would.
• Use <thinking> tags inside few-shot examples to demonstrate the reasoning pattern you want; the model will generalize that style into its own reasoning.
• Ask the model to self-check. Appending something like "before you finish, verify your answer against [criteria]" reliably catches errors, especially in coding and math tasks.
• Manage thinking latency. If a model is thinking more than you'd like — which can happen with large or complex system prompts — add an explicit instruction that thinking should only be used when it will meaningfully improve answer quality, and that the model should respond directly otherwise.

Show Image Source: Anthropic, "Claude's extended thinking" — accuracy on 2024 AIME math problems improves as a model is allowed more thinking tokens, illustrating why reasoning depth is a genuine performance lever, not just latency overhead.

5. Agentic Systems:

Agentic prompting — where a model runs in a loop, calling tools and making decisions over many steps — introduces a different set of concerns than single-turn prompting.

5.1. Long-horizon reasoning and state tracking:

Capable models can maintain orientation across extended sessions by focusing on incremental progress rather than trying to do everything at once. This capability really shines across multiple context windows: a model can work on a piece of a complex task, save its state, and pick up cleanly in a fresh context window later.

Context awareness and multi-window workflows. Some models can track their own remaining context ("token budget") through a conversation, letting them manage pacing and avoid wrapping up prematurely. If you're running an agent harness that compacts context automatically or saves state to external files, tell the model that explicitly — otherwise it may naturally try to finish up early as it senses it's approaching a context limit. An instruction like "your context window will be automatically compacted as it approaches its limit... do not stop tasks early due to token budget concerns" keeps the agent working persistently instead of self-truncating.

Workflows across multiple context windows. For tasks that genuinely span more than one context window:

Use a distinct first-window prompt to set up the framework (write tests, create setup scripts) before switching to iterative, todo-list-driven prompts for later windows.

Have the model write tests in a structured format (like tests.json) up front, and explicitly forbid removing or editing them without cause — this preserves correctness criteria across resets.

Set up "quality of life" tooling — setup scripts that start servers, run test suites, and run linters — so a freshly-started context window doesn't have to rediscover the environment from scratch.

When deciding between starting fresh versus compacting, remember that capable models are often very good at rediscovering state from the filesystem (via pwd, progress files, and git logs) — so a clean restart with clear pointers can sometimes beat compaction.

Provide verification tools — ways for the agent to check its own work (UI screenshots, browser automation, test runners) — so long autonomous stretches don't drift without any feedback signal.

State management best practices:

• Use structured formats (JSON) for state data like test results or task status, so schema requirements are unambiguous.
• Use unstructured freeform text for general progress notes.
• Use git as a state-tracking mechanism — it provides both a log of what's been done and restorable checkpoints.
• Explicitly ask the model to track progress and favor incremental work over attempting everything simultaneously.

Show Image Source: Anthropic — a lead agent persists its plan to memory before delegating to subagents, ensuring state survives context resets and long-running work stays coherent.

5.2. Balancing autonomy and safety:

Without explicit guidance, an autonomous agent may take actions that are difficult to reverse — deleting files, force-pushing to a shared branch, posting to an external service. If you want confirmation before risky actions, say so directly: encourage the model toward local, reversible actions (editing files, running tests) by default, but require it to ask before anything destructive, hard to reverse, or visible to others (deleting branches, git push --force, commenting on a public issue, modifying shared infrastructure). It also helps to explicitly forbid using destructive shortcuts to work around obstacles — for instance, bypassing safety checks like --no-verify, or discarding unfamiliar files that might be someone else's in-progress work.

5.3. Research and information gathering:

For research-style agentic tasks, three practices consistently improve outcomes:

Define clear success criteria up front — what does a genuinely successful answer look like?

Ask for source verification — instruct the model to cross-check information across multiple sources rather than trusting the first result.

Use a structured approach for complex research: have the model develop competing hypotheses as it gathers data, track confidence levels in progress notes, and regularly self-critique its plan. This helps a model work through large amounts of information methodically instead of stopping at the first plausible answer.

5.4. Subagent orchestration:

Capable agentic models can recognize when a task benefits from delegating work to specialized subagents — and do so proactively, without needing to be explicitly told. To make good use of this:

• Ensure subagent tools are well-defined and clearly described, so the orchestrating model knows when each one applies.
• Let delegation happen naturally rather than over-specifying it.
• Watch for overuse — some models have a strong pull toward spawning subagents even for simple tasks (like a single grep search) where a direct call would be faster. If you see this, add explicit guidance distinguishing when subagents are warranted — parallelizable work, tasks needing isolated context, independent workstreams — from when direct, sequential work is better — simple tasks, single-file edits, or anything requiring shared context across steps.

Anthropic's own multi-agent research system is a useful reference architecture here: a lead agent decomposes a query, spawns three to five subagents in parallel (each exploring a different angle with its own context window and tool budget), and each subagent returns a condensed summary — often just 1,000–2,000 tokens — rather than its full raw exploration. This keeps the lead agent's own context clean while still benefiting from deep, parallel investigation. It's a powerful pattern, but a token-hungry one: multi-agent systems can use roughly 15 times the tokens of a simple chat interaction, so they're best reserved for tasks where the value of the improved outcome justifies the cost.

5.5. Chain complex prompts:

With strong internal reasoning and native subagent orchestration, most multistep reasoning can now happen inside a single model call rather than requiring you to manually chain separate API requests. Still, explicit prompt chaining — breaking a task into sequential calls — remains useful when you need to inspect intermediate outputs directly or enforce a specific pipeline structure that shouldn't be left to the model's discretion.

The most common and reliable chaining pattern is self-correction: generate a draft, have the model review that draft against explicit criteria, then have it refine the draft based on its own review. Running each step as a separate call lets you log, evaluate, or branch the pipeline at any point.

5.6. Reduce file creation in agentic coding:

Agentic coding models often create temporary files — especially scripts — as a scratchpad for testing and iteration before producing a final answer. This generally improves outcomes for agentic coding tasks, so it's not something to eliminate by default. If you specifically want a clean workspace afterward, instruct the model to clean up any temporary files, scripts, or helper files it created for iteration once the task is complete.

5.7. Overeagerness:

Some models tend toward overengineering — adding extra files, unnecessary abstractions, or flexibility nobody asked for. If you see this, add scope-limiting guidance covering four dimensions: scope (don't add features or "improvements" beyond what was requested), documentation (don't add comments or docstrings to unchanged code), defensive coding (don't add error handling for scenarios that can't actually occur — validate only at real system boundaries), and abstractions (don't build helpers or utilities for one-time operations, or design for hypothetical future requirements). The right amount of complexity is the minimum needed for the task in front of the model, not the maximum it can imagine.

5.8. Avoid focusing on passing tests and hardcoding:

Agentic coding models can sometimes over-index on making a specific test suite pass rather than solving the underlying problem generally — occasionally through workarounds or values hardcoded to match known test inputs. To prevent this, be explicit: ask for a high-quality, general-purpose solution using standard tools (not helper scripts or workarounds), state clearly that tests exist to verify correctness rather than define the solution, and ask the model to flag it directly if a task seems unreasonable or a test appears incorrect, rather than silently working around it.

5.9. Minimizing hallucinations in agentic coding:

Grounding matters enormously in agentic coding contexts, where confident-sounding but wrong claims about a codebase can derail an entire task. A simple, effective instruction: never speculate about code that hasn't been opened; if a user references a specific file, read it before answering; investigate before making any claim about a codebase rather than guessing from a filename or a vague memory of similar code seen elsewhere.

6. Capability-Specific Tips:

6.1. Improved vision capabilities:

Modern multimodal models handle image processing and data extraction meaningfully better than earlier generations — including when multiple images are present in a single context, and in computer-use settings where the model interprets live screenshots and UI elements. One technique that reliably boosts performance further: give the model a crop tool (or an equivalent agent skill) that lets it "zoom in" on a specific region of an image before answering. Testing consistently shows uplift on image-heavy evaluations from this simple capability, since it lets the model focus its attention on the exact pixels that matter rather than the whole frame at once. Video can be handled similarly, by decomposing it into individual frames for analysis.

6.2. Frontend design:

Left unguided, models tend to converge on generic, safe design patterns — sometimes called "AI slop": overused fonts like Inter or Arial, predictable purple gradients on white backgrounds, and cookie-cutter layouts. This happens because safe, universally-inoffensive choices dominate web training data, so without direction, a model samples from that high-probability center by default.

Why this happens: during sampling, models predict tokens based on statistical patterns learned from training data. Safe, universally-acceptable design choices dominate that data, so without direction, the model samples from that high-probability center — landing on the same fonts, gradients, and layouts again and again. Anthropic's own frontend-design research calls this distributional convergence.

The fix is direct, specific prompting across a few concrete axes:

• Typography — request distinctive, characterful fonts and explicitly rule out overused defaults (Inter, Roboto, Arial, system fonts).
• Color and theme — ask for a cohesive, committed aesthetic using CSS variables for consistency, favoring a dominant palette with sharp accents over a timid, evenly-distributed one.
• Motion — request purposeful animation and micro-interactions, prioritizing a few well-orchestrated moments (like a staggered page-load reveal) over scattered effects everywhere.
• Backgrounds — ask for atmosphere and depth (gradients, geometric patterns, contextual effects) rather than defaulting to flat, solid colors.

Because models are highly steerable on this dimension, even a short instruction block naming these axes and explicitly banning the most overused patterns produces a noticeably more distinctive result than an unguided request for "a landing page."

7. Conclusion:

Good prompting is less about finding one magic phrase and more about being deliberately explicit — about output format, about context and motivation, about when to act versus when to ask, and about how much autonomy a model should exercise at any given step. The core techniques compound: clear, direct instructions plus well-chosen examples plus sensible structure (XML tags, roles, document ordering) get you a strong single-turn prompt. Layer in thoughtful tool-use guidance, calibrated reasoning depth, and deliberate state management, and that same discipline scales up into reliable, long-running agentic systems.

None of this is static. As models get more capable, some old habits — aggressive "you MUST" language, manual chain-of-thought scaffolding, heavy-handed thoroughness instructions — start working against you rather than for you, because the model is already doing that work well on its own. The practical takeaway is to keep testing your prompts against current model behavior rather than assuming yesterday's best practice still holds, and to prefer clear, calibrated instructions over brittle, over-engineered ones. That mindset — precise about intent, light on unnecessary constraint — is what separates prompts that work once from prompts that keep working as tasks, tools, and models evolve.

References and Further Reading:

• Anthropic — Prompting Best Practices (Claude Platform Docs)
• Anthropic — How We Built Our Multi-Agent Research System
• Anthropic — Claude's Extended Thinking
• Anthropic — Improving Frontend Design Through Skills
• Anthropic — Building Effective AI Agents