Initial commit
This commit is contained in:
Zhongwei Li
@@ -0,0 +1,283 @@
|
||||
# Advanced Prompt Engineering Techniques
|
||||
|
||||
Advanced techniques for optimizing Claude prompts for complex use cases.
|
||||
|
||||
## Few-Shot Prompting (Learning from Examples)
|
||||
|
||||
**What it is:** Provide examples of inputs and desired outputs to teach Claude the pattern
|
||||
|
||||
**Why it works:** Claude learns from examples better than from abstract instructions alone
|
||||
|
||||
**When to use:**
|
||||
- Complex output formats
|
||||
- Specific writing styles
|
||||
- Pattern recognition tasks
|
||||
- Consistent formatting needs
|
||||
|
||||
**Best practices:**
|
||||
- Use 2-5 diverse examples
|
||||
- Include edge cases
|
||||
- Ensure examples are accurate
|
||||
- Use XML tags to structure examples
|
||||
|
||||
**Example:**
|
||||
```xml
|
||||
<instructions>
|
||||
Extract product information in the specified format.
|
||||
</instructions>
|
||||
|
||||
<examples>
|
||||
<example>
|
||||
<input>iPhone 15 Pro - $999 - 128GB storage, titanium finish</input>
|
||||
<output>
|
||||
Product: iPhone 15 Pro
|
||||
Price: $999
|
||||
Features: 128GB storage, titanium finish
|
||||
</output>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<input>MacBook Air M2 chip starting at $1,199</input>
|
||||
<output>
|
||||
Product: MacBook Air M2
|
||||
Price: $1,199
|
||||
Features: M2 chip
|
||||
</output>
|
||||
</example>
|
||||
</examples>
|
||||
|
||||
<input>
|
||||
[new product description]
|
||||
</input>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Role Prompting
|
||||
|
||||
**What it is:** Assign Claude a specific role or persona to guide its responses
|
||||
|
||||
**Why it works:** Provides context for appropriate tone, knowledge level, and approach
|
||||
|
||||
**When to use:**
|
||||
- Domain-specific tasks
|
||||
- Specific communication styles
|
||||
- Educational content
|
||||
- Professional contexts
|
||||
|
||||
**Examples:**
|
||||
|
||||
```
|
||||
You are a senior Python developer with 10 years of experience.
|
||||
Review this code and provide feedback as you would to a junior developer.
|
||||
Focus on best practices, performance, and maintainability.
|
||||
|
||||
<code>
|
||||
[code here]
|
||||
</code>
|
||||
```
|
||||
|
||||
```
|
||||
You are a patient elementary school math teacher.
|
||||
Explain fractions to a 7-year-old using simple language and fun examples.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Context Engineering
|
||||
|
||||
**What it is:** Carefully managing what information goes into the prompt
|
||||
|
||||
**Why it works:** LLMs have finite attention - every token counts
|
||||
|
||||
**Key principles:**
|
||||
- Treat context as a finite resource
|
||||
- Use "just-in-time" data loading
|
||||
- Progressive disclosure over dump-all
|
||||
- Prioritize signal over noise
|
||||
|
||||
**Best practices:**
|
||||
- Start minimal, add based on failures
|
||||
- Use structural organization (XML/Markdown headers)
|
||||
- Remove redundant information
|
||||
- Find the right altitude (specific but flexible)
|
||||
|
||||
**Example - Bad:**
|
||||
```
|
||||
[Dumps entire 10-page documentation]
|
||||
|
||||
Answer this specific question about one feature.
|
||||
```
|
||||
|
||||
**Example - Good:**
|
||||
```xml
|
||||
<instructions>
|
||||
Answer the user's question using only the relevant documentation below.
|
||||
</instructions>
|
||||
|
||||
<relevant_docs>
|
||||
[Only the 2 paragraphs about the specific feature]
|
||||
</relevant_docs>
|
||||
|
||||
<question>
|
||||
How do I configure feature X?
|
||||
</question>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Long-Form Task Prompting
|
||||
|
||||
**What it is:** Breaking complex tasks into clear steps
|
||||
|
||||
**Why it works:** Reduces ambiguity and improves consistency
|
||||
|
||||
**When to use:**
|
||||
- Multi-step processes
|
||||
- Complex analysis tasks
|
||||
- Content generation workflows
|
||||
- Production systems
|
||||
|
||||
**Example:**
|
||||
```xml
|
||||
<task>
|
||||
Generate a comprehensive blog post about topic X.
|
||||
</task>
|
||||
|
||||
<steps>
|
||||
1. Research: Identify 3 key points about the topic
|
||||
2. Structure: Create an outline with introduction, 3 main sections, conclusion
|
||||
3. Write: Develop each section with examples and data
|
||||
4. Optimize: Add SEO-friendly headers and meta description
|
||||
5. Review: Check for accuracy, clarity, and completeness
|
||||
</steps>
|
||||
|
||||
<requirements>
|
||||
- Length: 1500-2000 words
|
||||
- Tone: Professional but approachable
|
||||
- Include: Statistics, examples, actionable takeaways
|
||||
- Audience: Intermediate practitioners
|
||||
</requirements>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Prompt Chaining
|
||||
|
||||
**What it is:** Breaking a complex task into a sequence of simpler prompts
|
||||
|
||||
**Why it works:** Each step focuses on one thing, improving quality
|
||||
|
||||
**When to use:**
|
||||
- Very complex tasks
|
||||
- When intermediate verification is needed
|
||||
- Multi-stage processing
|
||||
- Quality-critical applications
|
||||
|
||||
**Example workflow:**
|
||||
1. **Analysis prompt:** "Extract key themes from this document"
|
||||
2. **Synthesis prompt:** "Using these themes, create an outline"
|
||||
3. **Generation prompt:** "Using this outline, write the full content"
|
||||
4. **Review prompt:** "Review and improve this content"
|
||||
|
||||
---
|
||||
|
||||
## Output Control Techniques
|
||||
|
||||
### Controlling Length
|
||||
|
||||
**Specify exact targets:**
|
||||
```
|
||||
Write a 250-word summary (aim for 240-260 words)
|
||||
```
|
||||
|
||||
**Use structural limits:**
|
||||
```
|
||||
Summarize in exactly 3 bullet points, each 1-2 sentences
|
||||
```
|
||||
|
||||
### Controlling Format
|
||||
|
||||
**Use prefilling:**
|
||||
```
|
||||
Assistant: {
|
||||
"status":
|
||||
```
|
||||
|
||||
**Specify structure:**
|
||||
```xml
|
||||
<output_format>
|
||||
Return markdown with:
|
||||
## Summary
|
||||
[2-3 sentences]
|
||||
|
||||
## Key Points
|
||||
- [point 1]
|
||||
- [point 2]
|
||||
- [point 3]
|
||||
|
||||
## Recommendation
|
||||
[1 paragraph]
|
||||
</output_format>
|
||||
```
|
||||
|
||||
### Controlling Tone
|
||||
|
||||
**Be specific:**
|
||||
```
|
||||
Tone: Technical but accessible
|
||||
- Use industry terminology
|
||||
- Explain complex concepts simply
|
||||
- Professional yet conversational
|
||||
- Avoid jargon where possible
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Meta-Prompting
|
||||
|
||||
**What it is:** Having Claude help improve or generate prompts
|
||||
|
||||
**Use cases:**
|
||||
- Generating prompt variations
|
||||
- Improving existing prompts
|
||||
- Creating test cases
|
||||
- Prompt optimization
|
||||
|
||||
**Example:**
|
||||
```
|
||||
I want to create a prompt that extracts structured data from resumes.
|
||||
|
||||
Help me design an effective prompt that:
|
||||
1. Uses XML tags for structure
|
||||
2. Includes 2 examples
|
||||
3. Specifies exact JSON output format
|
||||
4. Handles edge cases (missing information)
|
||||
|
||||
Show me the complete prompt.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Testing and Iteration
|
||||
|
||||
**Empirical approach:**
|
||||
1. Start with a baseline prompt
|
||||
2. Test with diverse inputs
|
||||
3. Identify failure modes
|
||||
4. Add examples or constraints
|
||||
5. Re-test and measure improvement
|
||||
6. Iterate until quality threshold met
|
||||
|
||||
**Key metrics:**
|
||||
- Accuracy on test cases
|
||||
- Consistency across runs
|
||||
- Edge case handling
|
||||
- Token efficiency
|
||||
- Response time
|
||||
|
||||
**Best practice:** Test-driven prompt development
|
||||
- Create evaluation dataset first
|
||||
- Define success criteria
|
||||
- Iterate systematically
|
||||
- Measure objectively
|
||||
@@ -0,0 +1,322 @@
|
||||
# Claude 4.x Best Practices
|
||||
|
||||
Specific best practices for Claude 4.x models (Opus 4, Sonnet 4.5, Haiku 4).
|
||||
|
||||
## What's Different in Claude 4.x
|
||||
|
||||
Claude 4.x models have been trained for **more precise instruction following** than previous generations.
|
||||
|
||||
**Key improvements:**
|
||||
- Better adherence to explicit instructions
|
||||
- Enhanced attention to details and examples
|
||||
- Improved thinking capabilities for complex reasoning
|
||||
- More consistent output formatting
|
||||
- Better handling of structured data
|
||||
|
||||
---
|
||||
|
||||
## Best Practice 1: Be Explicitly Clear
|
||||
|
||||
Claude 4.x responds especially well to clear, explicit instructions.
|
||||
|
||||
**Do this:**
|
||||
```
|
||||
Write a Python function that validates email addresses.
|
||||
|
||||
Requirements:
|
||||
- Function name: validate_email
|
||||
- Input: string
|
||||
- Output: boolean
|
||||
- Use regex for validation
|
||||
- Support international domains
|
||||
- Include docstring with examples
|
||||
```
|
||||
|
||||
**Not this:**
|
||||
```
|
||||
Make an email validator in Python
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practice 2: Provide Context and Motivation
|
||||
|
||||
Explaining *why* helps Claude 4.x understand goals and deliver targeted responses.
|
||||
|
||||
**Good:**
|
||||
```
|
||||
I'm building a user registration system for a SaaS application.
|
||||
I need to validate email addresses to ensure users provide legitimate contact info.
|
||||
|
||||
Write a robust email validation function in Python that:
|
||||
[requirements]
|
||||
```
|
||||
|
||||
**Better understanding** → **Better results**
|
||||
|
||||
---
|
||||
|
||||
## Best Practice 3: Ensure Examples Align
|
||||
|
||||
Claude 4.x pays close attention to examples as part of instruction following.
|
||||
|
||||
**Critical:** Examples must perfectly match desired behavior
|
||||
|
||||
❌ **Misaligned example:**
|
||||
```xml
|
||||
<instructions>
|
||||
Extract dates in ISO format (YYYY-MM-DD)
|
||||
</instructions>
|
||||
|
||||
<example>
|
||||
Input: "Meeting on January 5th, 2024"
|
||||
Output: 01/05/2024 <!-- Wrong format! -->
|
||||
</example>
|
||||
```
|
||||
|
||||
✅ **Aligned example:**
|
||||
```xml
|
||||
<instructions>
|
||||
Extract dates in ISO format (YYYY-MM-DD)
|
||||
</instructions>
|
||||
|
||||
<example>
|
||||
Input: "Meeting on January 5th, 2024"
|
||||
Output: 2024-01-05
|
||||
</example>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practice 4: Leverage Thinking Capabilities
|
||||
|
||||
Claude 4.x has enhanced thinking capabilities for complex tasks.
|
||||
|
||||
**Use thinking for:**
|
||||
- Multi-step reasoning
|
||||
- Complex analysis
|
||||
- Problem-solving
|
||||
- Reflection after tool use
|
||||
|
||||
**Example:**
|
||||
```xml
|
||||
<task>
|
||||
Analyze this codebase architecture and suggest improvements.
|
||||
</task>
|
||||
|
||||
<instructions>
|
||||
First, think through the analysis in <thinking> tags:
|
||||
1. What patterns are being used?
|
||||
2. What are the strengths?
|
||||
3. What are the weaknesses?
|
||||
4. What improvements would have the most impact?
|
||||
|
||||
Then provide your recommendations.
|
||||
</instructions>
|
||||
|
||||
<codebase>
|
||||
[code here]
|
||||
</codebase>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practice 5: Guide Initial Thinking
|
||||
|
||||
You can guide Claude's thinking process for better results.
|
||||
|
||||
**Example:**
|
||||
```
|
||||
Solve this algorithm problem. Before coding, think through:
|
||||
|
||||
<thinking_guide>
|
||||
1. What is the core problem?
|
||||
2. What data structures would be efficient?
|
||||
3. What's the time complexity target?
|
||||
4. Are there edge cases to consider?
|
||||
</thinking_guide>
|
||||
|
||||
Then implement the solution.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practice 6: Use Structured Prompts
|
||||
|
||||
Claude 4.x excels with well-organized prompts.
|
||||
|
||||
**Template:**
|
||||
```xml
|
||||
<role>
|
||||
You are a senior software engineer reviewing code.
|
||||
</role>
|
||||
|
||||
<task>
|
||||
Review the following pull request for security vulnerabilities.
|
||||
</task>
|
||||
|
||||
<code>
|
||||
[code here]
|
||||
</code>
|
||||
|
||||
<focus_areas>
|
||||
- SQL injection risks
|
||||
- XSS vulnerabilities
|
||||
- Authentication issues
|
||||
- Input validation
|
||||
</focus_areas>
|
||||
|
||||
<output_format>
|
||||
For each issue found:
|
||||
1. Severity: Critical/High/Medium/Low
|
||||
2. Location: File and line number
|
||||
3. Description: What's wrong
|
||||
4. Recommendation: How to fix
|
||||
</output_format>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practice 7: Specify Precision Level
|
||||
|
||||
Claude 4.x can adjust precision based on your needs.
|
||||
|
||||
**For high accuracy:**
|
||||
```
|
||||
Analyze this data with high precision. Double-check all calculations.
|
||||
If uncertain about anything, state your confidence level.
|
||||
```
|
||||
|
||||
**For creative tasks:**
|
||||
```
|
||||
Generate creative marketing slogans. Prioritize originality and impact.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practice 8: Test and Iterate
|
||||
|
||||
Claude 4.x's consistency makes testing more reliable.
|
||||
|
||||
**Recommended approach:**
|
||||
1. Create test cases covering:
|
||||
- Happy path
|
||||
- Edge cases
|
||||
- Error conditions
|
||||
- Boundary values
|
||||
|
||||
2. Run prompt against all test cases
|
||||
|
||||
3. Identify patterns in failures
|
||||
|
||||
4. Refine prompt based on failures
|
||||
|
||||
5. Repeat until quality threshold met
|
||||
|
||||
---
|
||||
|
||||
## Model Selection Guide
|
||||
|
||||
Choose the right Claude 4.x model for your use case:
|
||||
|
||||
### Opus 4
|
||||
**Best for:**
|
||||
- Highest accuracy requirements
|
||||
- Complex reasoning tasks
|
||||
- Mission-critical applications
|
||||
- Creative writing
|
||||
- In-depth analysis
|
||||
|
||||
**Example use cases:**
|
||||
- Legal document analysis
|
||||
- Complex code generation
|
||||
- Research synthesis
|
||||
- Strategic planning
|
||||
|
||||
### Sonnet 4.5
|
||||
**Best for:**
|
||||
- Balance of performance and cost
|
||||
- Most production applications
|
||||
- Real-time interactions
|
||||
- General-purpose tasks
|
||||
|
||||
**Example use cases:**
|
||||
- Chatbots
|
||||
- Content generation
|
||||
- Code review
|
||||
- Data extraction
|
||||
|
||||
### Haiku 4
|
||||
**Best for:**
|
||||
- Speed-critical applications
|
||||
- High-volume processing
|
||||
- Simpler tasks
|
||||
- Cost optimization
|
||||
|
||||
**Example use cases:**
|
||||
- Classification
|
||||
- Simple extraction
|
||||
- Quick summaries
|
||||
- Moderation
|
||||
|
||||
---
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Token Efficiency
|
||||
|
||||
**Minimize unnecessary tokens:**
|
||||
```xml
|
||||
<!-- Inefficient -->
|
||||
<instructions>
|
||||
I would like you to please analyze the following text
|
||||
and then extract any email addresses that you find
|
||||
in the text and return them to me in a list format.
|
||||
</instructions>
|
||||
|
||||
<!-- Efficient -->
|
||||
<instructions>
|
||||
Extract all email addresses from the text below.
|
||||
Return as a JSON array.
|
||||
</instructions>
|
||||
```
|
||||
|
||||
### Batching
|
||||
|
||||
**For multiple similar tasks:**
|
||||
```xml
|
||||
<instructions>
|
||||
Classify each review as positive/negative/neutral.
|
||||
</instructions>
|
||||
|
||||
<reviews>
|
||||
<review id="1">[text]</review>
|
||||
<review id="2">[text]</review>
|
||||
<review id="3">[text]</review>
|
||||
</reviews>
|
||||
|
||||
<output_format>
|
||||
[
|
||||
{"id": "1", "sentiment": "positive"},
|
||||
{"id": "2", "sentiment": "negative"},
|
||||
...
|
||||
]
|
||||
</output_format>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Production Readiness Checklist
|
||||
|
||||
Before deploying prompts in production:
|
||||
|
||||
- [ ] Tested on diverse inputs
|
||||
- [ ] Edge cases handled
|
||||
- [ ] Output format strictly controlled
|
||||
- [ ] Examples align with instructions
|
||||
- [ ] Context minimized to essentials
|
||||
- [ ] Error handling specified
|
||||
- [ ] Token usage optimized
|
||||
- [ ] Model version specified
|
||||
- [ ] Success metrics defined
|
||||
- [ ] Fallback behavior defined
|
||||
159
skills/anthropic-prompt-engineer/references/common_mistakes.md
Normal file
159
skills/anthropic-prompt-engineer/references/common_mistakes.md
Normal file
@@ -0,0 +1,159 @@
|
||||
# Common Prompt Engineering Mistakes
|
||||
|
||||
Learn from these common pitfalls to create better prompts.
|
||||
|
||||
## Mistake 1: Being Too Vague
|
||||
|
||||
❌ **Problem:**
|
||||
```
|
||||
Write something about AI
|
||||
```
|
||||
|
||||
**Why it fails:**
|
||||
- No clear scope or direction
|
||||
- Undefined output format
|
||||
- Unknown target audience
|
||||
- No length specification
|
||||
|
||||
✅ **Solution:**
|
||||
```
|
||||
Write a 500-word introduction to large language models for software developers.
|
||||
|
||||
Include:
|
||||
- What LLMs are and how they work (high-level)
|
||||
- 3 practical use cases in software development
|
||||
- 1 code example of API usage
|
||||
- Limitations to be aware of
|
||||
|
||||
Tone: Technical but accessible
|
||||
Format: Markdown with headers
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Mistake 2: Instruction Confusion
|
||||
|
||||
❌ **Problem:**
|
||||
```
|
||||
Here is some text about Python. It talks about lists and dictionaries.
|
||||
Can you make it better and also add examples? Use clear language.
|
||||
```
|
||||
|
||||
**Why it fails:**
|
||||
- Instructions mixed with content
|
||||
- Unclear what "better" means
|
||||
- No structural separation
|
||||
|
||||
✅ **Solution:**
|
||||
```xml
|
||||
<instructions>
|
||||
Improve the following text by:
|
||||
1. Adding 2 code examples (one for lists, one for dictionaries)
|
||||
2. Simplifying complex sentences
|
||||
3. Adding subheadings for each topic
|
||||
</instructions>
|
||||
|
||||
<text_to_improve>
|
||||
[original text here]
|
||||
</text_to_improve>
|
||||
|
||||
<target_audience>
|
||||
Beginner Python developers
|
||||
</target_audience>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Mistake 3: No Examples (When Needed)
|
||||
|
||||
❌ **Problem:**
|
||||
```
|
||||
Extract entities from customer support tickets in a structured format.
|
||||
```
|
||||
|
||||
**Why it fails:**
|
||||
- "Structured format" is ambiguous
|
||||
- No clarity on what entities matter
|
||||
- Different interpretations possible
|
||||
|
||||
✅ **Solution:**
|
||||
```xml
|
||||
<instructions>
|
||||
Extract entities from customer support tickets.
|
||||
</instructions>
|
||||
|
||||
<examples>
|
||||
<example>
|
||||
<input>
|
||||
My order #12345 never arrived. I contacted support@example.com but no response.
|
||||
</input>
|
||||
<output>
|
||||
{
|
||||
"order_id": "12345",
|
||||
"issue_type": "delivery",
|
||||
"contact_method": "email",
|
||||
"email": "support@example.com"
|
||||
}
|
||||
</output>
|
||||
</example>
|
||||
</examples>
|
||||
|
||||
<input>
|
||||
[new ticket]
|
||||
</input>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Mistake 4: Prompt Too Long
|
||||
|
||||
❌ **Problem:**
|
||||
```
|
||||
[5000 words of background information]
|
||||
[500 words of instructions]
|
||||
[1000 words of examples]
|
||||
|
||||
Now answer this simple question: What is the capital of France?
|
||||
```
|
||||
|
||||
**Why it fails:**
|
||||
- Wastes tokens on irrelevant context
|
||||
- Dilutes important information
|
||||
- Slower and more expensive
|
||||
- May confuse the model
|
||||
|
||||
✅ **Solution:**
|
||||
```
|
||||
What is the capital of France?
|
||||
```
|
||||
|
||||
**Principle:** Use minimum necessary context
|
||||
|
||||
---
|
||||
|
||||
## Mistake 5: Not Controlling Output Format
|
||||
|
||||
❌ **Problem:**
|
||||
```
|
||||
Give me the user's information from this text.
|
||||
```
|
||||
|
||||
**Result:** Unpredictable format - might be prose, bullet points, or inconsistent structure
|
||||
|
||||
✅ **Solution:**
|
||||
```xml
|
||||
<instructions>
|
||||
Extract user information and return as JSON.
|
||||
</instructions>
|
||||
|
||||
<input>
|
||||
[text here]
|
||||
</input>
|
||||
|
||||
<output_format>
|
||||
{
|
||||
"name": string,
|
||||
"email": string | null,
|
||||
"phone": string | null
|
||||
}
|
||||
</output_format>
|
||||
147
skills/anthropic-prompt-engineer/references/core_techniques.md
Normal file
147
skills/anthropic-prompt-engineer/references/core_techniques.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# Core Prompt Engineering Techniques
|
||||
|
||||
Anthropic's official prompt engineering techniques for Claude AI models.
|
||||
|
||||
## 1. Be Clear and Direct
|
||||
|
||||
**What it is:** Provide explicit, unambiguous instructions
|
||||
|
||||
**Why it works:** Claude 4.x models are trained for precise instruction following
|
||||
|
||||
**When to use:**
|
||||
- Any prompt where clarity matters
|
||||
- Production systems requiring consistent output
|
||||
- Complex tasks with specific requirements
|
||||
|
||||
**How to apply:**
|
||||
- State exactly what you want
|
||||
- Specify format, length, and tone
|
||||
- Avoid vague or ambiguous language
|
||||
- Include specific constraints and requirements
|
||||
|
||||
**Examples:**
|
||||
|
||||
❌ **Bad:**
|
||||
```
|
||||
Tell me about Python
|
||||
```
|
||||
|
||||
✅ **Good:**
|
||||
```
|
||||
Write a 300-word explanation of Python's list comprehensions for intermediate developers.
|
||||
Include:
|
||||
- 3 practical examples
|
||||
- Performance considerations
|
||||
- Common pitfalls to avoid
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Use XML Tags for Structure
|
||||
|
||||
**What it is:** Organize prompts with XML tags like `<instructions>`, `<example>`, `<context>`
|
||||
|
||||
**Why it works:** Claude was trained with XML tags, naturally recognizing them as structural elements
|
||||
|
||||
**When to use:**
|
||||
- Separating data from instructions
|
||||
- Complex prompts with multiple sections
|
||||
- When working with variable content
|
||||
- Production systems requiring clear boundaries
|
||||
|
||||
**Common tags:**
|
||||
- `<instructions>` - Main task description
|
||||
- `<example>` - Few-shot examples
|
||||
- `<context>` - Background information
|
||||
- `<document>` - Input data to process
|
||||
- `<output_format>` - Expected result format
|
||||
- `<constraints>` - Limitations and rules
|
||||
|
||||
**Example:**
|
||||
```xml
|
||||
<instructions>
|
||||
Analyze the customer review below and extract structured sentiment data.
|
||||
</instructions>
|
||||
|
||||
<review>
|
||||
The product arrived damaged and customer service was unhelpful.
|
||||
</review>
|
||||
|
||||
<output_format>
|
||||
Return JSON with:
|
||||
- "sentiment": "positive" | "negative" | "neutral"
|
||||
- "confidence": 0.0 to 1.0
|
||||
- "key_issues": array of strings
|
||||
</output_format>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Chain of Thought (CoT)
|
||||
|
||||
**What it is:** Ask Claude to think step-by-step before providing final answer
|
||||
|
||||
**Why it works:** Breaking down problems leads to more accurate, nuanced, and reliable responses
|
||||
|
||||
**When to use:**
|
||||
- Math and logical reasoning problems
|
||||
- Complex analysis tasks
|
||||
- Multi-step processes
|
||||
- When accuracy is critical
|
||||
- Debugging and troubleshooting
|
||||
|
||||
**How to apply:**
|
||||
- Add "Think step by step" to your prompt
|
||||
- Request reasoning in `<thinking>` tags
|
||||
- Ask Claude to show its work
|
||||
- Guide the thinking process with specific steps
|
||||
|
||||
**Examples:**
|
||||
|
||||
**Basic CoT:**
|
||||
```
|
||||
Solve this problem step by step:
|
||||
|
||||
<problem>
|
||||
A store sells apples for $2 each. If you buy 5 or more, you get 20% off.
|
||||
How much do 7 apples cost?
|
||||
</problem>
|
||||
|
||||
Think through this step by step, showing your work.
|
||||
```
|
||||
|
||||
**Structured thinking:**
|
||||
```
|
||||
Analyze this code for bugs. Use the following process:
|
||||
|
||||
<thinking>
|
||||
1. Read and understand the code structure
|
||||
2. Identify potential issues
|
||||
3. Assess severity of each issue
|
||||
4. Recommend fixes
|
||||
</thinking>
|
||||
|
||||
<code>
|
||||
[code here]
|
||||
</code>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Prefilling Claude's Response
|
||||
|
||||
**What it is:** Provide the beginning of Claude's response to guide output format and style
|
||||
|
||||
**Why it works:** Immediately directs the response in the desired direction
|
||||
|
||||
**When to use:**
|
||||
- Forcing specific output formats (especially JSON)
|
||||
- Controlling tone and style
|
||||
- Ensuring responses start correctly
|
||||
- Avoiding preambles
|
||||
|
||||
**Examples:**
|
||||
|
||||
**JSON output:**
|
||||
```
|
||||
User: Extract the name, email, and phone from this text: [text]
|
||||
376
skills/anthropic-prompt-engineer/references/prompt_templates.md
Normal file
376
skills/anthropic-prompt-engineer/references/prompt_templates.md
Normal file
@@ -0,0 +1,376 @@
|
||||
# Prompt Templates
|
||||
|
||||
Ready-to-use prompt templates for common tasks.
|
||||
|
||||
## Template 1: Data Extraction
|
||||
|
||||
```xml
|
||||
<role>
|
||||
You are a data extraction specialist.
|
||||
</role>
|
||||
|
||||
<instructions>
|
||||
Extract structured information from the text below.
|
||||
</instructions>
|
||||
|
||||
<text>
|
||||
{{INPUT_TEXT}}
|
||||
</text>
|
||||
|
||||
<schema>
|
||||
{
|
||||
"field1": "type",
|
||||
"field2": "type",
|
||||
"field3": "type"
|
||||
}
|
||||
</schema>
|
||||
|
||||
<rules>
|
||||
- If information is missing, use null
|
||||
- Preserve exact values (don't paraphrase)
|
||||
- Validate data types match schema
|
||||
</rules>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 2: Code Review
|
||||
|
||||
```xml
|
||||
<role>
|
||||
You are a {{LANGUAGE}} expert with {{YEARS}} years of experience.
|
||||
</role>
|
||||
|
||||
<task>
|
||||
Review the following code for:
|
||||
1. Bugs and errors
|
||||
2. Performance issues
|
||||
3. Security vulnerabilities
|
||||
4. Best practice violations
|
||||
5. Code style and readability
|
||||
</task>
|
||||
|
||||
<code>
|
||||
{{CODE_HERE}}
|
||||
</code>
|
||||
|
||||
<output_format>
|
||||
For each issue:
|
||||
|
||||
### Issue: [Title]
|
||||
- **Severity**: Critical/High/Medium/Low
|
||||
- **Category**: Bug/Performance/Security/Style
|
||||
- **Location**: Line {{LINE_NUMBER}}
|
||||
- **Problem**: [Description]
|
||||
- **Fix**: [Recommendation]
|
||||
- **Code**:
|
||||
```{{LANGUAGE}}
|
||||
[Fixed code]
|
||||
```
|
||||
</output_format>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 3: Content Generation
|
||||
|
||||
```xml
|
||||
<task>
|
||||
Write a {{CONTENT_TYPE}} about {{TOPIC}}.
|
||||
</task>
|
||||
|
||||
<requirements>
|
||||
- **Length**: {{WORD_COUNT}} words
|
||||
- **Tone**: {{TONE}}
|
||||
- **Audience**: {{AUDIENCE}}
|
||||
- **Format**: {{FORMAT}}
|
||||
</requirements>
|
||||
|
||||
<must_include>
|
||||
- {{POINT_1}}
|
||||
- {{POINT_2}}
|
||||
- {{POINT_3}}
|
||||
</must_include>
|
||||
|
||||
<structure>
|
||||
1. {{SECTION_1}}
|
||||
2. {{SECTION_2}}
|
||||
3. {{SECTION_3}}
|
||||
4. {{SECTION_4}}
|
||||
</structure>
|
||||
|
||||
<examples>
|
||||
<example>
|
||||
<good_example>
|
||||
{{EXAMPLE_TEXT}}
|
||||
</good_example>
|
||||
<why_good>
|
||||
{{EXPLANATION}}
|
||||
</why_good>
|
||||
</example>
|
||||
</examples>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 4: Classification
|
||||
|
||||
```xml
|
||||
<instructions>
|
||||
Classify the following {{ITEM_TYPE}} into one of these categories:
|
||||
{{CATEGORY_LIST}}
|
||||
</instructions>
|
||||
|
||||
<classification_rules>
|
||||
- {{RULE_1}}
|
||||
- {{RULE_2}}
|
||||
- {{RULE_3}}
|
||||
</classification_rules>
|
||||
|
||||
<examples>
|
||||
{{FEW_SHOT_EXAMPLES}}
|
||||
</examples>
|
||||
|
||||
<item>
|
||||
{{ITEM_TO_CLASSIFY}}
|
||||
</item>
|
||||
|
||||
<output_format>
|
||||
{
|
||||
"category": "{{CATEGORY}}",
|
||||
"confidence": {{0-1}},
|
||||
"reasoning": "{{BRIEF_EXPLANATION}}"
|
||||
}
|
||||
</output_format>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 5: Analysis and Insights
|
||||
|
||||
```xml
|
||||
<role>
|
||||
You are an expert {{DOMAIN}} analyst.
|
||||
</role>
|
||||
|
||||
<task>
|
||||
Analyze the following {{DATA_TYPE}} and provide insights.
|
||||
</task>
|
||||
|
||||
<data>
|
||||
{{DATA_HERE}}
|
||||
</data>
|
||||
|
||||
<analysis_framework>
|
||||
1. **Overview**: What are we looking at?
|
||||
2. **Patterns**: What trends or patterns emerge?
|
||||
3. **Anomalies**: What's unexpected or noteworthy?
|
||||
4. **Insights**: What does this mean?
|
||||
5. **Recommendations**: What actions should be taken?
|
||||
</analysis_framework>
|
||||
|
||||
<output_requirements>
|
||||
- Support claims with data
|
||||
- Quantify findings where possible
|
||||
- Prioritize insights by impact
|
||||
- Be specific and actionable
|
||||
</output_requirements>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 6: Debugging Assistant
|
||||
|
||||
```xml
|
||||
<role>
|
||||
You are a debugging expert for {{LANGUAGE/FRAMEWORK}}.
|
||||
</role>
|
||||
|
||||
<problem>
|
||||
{{ERROR_MESSAGE_OR_DESCRIPTION}}
|
||||
</problem>
|
||||
|
||||
<code>
|
||||
{{PROBLEMATIC_CODE}}
|
||||
</code>
|
||||
|
||||
<context>
|
||||
{{ADDITIONAL_CONTEXT}}
|
||||
</context>
|
||||
|
||||
<debugging_process>
|
||||
Think step by step:
|
||||
|
||||
1. What is the error telling us?
|
||||
2. What could cause this error?
|
||||
3. What's the most likely root cause?
|
||||
4. How can we fix it?
|
||||
5. How can we prevent this in the future?
|
||||
</debugging_process>
|
||||
|
||||
<output>
|
||||
Provide:
|
||||
1. Root cause explanation
|
||||
2. Fixed code with comments
|
||||
3. Prevention tips
|
||||
</output>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 7: Comparison and Evaluation
|
||||
|
||||
```xml
|
||||
<task>
|
||||
Compare {{OPTION_A}} vs {{OPTION_B}} for {{USE_CASE}}.
|
||||
</task>
|
||||
|
||||
<evaluation_criteria>
|
||||
1. {{CRITERION_1}}
|
||||
2. {{CRITERION_2}}
|
||||
3. {{CRITERION_3}}
|
||||
4. {{CRITERION_4}}
|
||||
</evaluation_criteria>
|
||||
|
||||
<option_a>
|
||||
{{DETAILS_A}}
|
||||
</option_a>
|
||||
|
||||
<option_b>
|
||||
{{DETAILS_B}}
|
||||
</option_b>
|
||||
|
||||
<output_format>
|
||||
## Summary
|
||||
[2-3 sentence overview]
|
||||
|
||||
## Detailed Comparison
|
||||
|
||||
| Criterion | {{OPTION_A}} | {{OPTION_B}} | Winner |
|
||||
|-----------|--------------|--------------|--------|
|
||||
| {{CRIT_1}} | [analysis] | [analysis] | [A/B/Tie] |
|
||||
|
||||
## Recommendation
|
||||
[Specific recommendation with reasoning]
|
||||
</output_format>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 8: Step-by-Step Tutorial
|
||||
|
||||
```xml
|
||||
<task>
|
||||
Create a step-by-step tutorial for {{TASK}}.
|
||||
</task>
|
||||
|
||||
<audience>
|
||||
{{TARGET_AUDIENCE}} with {{SKILL_LEVEL}} level knowledge
|
||||
</audience>
|
||||
|
||||
<requirements>
|
||||
- {{REQUIREMENT_1}}
|
||||
- {{REQUIREMENT_2}}
|
||||
- {{REQUIREMENT_3}}
|
||||
</requirements>
|
||||
|
||||
<structure>
|
||||
For each step:
|
||||
1. **Step title**: Clear, action-oriented
|
||||
2. **Explanation**: Why this step matters
|
||||
3. **Instructions**: How to do it
|
||||
4. **Code/Example**: Concrete implementation
|
||||
5. **Expected result**: What success looks like
|
||||
6. **Common issues**: Troubleshooting tips
|
||||
</structure>
|
||||
|
||||
<tone>
|
||||
- Clear and encouraging
|
||||
- Explain technical terms
|
||||
- Assume no prior knowledge beyond prerequisites
|
||||
</tone>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 9: API/Function Documentation
|
||||
|
||||
```xml
|
||||
<task>
|
||||
Generate comprehensive documentation for this {{API/FUNCTION}}.
|
||||
</task>
|
||||
|
||||
<code>
|
||||
{{CODE_HERE}}
|
||||
</code>
|
||||
|
||||
<documentation_template>
|
||||
## {{FUNCTION_NAME}}
|
||||
|
||||
### Description
|
||||
[What it does and when to use it]
|
||||
|
||||
### Signature
|
||||
```{{LANGUAGE}}
|
||||
[function signature]
|
||||
```
|
||||
|
||||
### Parameters
|
||||
- `param1` (type): Description
|
||||
- `param2` (type): Description
|
||||
|
||||
### Returns
|
||||
- (type): Description
|
||||
|
||||
### Raises/Throws
|
||||
- `ExceptionType`: When and why
|
||||
|
||||
### Examples
|
||||
|
||||
```{{LANGUAGE}}
|
||||
# Example 1: Basic usage
|
||||
[code]
|
||||
|
||||
# Example 2: Advanced usage
|
||||
[code]
|
||||
```
|
||||
|
||||
### Notes
|
||||
- [Important consideration 1]
|
||||
- [Important consideration 2]
|
||||
</documentation_template>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 10: Prompt Improvement
|
||||
|
||||
```xml
|
||||
<task>
|
||||
Improve the following prompt to be more effective.
|
||||
</task>
|
||||
|
||||
<original_prompt>
|
||||
{{PROMPT_TO_IMPROVE}}
|
||||
</original_prompt>
|
||||
|
||||
<improvement_criteria>
|
||||
1. Clarity and specificity
|
||||
2. Proper structure (XML tags)
|
||||
3. Examples where helpful
|
||||
4. Clear output format
|
||||
5. Appropriate context
|
||||
6. Avoid common mistakes
|
||||
</improvement_criteria>
|
||||
|
||||
<improved_prompt>
|
||||
[Provide the improved version with explanations of changes]
|
||||
</improved_prompt>
|
||||
|
||||
<explanation>
|
||||
**Changes made:**
|
||||
1. [Change 1 and why]
|
||||
2. [Change 2 and why]
|
||||
3. [Change 3 and why]
|
||||
</explanation>
|
||||
```
|
||||
Reference in New Issue
Block a user