Skip to content

Article

Prompting Best Practices

Claude API Docs

Source ↗ ← All highlights
  • Claude Opus 4.7 calibrates response length to how complex it judges the task to be, rather than defaulting to a fixed verbosity. This usually means shorter answers on simple lookups and much longer ones on open-ended analysis.
  • If your product depends on a certain style or verbosity of output, you may need to tune your prompts. As an example, to decrease verbosity, you might add: Provide concise, focused responses. Skip non-essential context, and keep examples minimal.
  • We expect effort to be more important for this model than for any prior Opus, and recommend experimenting with it actively when you upgrade.
  • If you are running Claude Opus 4.7 at max or xhigh effort, set a large max output token budget so the model has room to think and act across its subagents and tool calls. We recommend starting at 64k tokens and tuning from there.
  • Claude Opus 4.7 provides more regular, higher-quality updates to the user throughout long agentic traces. If you’ve added scaffolding to force interim status messages (“After every 3 tool calls, summarize progress”), try removing it. If you find that the length or contents of Claude Opus 4.7’s user-facing updates are not well-calibrated to your use case, explicitly describe what these updates should look like in the prompt and provide examples.
  • As with any new model, prose style on long-form writing may shift. Claude Opus 4.7 is more direct and opinionated, with less validation-forward phrasing and fewer emoji than Claude Opus 4.6’s warmer style. If your product relies on a specific voice, re-evaluate style prompts against the new baseline.
  • if your product voice is warmer or more conversational, add: Use a warm, collaborative tone. Acknowledge the user’s framing before answering.
  • Claude Opus 4.7 has stronger design instincts than Claude Opus 4.6, with a consistent default house style: warm cream/off-white backgrounds (~#F4F1EA), serif display type (Georgia, Fraunces, Playfair), italic word-accents, and a terracotta/amber accent. This reads well for editorial, hospitality, and portfolio briefs, but will feel off for dashboards, dev tools, fintech, healthcare, or enterprise apps — and it appears in slide decks as well as web UIs.
  • This default is persistent. Generic instructions (“don’t use cream,” “make it clean and minimal”) tend to shift the model to a different fixed palette rather than producing variety. Two approaches work reliably:
  • 1. Specify a concrete alternative. The model follows explicit specs precisely: Design a desktop landing page for a supplement brand called AEFRM. The visual direction should come from a cold monochrome atmosphere using pale silver-gray tones that gradually deepen into blue-gray and near-black, similar to a misted metallic surface. The page should feel sharp and controlled, with a strong sense of structure and restraint. Use this tonal system across the full page instead of introducing bright accent colors. Use the uploaded image on the hero design in black and white. The layout should be built with clear horizontal sections and a centered max-width container. Use 4px corner radius consistently across cards, buttons, inputs, and media frames. Margins should feel generous, with enough empty space around each section so the page breathes. Typography should use a square, angular sans-serif with wider letter spacing than usual, especially in headings and navigation, so the text feels more engineered and less compressed. Headline text can be large and uppercase, while supporting copy remains short and sparse. The sub texts should be written with Alumni Sans SC in 4-6px like tiny little texts on corners bottom centre like that. For the structure, start with a hero section containing a strong product statement, one short supporting paragraph, and a clean product placeholder or packshot frame. Below that, add a benefit grid with three or four blocks, then a formulation or ingredients section, and finally a cta. Buttons should be flat and precise, with subtle hover changes using transition: all 160ms ease out where brightness and border contrast shift slightly rather than using dramatic motion. Color palette should stay within this range: #E9ECEC, #C9D2D4, #8C9A9E, #44545B, #11171B.
  • 2. Have the model propose options before building. This breaks the default and gives users control. If you previously relied on temperature for design variety, use this approach — it produces meaningfully different directions across runs. Example prompt: Before building, propose 4 distinct visual directions tailored to this brief (each as: bg hex / accent hex / typeface — one-line rationale). Ask the user to pick one, then implement only that direction.
  • Additionally, Claude Opus 4.7 requires less frontend design prompting than previous models to avoid generic patterns that users call the “AI slop” aesthetic. With earlier models, we recommended a lengthier prompt snippet in our frontend-design skill. However, Claude Opus 4.7 generates distinctive, creative frontends with more minimal prompting guidance.
  • This prompt snippet works well with the above prompting advice for variety: <frontend_aesthetics> NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white or dark backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character. Use unique fonts, cohesive colors and themes, and animations for effects and micro-interactions. </frontend_aesthetics>
  • Some recommended prompt language: Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.
  • Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.
  • Golden rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they’d be confused, Claude will be too. • Be specific about the desired output format and constraints. • Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.
  • Providing context or motivation behind your instructions, such as explaining to Claude why such behavior is important, can help Claude better understand your goals and deliver more targeted responses. Claude is smart enough to generalize from the explanation.
  • When adding examples, make them: • Relevant: Mirror your actual use case closely. • Diverse: Cover edge cases and vary enough that Claude doesn’t pick up unintended patterns. • Structured: Wrap examples in <example> tags (multiple examples in <examples> tags) so Claude can distinguish them from instructions. Include 3–5 examples for best results. You can also ask Claude to evaluate your examples for relevance and diversity, or to generate additional ones based on your initial set.
  • XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. <instructions>, <context>, <input>) reduces misinterpretation.
  • When working with large documents or data-rich inputs (20k+ tokens), structure your prompt carefully to get the best results: • Put longform data at the top: Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples. This can significantly improve performance across all models. Queries at the end can improve response quality by up to 30% in tests, especially with complex, multi-document inputs. • Ground responses in quotes: For long document tasks, ask Claude to quote relevant parts of the documents first before carrying out its task. This helps Claude cut through the noise of the rest of the document’s contents.
  • Tell Claude what to do instead of what not to do • Instead of: “Do not use markdown in your response” • Try: “Your response should be composed of smoothly flowing prose paragraphs.”
  • Use XML format indicators • Try: “Write the prose sections of your response in <smoothly_flowing_prose_paragraphs> tags.”
  • To make Claude more proactive about taking action by default, you can add this to your system prompt: <default_to_action> By default, implement changes rather than only suggesting them. If the user’s intent is unclear, infer the most useful likely action and proceed, using tools to discover any missing details instead of guessing. Try to infer the user’s intent about whether a tool call (e.g., file edit or read) is intended or not, and act accordingly. </default_to_action>
  • if you want the model to be more hesitant by default, less prone to jumping straight into implementations, and only take action if requested, you can steer this behavior with a prompt like the below: <do_not_act_before_instructions> Do not jump into implementatation or changes files unless clearly instructed to make changes. When the user’s intent is ambiguous, default to providing information, doing research, and providing recommendations rather than taking action. Only proceed with edits, modifications, or implementations when the user explicitly requests them. </do_not_act_before_instructions>