# Prompt Engineering Best Practices This note has two parts. The first covers what Anthropic's current prompting guide says for today's Claude models (Fable 5.x, Mythos 5.x, Opus 5.x, Sonnet 5.x, Haiku 5.5 and the late 4.x models), with what changed compared to older advice. The second is the general checklist I started in 2024, when prompts mostly targeted chat models, plus a few Claude cookbook tips. Some of the older advice no longer works. Two of the tips in the Claude cookbook section now return API errors; I marked them. ## What changed for current Claude models | Older advice | What Anthropic's guide says now | |---|---| | Prefill the assistant turn with `{` to force JSON | Prefilling the last assistant turn returns a 400 error since the Claude 4.6 models. Use structured outputs, or ask for the schema (with retries) | | Extended thinking with a `budget_tokens` cap | Adaptive thinking plus the `effort` parameter. `budget_tokens` returns a 400 error on Claude 4.7 and later | | "Think step by step", or reasoning written out in `<thinking>` tags | Thinking is always on for Fable 5.x and Opus 5.5. Asking the model to write its reasoning in the reply might be declined. Manual chain of thought stays a fallback for when thinking is off | | A hand-written step-by-step plan for hard problems | A general "think thoroughly" often produces better reasoning than a prescribed plan | | "CRITICAL: You MUST use this tool when..." | Recent models overtrigger on that. Write "Use this tool when..." | | "If in doubt, use [tool]" and other anti-laziness lines | Remove them. Tools that undertriggered before now trigger on their own, and these lines cause overtriggering | | "Verify your answer before you finish" | Still useful, except on Opus 5: it checks its own work, and carried-over checks cause over-verification | | Put the most important instruction at the top | With long inputs (20k+ tokens), put the documents at the top and the question at the end | | Edit or summarize earlier turns to save context | On Fable 5.1 and later, Opus 5.5, Sonnet 5.5 and Haiku 5.5, that invalidates every later thinking block. Keep the history append-only | | A long block of "avoid markdown" rules | On Fable 5.1, which already formats less, that block can remove structure the content needs | ## Techniques for all current Claude models ### Read the page for your model first Anthropic now publishes one prompting page per model, listing where that model behaves differently: effort calibration, progress updates, subagent use, verbosity, refusals, and so on. The general guide says to read the model's page first, then the shared techniques below. When a technique names a specific model, it was measured on that model; re-check it with your own evals before you apply it to another one. My notes on two of those pages: [[Claude Fable 5.2]] (calibrating effort again, finishing long tasks, saying who owns the code, caution that piles up in memory files) and [[Claude Opus 5.5]] (handing over the whole task, finish lines, verifiable output). ### Be clear and direct Anthropic suggests thinking of Claude as a brilliant new employee who doesn't know your norms and workflows: the more precisely you explain what you want, the better the result. To check a prompt, show it to a colleague with little context on the task. If they'd be confused, Claude will be too. - Be specific about the output format and the constraints - Use numbered steps when the order or the completeness of the steps matters - If you want more than the minimum, ask for it. "Create an analytics dashboard" gets a basic one. Adding "Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation." gets the full version ### Give the reason behind each rule A rule with its reason works better than a bare rule, because Claude generalizes from the explanation. In the guide's example, "NEVER use ellipses" is weaker than "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them." With the reason, the model also knows what to do in cases the rule doesn't name. ### Use 3 to 5 examples Examples remain one of the most reliable ways to steer format, tone and structure (few-shot or multishot prompting). The guide recommends 3 to 5 examples that are: - Relevant: close to the real use case - Diverse: covering edge cases, and varied enough that Claude doesn't copy a pattern you didn't intend - Wrapped in `<example>` tags (several of them in `<examples>`), so they stay separate from the instructions You can ask Claude to judge your examples for relevance and diversity, or to write more based on your first set. Examples also work with thinking: present each one as a problem, the method to apply and the expected answer, and Claude reuses that approach in its own reasoning. ### Structure the prompt with XML tags When a prompt mixes instructions, context, examples and variable inputs, wrap each kind of content in its own tag (`<instructions>`, `<context>`, `<input>`). Keep the tag names consistent and descriptive across your prompts, and nest them when the content has a hierarchy (a `<documents>` block holding `<document index="n">` items). ### Set a role in the system prompt A role in the system prompt focuses Claude's behavior and tone. One sentence is enough to make a difference: "You are a helpful coding assistant specializing in Python." If your application needs Claude to name itself correctly, say so: "The assistant is Claude, created by Anthropic. The current model is Claude Opus 5.5." Same for apps that pick a model: give the exact model string. ### Put long documents first and the question last For inputs above about 20k tokens: - Place the documents at the top, above the query, the instructions and the examples. In Anthropic's tests, a query at the end improved response quality by up to 30%, especially with complex, multi-document inputs - Wrap each document in a `<document>` tag with `<source>` and `<document_content>` subtags (plus any other metadata), inside a `<documents>` block - Ask Claude to quote the relevant passages first (in `<quotes>` tags), then work from those quotes. That keeps it focused on the parts that matter and away from the rest ### Expect shorter answers and fewer summaries Recent models write more concisely than earlier ones: fact-based progress reports instead of self-congratulation, a slightly more conversational tone, and fewer detailed summaries. After tool calls, Claude may skip the summary and go straight to the next action. If you want to see what it did: "After completing a task that involves tool use, provide a quick summary of the work you've done." Two exceptions: - Claude Opus 5 writes longer user-facing answers than earlier models, and raising or lowering effort doesn't reliably change that length. Ask for conciseness in the prompt - Claude Fable 5.1 writes fewer updates between tool calls during agentic work. Ask for progress text explicitly, and remove instructions that tell it to keep that text short. Fable 5.2 has its own advice for long turns (see [[Claude Fable 5.2]]) ### Control the format - Say what to do instead of what not to do. "Your response should be composed of smoothly flowing prose paragraphs." works better than "Do not use markdown in your response" - Use XML format indicators: "Write the prose sections of your response in `<smoothly_flowing_prose_paragraphs>` tags." - Match your prompt's style to the output you want. A prompt without markdown gets less markdown back - For fine control, write a detailed block. The guide's sample (`<avoid_excessive_markdown_and_bullet_points>`) asks for prose paragraphs, keeps markdown for inline code, code blocks and simple headings, and allows lists only for truly discrete items or when the user asks for one. On Fable 5.1, which formats less already, drop that block or use the shorter rule from its own page - Recent models default to LaTeX for math. If you need plain text, say so, and name the characters to use ("/" for division, "*" for multiplication, "^" for exponents) ### Replace prefilled responses Prefilling means sending a partial assistant message for Claude to continue. Starting with the Claude 4.6 models and Claude Mythos Preview, a prefill on the last assistant turn returns a 400 error. Assistant messages elsewhere in the conversation still work, and older models still accept prefills. Anthropic's view is that most prefill use cases aren't needed anymore, because instruction following got good enough. The replacements: | Prefill was used for | Use instead | |---|---| | Forcing JSON, YAML or a classification label | [[LLM Structured Outputs\|Structured outputs]], or ask for the schema (newer models match complex schemas when told to, especially with retries). For classification, a tool with an enum field holding the valid labels | | Skipping the preamble ("Here is the requested summary:") | A system prompt line: "Respond directly without preamble. Do not start with phrases like 'Here is...', 'Based on...', etc." Or output inside XML tags, structured outputs or a tool call. Strip the rare leftover in post-processing | | Steering around unnecessary refusals | Clear prompting in the user message. Refusals got more accurate | | Continuing an interrupted answer | Move it to the user turn: "Your previous response was interrupted and ended with `[previous_response]`. Continue from where you left off." Or retry the request if that doesn't hurt the UX | | Re-injecting context in long conversations | Put the reminders in the user turn, expose the context through tools, or refresh it during context compaction | ### Ask for action explicitly Recent models follow instructions precisely. "Can you suggest some changes to improve this function?" gets suggestions. "Change this function to improve its performance." gets the edit. The guide has two system-prompt blocks to set the default: - `<default_to_action>`: implement changes instead of only suggesting them. When the intent is unclear, infer the most useful action and use tools to find the missing details instead of guessing - `<do_not_act_before_instructions>`: don't change files unless clearly asked. When the intent is ambiguous, default to information, research and recommendations Tone down aggressive wording. Claude Opus 4.5 and 4.6 already respond more strongly to the system prompt, so prompts written to fix undertriggering on tools or skills now make them overtrigger. Replace "CRITICAL: You MUST use this tool when..." with "Use this tool when...". See [[AI Tool Use]]. ### Run independent tool calls in parallel Recent models already run independent tool calls in parallel: several searches during research, several file reads, several bash commands at once (which can bottleneck the machine). A `<use_parallel_tool_calls>` block in the system prompt pushes that to about 100%: call independent tools together, call dependent ones in sequence, and never use placeholders or guess missing parameters. For the opposite behavior: "Execute operations sequentially with brief pauses between each step to ensure stability." On Fable 5.1, in long agent loops, send the parallel-calls instruction again as a turn-scoped system message after each round of tool results. ### Thinking and effort - Claude 4.6 and later models use adaptive thinking (`thinking: {type: "adaptive"}`): Claude decides when and how much to think, based on the `effort` parameter and on how complex the query is. Higher effort means more thinking. On easy queries, it answers directly - On Fable 5.x, Mythos 5.x and Opus 5.5, thinking is always on, whatever you set. Fable 5.2 and Mythos 5.2 think before almost every reply at `high` effort and above - On Opus 5, Sonnet 5, Sonnet 5.5 and Haiku 5.5, thinking is on when you omit the `thinking` parameter, so a response can start with thinking blocks. Select content blocks by `type`, not by position, and leave room for thinking in `max_tokens` - `budget_tokens` is deprecated on Opus 4.6 and Sonnet 4.6, and returns a 400 error on Claude 4.7 and later. Move cost control to `effort`, with `max_tokens` as the hard ceiling. [[Claude Code effort levels]] covers how the levels behave in practice - Prefer general instructions over prescriptive steps. "Think thoroughly" often produces better reasoning than a hand-written plan; Claude's reasoning frequently goes beyond what a human would prescribe - Guide the thinking where it helps, e.g., after tool use: "After receiving tool results, carefully reflect on their quality and determine optimal next steps before proceeding." - Manual [[Chain-of-Thought (CoT) prompting]] (reason first, final answer in `<answer>` tags) is the fallback for when thinking is off. On Fable 5.x, Opus 5, Opus 5.5 and Sonnet 5.5, rely on thinking instead, at a lower effort if cost or latency matters. A prompt asking the model to write out its reasoning (for example in `<thinking>` tags) might be declined - Ask for a self-check: "Before you finish, verify your answer against [test criteria]." It catches errors reliably, especially in code and math. Opus 5 is the exception: it verifies its own work without being asked, so remove these instructions there - With thinking disabled, Opus 4.5 is sensitive to the word "think". Use "consider", "evaluate" or "reason through" instead ### When it explores or thinks too much Opus 4.6 does more upfront exploration than earlier models, especially at high effort. Prompts that pushed older models to be more thorough now overshoot: - Replace blanket defaults with targeted ones: "Use [tool] when it would enhance your understanding of the problem" instead of "Default to using [tool]" - Remove over-prompting such as "If in doubt, use [tool]" - If it keeps going back and forth: "When you're deciding how to approach a problem, choose an approach and commit to it. Avoid revisiting decisions unless you encounter new information that directly contradicts your reasoning." - If thinking triggers too often (it happens with large or complex system prompts): "Thinking adds latency and should only be used when it will meaningfully improve answer quality - typically for problems that require multistep reasoning. When in doubt, respond directly." - If it still does too much, lower the effort. On Fable 5.2, lower the effort instead of prompting: in Anthropic's tests, an instruction to answer directly didn't stop it from thinking at `medium` and above ## Agentic systems ### Long tasks across several context windows Recent models keep track of state well over long tasks, by making steady progress on a few things at a time. Sonnet 5, Sonnet 4.6, Sonnet 4.5 and Haiku 4.5 also track how much of their [[Context Window]] remains ("context awareness"). Near the limit, they may try to wrap up early. If your agent compacts context or saves it to files (as [[Claude Code]] does), say so in the prompt: "Your context window will be automatically compacted as it approaches its limit, allowing you to continue working indefinitely from where you left off. Therefore, do not stop tasks early due to token budget concerns." The guide's full sample also asks it to save progress to memory before the window refreshes. The memory tool pairs well with this. For work that spans several context windows: 1. Use a different prompt for the first window. Have it set up the framework (tests, setup scripts), then iterate on a todo list in the following windows 2. Have it write the tests first and track them in a structured file such as `tests.json`. Tell it why they matter: "It is unacceptable to remove or edit tests because this could lead to missing or buggy functionality." 3. Have it write convenience scripts (e.g., `init.sh`) that start servers and run the test suites and linters, so a fresh window doesn't redo the setup 4. Consider starting a fresh window instead of compacting. Recent models are very good at rebuilding state from the local filesystem. Be prescriptive about how it starts: "Call pwd; you can only read and write files in this directory.", "Review progress.txt, tests.json, and the git logs.", "Manually run through a fundamental integration test before moving on to implementing new features." 5. Give it verification tools (computer use, browser use, a browser automation MCP server), so it can check UI work without you 6. Encourage it to use its whole context: plan the work, continue systematically, and don't run out of context with significant uncommitted work ### Track state in files and git - Use structured formats (JSON) for structured state such as test results or task status - Freeform text works better for progress notes (a `progress.txt` with what got fixed and what's next) - [[Git]] gives you a log and checkpoints you can restore. Recent models use it well across sessions - Ask explicitly for incremental progress ### Ask before risky actions Without guidance, Opus 4.6 may take actions that are hard to undo or that affect shared systems: deleting files, force-pushing, posting to external services. The guide suggests a block that lets it take local, reversible actions (editing files, running tests) freely and makes it ask before anything destructive, hard to reverse or visible to others (`rm -rf`, dropping tables, `git push --force`, `git reset --hard`, amending published commits, pushing code, commenting on PRs, sending messages). It also tells the model not to use destructive shortcuts when it hits an obstacle, such as `--no-verify` or discarding unfamiliar files that may be someone's work in progress. ### Research Define what a successful answer looks like, and ask Claude to verify information across several sources. For complex research, ask for a structured approach: several competing hypotheses, confidence levels tracked in progress notes, regular self-critique of the approach, and a hypothesis tree or research notes file that keeps the findings visible. ### Subagents Recent models delegate to subagents on their own when the subagent tools are well described. Watch for overuse: Opus 4.6 spawns subagents where a direct `grep` would be faster, and Opus 5 also delegates more readily than earlier models. If you see too many, add guidance on when they're warranted: "Use subagents when tasks can run in parallel, require isolated context, or involve independent workstreams that don't need to share state. For simple tasks, sequential operations, single-file edits, or tasks where you need to maintain context across steps, work directly rather than delegating." More in [[AI Subagents]] and [[Orchestrator tax]]. ### Prompt chaining With adaptive thinking and subagents, Claude handles most multistep reasoning within a single call. Explicit [[Prompt Chaining]] still helps when you need to inspect intermediate outputs or enforce a fixed pipeline. The most common pattern is self-correction: generate a draft, have Claude review it against criteria, then have it refine the draft based on the review. Each step is a separate API call, so you can log, evaluate or branch at any point. ### Overeagerness Opus 4.5 and 4.6 tend to overengineer: extra files, abstractions nobody needs, flexibility nobody asked for. The guide's block asks for the minimum change: - Scope: no features, refactors or "improvements" beyond the request. A bug fix doesn't need the surrounding code cleaned up - Documentation: no docstrings, comments or type annotations on code it didn't change - Defensive coding: no error handling or fallbacks for scenarios that can't happen. Validate only at system boundaries (user input, external APIs) - Abstractions: no helpers for one-time operations, no design for hypothetical future requirements Temporary files are related. Claude may write scratch scripts while it iterates, which can improve results in agentic coding. If you don't want them left behind: "If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task." Fable 5.2 can move the other way: told that the codebase is its own, it merges repeated code and fixes nearby problems without being asked (see [[Claude Fable 5.2]]). ### Tests and hard-coded solutions Claude can focus on making the tests pass instead of solving the problem in general. Ask for a general-purpose solution with the standard tools, no hard-coded values for specific test inputs, and include this line: "If the task is unreasonable or infeasible, or if any of the tests are incorrect, please inform me rather than working around them." ### Hallucinations Recent models hallucinate less about code and give more grounded answers. The guide's `<investigate_before_answering>` block pushes further: never speculate about code it hasn't opened, read any file the user references before answering, and investigate the relevant files before making claims about the codebase. See [[AI Hallucination]]. ## Vision, frontend and medical prompts - Vision: give Claude a crop tool or skill, so it can zoom into the relevant region of an image. Anthropic saw consistent gains on image evaluations with it (there's a cookbook recipe) - Frontend design: without guidance, models fall back to generic layouts, the look people call "AI slop". The guide's `<frontend_aesthetics>` block asks for distinctive fonts (no Inter, Roboto or Arial), a committed color theme with sharp accents, CSS animations at a few high-impact moments, and layered backgrounds instead of flat colors - Medication dosing: if people may ask your application about doses of children's medicine, add Anthropic's `<medical_guidance>` block for your model to the system prompt, exactly as written. It makes Claude take the dose from the product's label (checked with web search when available) and otherwise point people to the label's chart, a pharmacist or the child's doctor ## Migrating prompts from older models The guide's checklist: 1. Describe precisely the behavior you want in the output 2. Add modifiers that ask for quality and detail ("Go beyond the basics to create a fully-featured implementation.") 3. Ask explicitly for animations and interactive elements when you want them 4. Switch to adaptive thinking and `effort`; drop `budget_tokens` 5. Remove prefilled responses (see above) 6. Tone down anti-laziness prompting. The Claude 4.6 models are more proactive and overtrigger on instructions that older models needed 7. Pass thinking blocks back unchanged and keep the history append-only. On Fable 5.1 and 5.2, Mythos 5.1 and 5.2, Opus 5.5, Sonnet 5.5 and Haiku 5.5, editing earlier messages, rebuilding `system` or `tools`, or summarizing older turns in place invalidates every later thinking block. Move those changes to mid-conversation system messages and server-side context management For Fable 5.2, the model's own page adds a migration order: set the effort explicitly, reread every prompt, skill, agent file and memory file you carry over, run your longest agentic tasks, and fix one behavior at a time. My summary is in [[Claude Fable 5.2]]. ## My take A good part of what changed is removal. Caps-lock MUSTs, "think step by step", prefills, thinking budgets, "if in doubt, use the tool": these were workarounds for weaker models. On current models, they cause problems of their own (overtriggering, over-verification, declined requests, 400 errors). This very note recommended prefilling `{` for JSON; that request now fails. What's left is close to writing a good brief for a smart colleague who just joined: the goal, the context, the reason behind each rule, a few examples, and what "done" means. It fits how I already see prompt engineering: one part of [[Context Engineering]]. The tip I'd apply first is the reason behind each rule. A rule that carries its "why" lets the model judge when it applies, and it survives model changes better. Many of my own agent rules already explain themselves (the casing-rename rule in my vault instructions spells out the sync storms it prevents). The ALL-CAPS "DO NOT" and "ALWAYS" lines are the ones I'd rewrite, since Anthropic now says that kind of wording makes recent models overtrigger. And reread your prompts whenever you switch models. The per-model pages exist because the same line can help one model and hurt the next: verification instructions on Opus 5, "answer directly" on Fable 5.2, the anti-markdown block on Fable 5.1. ## General checklist (2024) Input - Context - Persona - You are roles... - that what it should do... - Input data - Instructions - Desired output - Goal(s) - Proofread and correct - Spelling and Grammar - Tone adjustment - Text conversion - Translation - ... - Summarize text - For a specific audience - With a word or sentence limit - With a specific focus - Expand text - Analysis / Text classification - Analyze the sentiment ... - Classify the following comment's sentiment as positive, neutral or negative - Determine the topics being discussed - Determine the category of issue being discussed, and assign a confidence percentage to each result - Identify named entities / Text extraction / Keyword extraction - Identify ... - Please extract ... - Extract important keywords ... - Text-to-image generation - Subject - Description - Style (e.g., modern, artistic, wideshot, close-up, impressionist, etc) - Code generation - ... - Examples (optional) - Constraints - Behavior - Avoid misinformation - ... providing reference to credible, and peer-reviewed sources whenever possible - Avoid bias/unfairness - Provide a balanced review... - Considering both the strengths and weaknesses, without favoring any particular genre... - Avoid copyright infringment - Create unique ... - Ensure that all content you generate is original and does not infringe upon any existing copyrights or use copyrighted material - Improve transparency - Detail your reasoning, the underlying principles, ... - Output guidelines - Format - e.g., JSON, Markdown, etc - Length / Verbosity - Structure - Tone - Style - Mood - ... - ... Verbosity control: - In one word - In one sentence - In a paragraph - Briefly explain - Provide a detailed analysis Tone control: - Formal - Casual - Humorous - Fun - Relatable - Independent - Intuitive - As if explaining to a child - Like I'm a 5 year old - For a teenager - Friendly - Like you're talking to a friend - Engaging Role examples: - A subject matter expert (e.g. a historian, scientist, lawyer, doctor) - A writing assistant (e.g. to help brainstorm ideas or edit your work) - A specific character or persona (e.g. a pirate, talk show host, or famous person) - An objective, neutral analyst to summarize information - A creative story teller or worldbuilder - I want you to act as a life coach. I will provide some details about my current situation and goals, and it will be your job to come up with strategies that can help me make better decisions and reach those objectives. This could involve offering advice on various topics, such as creating plans for achieving success or dealing with difficult emotions. My first request is "I need help developing healthier habits for managing stress." General: - Ensure the prompt clearly describes the task - Be as explicit as possible to avoid confusion - Keep prompts concise and to the point - Avoid details that could distract the model - Say what to do, rather than what not to do - Use delimiters to separate instructions from content - Tweak and test different strategies - Avoid repetition - Clean/Adapt the input prompt - e.g., don't repeat any sentence - e.g., less repetitive - Post-process the output to remove duplication/repetition - Limit the likelihood of hallucinations - If you don't know the answer, respond with "?" - Start with zero-shot, then few-shots Failures to avoid: - Considering that the data the model has is up to date - No, there is a cut-off date - Considering that models are unbiased - Considering the models as predictable - Thinking that the models know it all - Thinking that the models are careful about language and cultural nuances - Using vague prompts Reduce latency - Flow of completion - End user to ChatGPT API Latency - Time to process prompt tokens - Model choice impact - Time to generate tokens - Model choice impact - chatgpt API to end user latency - Reduce the number of tokens to generate - Stop sequences: e.g., Recommend X books - Max tokens (API param) - n Parameter (OpenAPI): number of chat completion choices to generate - Stream (OpenAPI): Return tokens as soon as they are available - Reduces the wait time for the first initial tokens - Improves UX ## Claude cookbook tips Claude-specific best practices (from the [[Claude Platform]] cookbook, https://platform.claude.com/cookbook/): - Use XML tags as delimiters (`<instructions>`, `<document>`, `<example>`); Claude is specifically trained to respect them - Front-load the most important instruction at the top of the prompt - Update (November 2026): with long documents (20k+ tokens), the current guide puts the documents at the top and the question at the end (see [[#Put long documents first and the question last]]) - For reliable JSON output, describe the exact schema and prefill the assistant response with `{` (JSON mode via prompting) - Outdated: since the Claude 4.6 models, a prefill on the last assistant turn returns a 400 error. Use structured outputs instead (see [[#Replace prefilled responses]]) - Use prompt caching for long, stable prefixes (system prompts, reference documents); big cost and latency savings on repeated calls - Batch anything asynchronous through the Batches API: 50% cheaper - For grounded answers over documents, use the built-in citations feature rather than "quote your sources" prompt hacks - For hard problems, enable extended thinking and tune the thinking budget rather than resorting to convoluted chain-of-thought prompts - Outdated: `budget_tokens` returns a 400 error on Claude 4.7 and later. Use adaptive thinking and the `effort` parameter (see [[#Thinking and effort]]) - Use the metaprompt technique: have Claude generate and refine the starting prompt for a task - For agents: prefer giving Claude fewer, well-described tools over many overlapping ones, and let subagents do context-heavy exploration (see [[Orchestrator tax]]) ## Image generation For image generation: - Consistency is a challenge - Don't forget you can add - Motion - Emotion - Abstract concepts - Ask ChatGPT to provide help to improve image prompts - Give some bullet points describing how I could change that prompt to make it more emotive. I want the image to resonate with people, and to make them care about ... - Marketing campaign visuals - Help me design image assets for a new product I am launching. The product is a ... I want all the assets to have a consistent theme. They should be simple, stylish, and futuristic - Generate a header image for a social media site that I can use for this campaign - Show the product in use in a ... setting - Give me a background image for a flyer that will be printed out. Leave some space where I can add text at a later date ## References - Anthropic, "Prompting best practices", Claude Platform docs (read 2026-11-10): https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices - Anthropic, "Prompting Claude Fable 5.2": https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-2 - Anthropic, "Prompting Claude Opus 5.5": https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5 - Anthropic, "Prompting Claude Opus 5": https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5 - Anthropic, "Prompting Claude Fable 5.1": https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1 - Anthropic, Effort: https://platform.claude.com/docs/en/build-with-claude/effort - Anthropic, Structured outputs: https://platform.claude.com/docs/en/build-with-claude/structured-outputs - Anthropic, Migration guides: https://platform.claude.com/docs/en/about-claude/models/migration-guide - Claude cookbook: https://platform.claude.com/cookbook/ ## Related - [[Prompt Engineering]] - [[Prompt Engineering Strategies]] - [[Context Engineering]] - [[Chain-of-Thought (CoT) prompting]] - [[Prompt Chaining]] - [[LLM Structured Outputs]] - [[AI Tool Use]] - [[AI Subagents]] - [[AI Hallucination]] - [[Claude Code effort levels]] - [[Claude Fable 5.2]] - [[Claude Opus 5.5]] - [[Claude Platform]] - [[Promptfoo]]