| name | prompting |
| description | PROACTIVE: This skill SHOULD BE USED AUTOMATICALLY when writing prompts, system prompts, crafting instructions for LLMs, or optimizing AI interactions. Triggers on: write prompt, system prompt, prompt engineering, optimize prompt, better prompt, prompt template, instruction design, context engineering, SKILL.md description, agent instructions. Use for CRAFTING LLM PROMPTS. Based on official Anthropic documentation for Claude Sonnet 4.5 and Opus 4.5. |
Claude 4.5 Prompting Best Practices
Based on official Anthropic documentation. For detailed patterns: references/anthropic_4_5_prompting_techniques.md
Quick Checklist
[ ] Explicit: Request behavior explicitly ("go beyond basics", "be thorough")
[ ] WHY: Explain motivation behind constraints (Claude generalizes from explanation)
[ ] Action: "Make changes" vs "Suggest changes" (literal interpretation)
[ ] Positive: "Write in prose" vs "Don't use bullets"
[ ] Structure: XML tags (<task>, <context>, <output_format>)
[ ] Examples: Must align with desired behavior (Claude pays close attention)
[ ] Tool triggering: Dial back aggressive language for 4.5 ("Use when..." not "MUST use")
Core Principles
1. Be Explicit
Claude 4.5 does exactly what asked. Request "above and beyond" explicitly:
# Less effective
Create an analytics dashboard
# More effective
Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation.
2. Provide WHY
Explaining motivation helps Claude generalize:
# Less effective
NEVER use ellipses
# More effective
Your response will be read aloud by TTS, so never use ellipses since TTS can't pronounce them.
3. Action vs Suggestion
"Suggest" = suggest only. "Make" = implement:
# Will ONLY suggest
Can you suggest some changes?
# Will implement
Change this function to improve performance.
Model-Specific Notes
Sonnet 4.5
- Aggressive parallel tool calling
- May overtrigger tools - dial back aggressive prompts
- Significantly better with extended thinking enabled for coding
- 0% error rate on code editing benchmarks
Opus 4.5
- More conservative (thinks before acting)
- Sensitive to "think" word when extended thinking disabled → use "consider", "evaluate"
- Tends to overengineer - add explicit constraints
- Preserves all thinking blocks throughout conversation
Key Prompt Snippets
Default to Action
<default_to_action>
By default, implement changes rather than only suggesting them. If intent is unclear, infer the most useful action and proceed, using tools to discover missing details.
</default_to_action>
Parallel Tool Calls
<use_parallel_tool_calls>
If calling multiple tools with no dependencies, make all independent calls in parallel. If some depend on previous results, call sequentially. Never guess parameters.
</use_parallel_tool_calls>
Minimize Overengineering (Opus 4.5)
Avoid over-engineering. Only make changes directly requested or clearly necessary.
Don't add features or "improvements" beyond what was asked. Don't add error handling for impossible scenarios. Don't create abstractions for one-time operations.
Code Exploration
<investigate_before_answering>
ALWAYS read relevant files before proposing edits. Do not speculate about code you haven't inspected. If user references a file, you MUST open it first.
</investigate_before_answering>
Format Control
<avoid_excessive_markdown>
Write in clear, flowing prose. Reserve markdown for `inline code`, code blocks, and simple headings. Avoid **bold**, *italics*, and bullet lists unless truly discrete items.
</avoid_excessive_markdown>
Context Management
Your context window will be automatically compacted. Do not stop tasks early due to token concerns. Save progress to memory before context refreshes. Be persistent and autonomous.
Extended Thinking
Enable for: Complex reasoning, multi-step coding, deep analysis, math
Avoid for: Simple queries (can hurt by 36%), low-latency needs
thinking={"type": "enabled", "budget_tokens": 10000}
Interleaved thinking (beta): Enables thinking between tool calls
Header: anthropic-beta: interleaved-thinking-2025-05-14
System Prompt Structure
1. Task context (role/persona, broad task)
2. Tone context
3. Background data
4. Detailed rules and constraints
Key insight: Put most instructions in human prompts. System message for high-level scene setting and tool definitions.
State Management (Long Tasks)
- Git for state tracking (Claude 4.5 performs well with git)
- JSON for structured data (test status, task progress)
- progress.txt for freeform notes
- Commit with descriptive messages after changes
Editing Long Prompts (300+ lines)
CRITICAL: Never ask questions. Autonomous teams must work without interruption.
When asked to update/review a long prompt:
- Surgical edits only: Change specific sections, preserve everything else
- Never compress or shorten: Long prompts contain accumulated edge cases - condensing loses them
- Never summarize: Even if it seems verbose, keep full length
- Refactor duplication: Remove duplicated content by consolidating or cross-referencing, but keep all unique information
- If unclear what to fix: Make best judgment based on context, proceed without asking
Reference
Full documentation: references/anthropic_4_5_prompting_techniques.md
