QUICK INFO
| Difficulty | Intermediate |
| Time Required | 25-35 minutes |
| Prerequisites | API access or Claude.ai account, familiarity with LLM basics |
| Tools Needed | Claude API (any Claude 4.x model) or claude.ai |
What You'll Learn:
- How to write explicit instructions that Claude 4.x follows precisely
- Managing multi-context workflows with state tracking
- Controlling output format, verbosity, and tool usage
- Avoiding common pitfalls like overengineering and hallucination
Claude 4.x models follow instructions more literally than previous versions. If you've been using Claude 3.x, some of your prompts will need adjustment. This guide covers the techniques that matter most.
The Core Shift
Claude 4 models are trained for precise instruction following. The "above and beyond" behavior you might have relied on from earlier models now requires explicit requests. This isn't a regression; it's a design choice that gives you more control. But it means being vague gets you vague results.
A prompt like "Create an analytics dashboard" might have produced something elaborate in Claude 3.5. With Opus 4.5 or Sonnet 4.5, you'll get something functional but minimal unless you specify otherwise.
What works better: "Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation."
The pattern holds across most tasks. If you want Claude to elaborate, explore edge cases, or add polish, ask for it.
Writing Instructions That Work
Be Explicit About What You Want
Claude 4.x interprets instructions literally. "Can you suggest some changes to improve this function?" will get you suggestions, not implementations, even if making changes is what you actually wanted.
For action, be direct: "Change this function to improve its performance" or "Make these edits to the authentication flow."
If you want Claude to default to action without asking permission each time, add something like this to your system prompt:
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.
The opposite also works. If you find Claude jumping into implementations when you wanted analysis first:
Do not jump into implementation or change 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.
Add Context When It Matters
Claude 4 models respond well to understanding why an instruction exists. "NEVER use ellipses" works, but "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" works better. The model generalizes from the explanation and handles related edge cases more intelligently.
This isn't always necessary. "Use JSON format" doesn't need justification. But for constraints that might seem arbitrary or for behaviors you want applied flexibly across situations, the reasoning helps.
Long-Running Tasks and State Management
Claude 4.5 models excel at extended tasks that span multiple context windows. Opus 4.5 in particular can work on complex problems, save state, and continue effectively with a fresh context. But you need to structure things appropriately.
Managing Context Limits
Claude 4.5 models track their remaining context window. This is useful, but it can also cause the model to start wrapping up work prematurely as it approaches the limit. If you're using an agent harness that handles context automatically, tell Claude:
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. As you approach your token budget limit, save your current progress and state to memory before the context window refreshes. Always be as persistent and autonomous as possible and complete tasks fully.
State Tracking Across Sessions
For tasks that span multiple context windows, structure matters. A few things I've found work well:
Use JSON for structured state like test results or task lists. Use plain text for progress notes and context. Git works surprisingly well for tracking state across sessions since it provides both history and restore points.
// tests.json
{
"tests": [
{"id": 1, "name": "authentication_flow", "status": "passing"},
{"id": 2, "name": "user_management", "status": "failing"},
{"id": 3, "name": "api_endpoints", "status": "not_started"}
],
"total": 200,
"passing": 150,
"failing": 25,
"not_started": 25
}
// progress.txt
Session 3 progress:
- Fixed authentication token validation
- Updated user model to handle edge cases
- Next: investigate user_management test failures (test #2)
- Note: Do not remove tests as this could lead to missing functionality
Multi-Window Workflow Tips
Use the first context window differently than subsequent ones. Set up your framework in the first window: write tests, create setup scripts, establish the structure. Then use future context windows to iterate through a todo list.
Have Claude write tests in a structured format before starting work. Remind it explicitly that removing or editing tests can mask bugs.
Setup scripts like init.sh save time when continuing from fresh. Without them, Claude spends tokens rediscovering how to start servers, run test suites, etc.
When starting a fresh context after a window is cleared, Claude 4.5 models are effective at discovering state from the filesystem. Sometimes this works better than compaction. Be prescriptive about how it should start: review progress.txt, check git logs, run an integration test before implementing new features.
Controlling Output Format
Claude 4.5 has a more concise communication style than earlier models. It may skip summaries after tool calls, provide terser explanations, and generally optimize for efficiency. This is often good. But if you want more visibility:
After completing a task that involves tool use, provide a quick summary of the work you've done.
Reducing Markdown and Lists
Claude 4.x responds well to formatting instructions, but telling it what to do works better than telling it what not to do.
Instead of "Do not use markdown in your response," try "Your response should be composed of smoothly flowing prose paragraphs."
You can also use XML format indicators: "Write the prose sections of your response in <smoothly_flowing_prose_paragraphs> tags."
For detailed control over markdown usage:
When writing reports, documents, technical explanations, analyses, or any long-form content, write in clear, flowing prose using complete paragraphs and sentences. Use standard paragraph breaks for organization and reserve markdown primarily for inline code, code blocks, and simple headings. Avoid bold and italics.
DO NOT use ordered lists or unordered lists unless: a) you're presenting truly discrete items where a list format is the best option, or b) the user explicitly requests a list or ranking.
Instead of listing items with bullets or numbers, incorporate them naturally into sentences.
The formatting style of your prompt influences Claude's response style. Removing markdown from your prompt reduces markdown in the output.
Tool Usage
Triggering and Overtriggering
Opus 4.5 responds more strongly to system prompt instructions than previous models. If your prompts were designed to push Claude to use tools more aggressively, you may now see overtriggering. "CRITICAL: You MUST use this tool when..." can become "Use this tool when..." without losing effectiveness.
Parallel Tool Calls
Sonnet 4.5 is particularly aggressive about parallel execution. It will run multiple searches during research, read several files simultaneously, and execute bash commands in parallel. This can occasionally bottleneck system performance.
The behavior is steerable. For maximum parallelism:
If you intend to call multiple tools and there are no dependencies between the tool calls, make all of the independent tool calls in parallel. Prioritize calling tools simultaneously whenever the actions can be done in parallel rather than sequentially. For example, when reading 3 files, run 3 tool calls in parallel to read all 3 files into context at the same time. However, if some tool calls depend on previous calls to inform dependent values like the parameters, do NOT call these tools in parallel. Never use placeholders or guess missing parameters in tool calls.
To slow things down: "Execute operations sequentially with brief pauses between each step to ensure stability."
Common Problems and Fixes
Overengineering
Opus 4.5 tends to create extra files, add unnecessary abstractions, and build in flexibility you didn't ask for. A bug fix becomes a refactoring project. A simple feature sprouts configuration options.
Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused.
Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability.
Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. Reuse existing abstractions where possible and follow the DRY principle.
Not Exploring Code Before Proposing Solutions
Claude can be overly conservative about reading code. It might propose solutions based on assumptions rather than actually checking what's there.
ALWAYS read and understand relevant files before proposing code edits. Do not speculate about code you have not inspected. If the user references a specific file/path, you MUST open and inspect it before explaining or proposing fixes. Be rigorous and persistent in searching code for key facts.
Hallucinating About Code
Claude 4.x models hallucinate less than previous versions, but you can push this further:
Never speculate about code you have not opened. If the user references a specific file, you MUST read the file before answering. Make sure to investigate and read relevant files BEFORE answering questions about the codebase. Never make any claims about code before investigating unless you are certain of the correct answer.
Focusing on Passing Tests Rather Than General Solutions
Sometimes Claude optimizes for making tests pass rather than solving the underlying problem correctly. It might hardcode values or create solutions that only work for specific test inputs.
Please write a high-quality, general-purpose solution using the standard tools available. Do not create helper scripts or workarounds. Implement a solution that works correctly for all valid inputs, not just the test cases. Do not hard-code values or create solutions that only work for specific test inputs.
Focus on understanding the problem requirements and implementing the correct algorithm. Tests are there to verify correctness, not to define the solution.
If any of the tests are incorrect, please inform me rather than working around them.
Temporary File Cleanup
Claude 4.x may create temporary files for testing and iteration. Sometimes this is useful, sometimes it clutters your project.
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.
Research Tasks
Claude 4.5 models handle multi-source research well. For complex research, structure helps:
Search for this information in a structured way. As you gather data, develop several competing hypotheses. Track your confidence levels in your progress notes to improve calibration. Regularly self-critique your approach and plan. Update a hypothesis tree or research notes file to persist information. Break down this complex research task systematically.
Frontend Design
Without guidance, Claude defaults to generic patterns that create what some call the "AI slop" aesthetic. To get more distinctive results:
You tend to converge toward generic outputs. In frontend design, this creates what users call the "AI slop" aesthetic. Avoid this: make creative, distinctive frontends that surprise and delight.
Focus on typography with distinctive font choices rather than Inter, Arial, or Roboto. Use cohesive color themes with dominant colors and sharp accents rather than evenly-distributed palettes. Use animations for micro-interactions. Create atmosphere with layered gradients and patterns rather than solid backgrounds.
Avoid purple gradients on white backgrounds, predictable layouts, cookie-cutter design. Think outside the box.
Extended Thinking
When extended thinking is disabled, Opus 4.5 is sensitive to the word "think" and variants. Replace "think" with "consider," "believe," or "evaluate" to avoid triggering unintended behavior.
When extended thinking is enabled, you can guide Claude's reasoning after tool use:
After receiving tool results, carefully reflect on their quality and determine optimal next steps before proceeding. Use your thinking to plan and iterate based on this new information, and then take the best next action.
Model Identity
If you need Claude to identify itself correctly or use specific API strings in an application:
The assistant is Claude, created by Anthropic. The current model is Claude Sonnet 4.5.
For applications that need model strings:
When an LLM is needed, please default to Claude Sonnet 4.5 unless the user requests otherwise. The exact model string for Claude Sonnet 4.5 is claude-sonnet-4-5-20250929.
What's Next
The techniques here cover most common scenarios. For vision tasks specifically, Anthropic has a crop tool cookbook that shows consistent uplift on image evaluations when Claude can zoom into relevant regions. For extended thinking workflows, the memory tool documentation covers seamless context transitions.
PRO TIPS
The shift to Opus 4.5 from earlier models sometimes means dialing back aggressive prompting. Where you might have written "CRITICAL: You MUST use this tool when X happens," you can now write "Use this tool when X happens" and get the same behavior without overtriggering.
XML tags still work well for organizing complex system prompts. <avoid_excessive_markdown>, <default_to_action>, etc. help Claude parse instruction categories.
For subagent orchestration, Claude 4.5 models recognize when delegation would help and do it proactively. You don't need to prompt for this explicitly. If you want to dial it back: "Only delegate to subagents when the task clearly benefits from a separate agent with a new context window."
Vision capabilities improved in Opus 4.5. For image-heavy tasks, giving Claude access to a crop tool lets it zoom into relevant regions and boosts accuracy measurably.
FAQ
Q: My prompts worked fine with Claude 3.5 but now get minimal results. What changed? A: Claude 4.x follows instructions more literally. "Above and beyond" behavior now requires explicit requests. Add modifiers like "Include as many relevant features as possible" or "Go beyond the basics to create a fully-featured implementation."
Q: Claude keeps suggesting changes instead of making them. How do I fix this? A: Use imperative language. "Change this function" instead of "Can you suggest changes?" Or add to your system prompt: "By default, implement changes rather than only suggesting them."
Q: How do I get Claude to use less markdown formatting?
A: Tell it what to do, not what to avoid. "Write in flowing prose paragraphs" works better than "Don't use markdown." XML tags like <smoothly_flowing_prose_paragraphs> also help.
Q: Parallel tool calls are bottlenecking my system. Can I slow Claude down? A: Add "Execute operations sequentially with brief pauses between each step to ensure stability" to your prompt.
Q: Claude is creating way more files and abstractions than I asked for. A: Opus 4.5 tends to overengineer. Add explicit instructions: "Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused."
RESOURCES
- Official Claude 4.5 prompting docs: Anthropic's complete reference
- What's new in Claude 4.5: Overview of new capabilities
- Extended thinking guide: Deep dive on thinking capabilities
- Crop tool cookbook: Vision task optimization
