Initial commit
This commit is contained in:
12
.claude-plugin/plugin.json
Normal file
12
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,12 @@
|
||||
{
|
||||
"name": "prompt-skills",
|
||||
"description": "Collection of prompt engineering skills",
|
||||
"version": "0.0.0-2025.11.28",
|
||||
"author": {
|
||||
"name": "Han",
|
||||
"email": "ihanai1991@gmail.com"
|
||||
},
|
||||
"skills": [
|
||||
"./skills"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# prompt-skills
|
||||
|
||||
Collection of prompt engineering skills
|
||||
49
plugin.lock.json
Normal file
49
plugin.lock.json
Normal file
@@ -0,0 +1,49 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:hanai/cc-marketplace:",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "1f3b6a6199f0d61d9117d752c53acc05f97b8078",
|
||||
"treeHash": "ab016fcab94f9a9553a47f1fad79b86fbc3d23655e32b04bc486ded4106beb9a",
|
||||
"generatedAt": "2025-11-28T10:17:22.287811Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "prompt-skills",
|
||||
"description": "Collection of prompt engineering skills",
|
||||
"version": null
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "f89e1ca19ac855eae6b3d2a7eac1964e80adcb71e0a4fdfc9b15c6ba228a1ccc"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "2418bda75174b3aad5e736f821bacf43196b8e7c85be2bfbc023de4c53c4289c"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt/best-practices-for-prompt-engineering/SKILL.md",
|
||||
"sha256": "6bdf457438ae04ffdc6b0c83e3ca33fb18deb7a8d120c623db8d169b389b1c4a"
|
||||
},
|
||||
{
|
||||
"path": "skills/coding/fundamental-coding-principles/SKILL.md",
|
||||
"sha256": "982287446cd10ccd885f47c6597a9c5f84f6af34114b37fa027db38f2e17d5ae"
|
||||
}
|
||||
],
|
||||
"dirSha256": "ab016fcab94f9a9553a47f1fad79b86fbc3d23655e32b04bc486ded4106beb9a"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
48
skills/coding/fundamental-coding-principles/SKILL.md
Normal file
48
skills/coding/fundamental-coding-principles/SKILL.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
name: fundamental-coding-principles
|
||||
description: Apply SOLID, DRY, KISS, YAGNI, and SSOT principles when writing, reviewing, or refactoring code to ensure maintainability and quality.
|
||||
---
|
||||
|
||||
# Fundamental Coding Principles
|
||||
|
||||
Apply this skill to keep code changes focused, testable, and maintainable.
|
||||
|
||||
## Quick Checklist
|
||||
- Confirm each edit has a single purpose before coding.
|
||||
- Ruthlessly remove duplication or dead paths you touch.
|
||||
- Only add behavior backed by an explicit requirement.
|
||||
- Prefer simple, composable solutions over clever ones.
|
||||
- Keep truthy data and decisions in one authoritative place.
|
||||
|
||||
## Principle Guardrails
|
||||
|
||||
### SOLID
|
||||
- `S`: Validate the change impacts one reason to vary; split helpers if mixed concerns appear.
|
||||
- `O`: Extend behavior through new types or functions rather than rewriting stable code paths.
|
||||
- `L`: Ensure new subtype logic preserves caller expectations (inputs, return contracts, exceptions).
|
||||
- `I`: Create targeted interfaces; avoid forcing consumers to implement unused members.
|
||||
- `D`: Depend on abstractions or injected collaborators; eliminate hardwired globals where possible.
|
||||
|
||||
### DRY
|
||||
- Scan for repeated logic, constants, or schemas; consolidate into shared utilities before finishing.
|
||||
- Prefer extracting reusable modules over copy-pasting even inside the same file.
|
||||
|
||||
### KISS
|
||||
- Trim optional branches, flags, and polymorphism unless they solve today’s requirement.
|
||||
- Keep functions short and state minimal; decompose complex flows into readable steps.
|
||||
|
||||
### YAGNI
|
||||
- Challenge every new feature, parameter, or hook: is there a verified need right now?
|
||||
- Defer premature abstractions until duplication or clear requirements emerge.
|
||||
|
||||
### SSOT
|
||||
- Update or create the canonical definition (config, schema, doc) when data models change.
|
||||
- Remove divergent caches or mirrors unless you enforce sync in the same change.
|
||||
|
||||
## Reference Playbooks
|
||||
- [Splunk: "SOLID Design Principles – Hands-On Examples"](https://www.splunk.com/en_us/blog/learn/solid-design-principle.html) – success/failure code walkthroughs for each letter.
|
||||
- [PullRequest.com: "7 Clean Coding Principles"](https://www.pullrequest.com/blog/7-clean-coding-principles/) – DRY-focused review prompts.
|
||||
- [MIT 6.031: Code Review Guide](https://web.mit.edu/6.031/www/fa20/classes/03-code-review/) – DRY and simplification questions to ask.
|
||||
- [Baeldung: KISS Software Design Principle](https://www.baeldung.com/cs/kiss-software-design-principle) – tactics for keeping solutions lightweight.
|
||||
- [TechTarget: YAGNI Explainer](https://www.techtarget.com/whatis/definition/You-arent-gonna-need-it) – decision tests and risk scenarios.
|
||||
- [Atlassian Workstream: Building an SSOT](https://www.atlassian.com/work-management/knowledge-sharing/documentation/building-a-single-source-of-truth-ssot-for-your-team) – practices for maintaining canonical sources.
|
||||
372
skills/prompt/best-practices-for-prompt-engineering/SKILL.md
Normal file
372
skills/prompt/best-practices-for-prompt-engineering/SKILL.md
Normal file
@@ -0,0 +1,372 @@
|
||||
---
|
||||
name: best-practices-for-prompt-engineering
|
||||
description: Best practices for prompt engineering. Apply this skill when creating, optimizing, reviewing, or troubleshooting prompts for large language models (LLMs).
|
||||
source: https://claude.com/blog/best-practices-for-prompt-engineering
|
||||
---
|
||||
|
||||
## How to use prompt engineering
|
||||
|
||||
At its most basic level, prompt engineering is just modifying the query you pass your LLM. Often it's simply adding information to the query before you make your actual request—but knowing *which* information is the *right* information to share is the secret to engineering a great and effective prompt.
|
||||
|
||||
### Core techniques
|
||||
|
||||
These prompt engineering techniques form the foundation of effective AI interactions. Use them consistently to see immediate improvements in response quality.
|
||||
|
||||
#### Be explicit and clear
|
||||
|
||||
Modern AI models respond exceptionally well to clear, explicit instructions. Don't assume the model will infer what you want—state it directly. Use simple language that states exactly what you want without ambiguity.
|
||||
|
||||
**The key principle**: Tell the model exactly what you want to see. If you want comprehensive output, ask for it. If you want specific features, list them. Modern models benefit especially from explicit direction.
|
||||
|
||||
**Example: Creating an analytics dashboard**
|
||||
|
||||
**Vague**: "Create an analytics dashboard"
|
||||
|
||||
**Explicit**: "Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation."
|
||||
|
||||
The second version explicitly requests comprehensive features and signals that you want the model to go above and beyond the minimum.
|
||||
|
||||
**Best practices**:
|
||||
|
||||
* Lead with direct action verbs: "Write," "Analyze," "Generate," "Create"
|
||||
* Skip preambles and get straight to the request
|
||||
* State what you want the output to include, not just what to work on
|
||||
* Be specific about quality and depth expectations
|
||||
|
||||
#### Provide context and motivation
|
||||
|
||||
Explaining *why* something matters helps AI models better understand your goals and deliver more targeted responses. This is particularly effective with newer models that can reason about your underlying objectives.
|
||||
|
||||
**Example: Formatting preferences**
|
||||
|
||||
**Less effective**: "NEVER use bullet points"
|
||||
|
||||
**More effective**: "I prefer responses in natural paragraph form rather than bullet points because I find flowing prose easier to read and more conversational. Bullet points feel too formal and list-like for my casual learning style."
|
||||
|
||||
The second version helps the model understand the reasoning behind the rule, which allows it to make better decisions about related formatting choices.
|
||||
|
||||
**When to provide context**:
|
||||
|
||||
* Explaining the purpose or audience for the output
|
||||
* Clarifying why certain constraints exist
|
||||
* Describing how the output will be used
|
||||
* Indicating what problem you're trying to solve
|
||||
|
||||
#### Be specific
|
||||
|
||||
Specificity in prompt engineering means structuring your instructions with explicit guidelines and requirements. The more specific you are about what you want, the better the results.
|
||||
|
||||
**Example: Meal planning**
|
||||
|
||||
**Vague**: "Create a meal plan for a Mediterranean diet"
|
||||
|
||||
**Specific**: "Design a Mediterranean diet meal plan for pre-diabetic management. 1,800 calories daily, emphasis on low glycemic foods. List breakfast, lunch, dinner, and one snack with complete nutritional breakdowns."
|
||||
|
||||
**What makes a prompt specific enough?**
|
||||
|
||||
Include:
|
||||
|
||||
* Clear constraints (word count, format, timeline)
|
||||
* Relevant context (who's the audience, what's the goal)
|
||||
* Desired output structure (table, list, paragraph)
|
||||
* Any requirements or restrictions (dietary needs, budget limits, technical constraints)
|
||||
|
||||
#### Use examples
|
||||
|
||||
Examples aren't always necessary, but they shine when explaining concepts or demonstrating specific formats. Also known as one-shot or few-shot prompting, examples show rather than tell, clarifying subtle requirements that are difficult to express through description alone.
|
||||
|
||||
**Example: Article summarization**
|
||||
|
||||
**Without example**: "Summarize this article"
|
||||
|
||||
```plaintext
|
||||
Here's an example of the summary style I want:
|
||||
|
||||
Article: [link to article about AI regulation]
|
||||
Summary: EU passes comprehensive AI Act targeting high-risk systems. Key provisions include transparency requirements and human oversight mandates. Takes effect 2026.
|
||||
|
||||
Now summarize this article in the same style: [link to your new article]
|
||||
```
|
||||
|
||||
**When to use examples**:
|
||||
|
||||
* The desired format is easier to show than describe
|
||||
* You need a specific tone or style
|
||||
* The task involves subtle patterns or conventions
|
||||
* Simple instructions haven't produced consistent results
|
||||
|
||||
**Pro tip**: Start with one example (one-shot). Only add more examples (few-shot) if the output still doesn't match your needs.
|
||||
|
||||
#### Give permission to AI to express uncertainty
|
||||
|
||||
Give the AI explicit permission to express uncertainty rather than guessing. This reduces hallucinations and increases reliability.
|
||||
|
||||
**Example**: "Analyze this financial data and identify trends. If the data is insufficient to draw conclusions, say so rather than speculating."
|
||||
|
||||
This simple addition makes responses more trustworthy by allowing the model to acknowledge limitations.
|
||||
|
||||
## Advanced prompt engineering techniques
|
||||
|
||||
These core habits will get you pretty far, but you may still encounter situations that require more sophisticated approaches. Advanced prompt engineering techniques shine when you're building agentic solutions, working with complex data structures, or need to break down multi-stage problems.
|
||||
|
||||
### Prefill the AI's response
|
||||
|
||||
Prefilling lets you start the AI's response for it, guiding format, tone, or structure. This technique is particularly powerful for enforcing output formats or skipping preambles.
|
||||
|
||||
**When to use prefilling**:
|
||||
|
||||
* You need the AI to output JSON, XML, or other structured formats
|
||||
* You want to skip conversational preambles and get straight to content
|
||||
* You need to maintain a specific voice or character
|
||||
* You want to control how the AI begins its response
|
||||
|
||||
**Example: Enforcing JSON output**
|
||||
|
||||
Without prefill, AI might say: "Here's the JSON you requested: {...}"
|
||||
|
||||
With prefill (API usage):
|
||||
|
||||
```python
|
||||
messages=[
|
||||
{"role": "user", "content": "Extract the name and price from this product description into JSON."},
|
||||
{"role": "assistant", "content": "{"}
|
||||
]
|
||||
```
|
||||
|
||||
The AI will continue from the opening brace, outputting only valid JSON.
|
||||
|
||||
**Note**: In chat interfaces, you can approximate this by being very explicit: "Output only valid JSON with no preamble. Begin your response with an opening brace."
|
||||
|
||||
### Chain of thought prompting
|
||||
|
||||
Chain of thought (CoT) prompting involves requesting step-by-step reasoning before answering. This technique helps with complex analytical tasks that benefit from structured thinking.
|
||||
|
||||
**When to use chain of thought**:
|
||||
|
||||
* You need transparent reasoning that you can review
|
||||
* The task requires multiple analytical steps
|
||||
* You want to ensure the AI considers specific factors
|
||||
|
||||
There are three common implementations of chain of thought:
|
||||
|
||||
**Basic chain of thought**
|
||||
|
||||
Simply add "Think step-by-step" to your instructions.
|
||||
|
||||
```plaintext
|
||||
Draft personalized emails to donors asking for contributions to this year's Care for Kids program.
|
||||
|
||||
Program information:
|
||||
<program>
|
||||
{{PROGRAM_DETAILS}}
|
||||
</program>
|
||||
|
||||
Donor information:
|
||||
<donor>
|
||||
{{DONOR_DETAILS}}
|
||||
</donor>
|
||||
|
||||
Think step-by-step before you write the email.
|
||||
```
|
||||
|
||||
**Guided chain of thought**
|
||||
|
||||
Structure your prompt to provide specific reasoning stages.
|
||||
|
||||
```javascript
|
||||
Think before you write the email. First, think through what messaging might appeal to this donor given their donation history. Then, consider which aspects of the Care for Kids program would resonate with them. Finally, write the personalized donor email using your analysis.
|
||||
```
|
||||
|
||||
**Structured chain of thought**
|
||||
|
||||
Use tags to separate reasoning from the final answer.
|
||||
|
||||
```javascript
|
||||
Think before you write the email in <thinking> tags. First, analyze what messaging would appeal to this donor. Then, identify relevant program aspects. Finally, write the personalized donor email in <email> tags, using your analysis.
|
||||
```
|
||||
|
||||
### Control the output format
|
||||
|
||||
For modern AI models, there are several effective ways to control response formatting:
|
||||
|
||||
**1\. Tell the AI 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"
|
||||
|
||||
**2\. Match your prompt style to the desired output**
|
||||
|
||||
The formatting style used in your prompt may influence the AI's response style. If you want minimal markdown, reduce markdown in your prompt.
|
||||
|
||||
**3\. Be explicit about formatting preferences**
|
||||
|
||||
For detailed control over formatting:
|
||||
|
||||
```plaintext
|
||||
When writing reports or analyses, write in clear, flowing prose using complete paragraphs. Use standard paragraph breaks for organization. Reserve markdown primarily for inline code, code blocks, and simple headings.
|
||||
|
||||
DO NOT use ordered lists or unordered lists unless you're presenting truly discrete items where a list format is the best option, or the user explicitly requests a list.
|
||||
|
||||
Instead of listing items with bullets, incorporate them naturally into sentences. Your goal is readable, flowing text that guides the reader naturally through ideas.
|
||||
```
|
||||
|
||||
### Prompt chaining
|
||||
|
||||
Unlike the previous techniques, prompt chaining cannot be implemented in a single prompt. Chaining breaks down complex tasks into smaller sequential steps with separate prompts. Each prompt handles one stage, and the output feeds into the next instruction.
|
||||
|
||||
This approach trades latency for higher accuracy by making each individual task easier. Typically this technique would be implemented using workflows or programmatically, but you could manually provide the prompts after receiving responses.
|
||||
|
||||
**Example: Research summary**
|
||||
|
||||
1. **First prompt**: "Summarize this medical paper covering methodology, findings, and clinical implications."
|
||||
|
||||
2. **Second prompt**: "Review the summary above for accuracy, clarity, and completeness. Provide graded feedback."
|
||||
|
||||
3. **Third prompt**: "Improve the summary based on this feedback: [feedback from step 2]"
|
||||
|
||||
Each stage adds refinement through focused instruction.
|
||||
|
||||
**When to use prompt chaining**:
|
||||
|
||||
* You have a complex request that needs breaking down into steps
|
||||
* You need iterative refinement
|
||||
* You're doing multi-stage analysis
|
||||
* Intermediate validation adds value
|
||||
* A single prompt produces inconsistent results
|
||||
|
||||
**Trade-offs**: Chaining increases latency (multiple API calls) but often dramatically improves accuracy and reliability for complex tasks.
|
||||
|
||||
## Techniques you might have heard about
|
||||
|
||||
Some prompt engineering techniques that were popular with earlier AI models are less necessary with modern models. However, you may still encounter them in older documentation or find them useful in specific situations.
|
||||
|
||||
### XML tags for structure
|
||||
|
||||
XML tags were once a recommended way to add structure and clarity to prompts, especially when incorporating large amounts of data. While modern models are better at understanding structure without XML tags, they can still be useful in specific situations.
|
||||
|
||||
**Example**:
|
||||
|
||||
```plaintext
|
||||
<athlete_information>
|
||||
- Height: 6'2"
|
||||
- Weight: 180 lbs
|
||||
- Goal: Build muscle
|
||||
- Dietary restrictions: Vegetarian
|
||||
</athlete_information>
|
||||
|
||||
Generate a meal plan based on the athlete information above.
|
||||
```
|
||||
|
||||
**When XML tags might still be helpful**:
|
||||
|
||||
* You're working with extremely complex prompts mixing multiple types of content
|
||||
* You need to be absolutely certain about content boundaries
|
||||
* You're working with older model versions
|
||||
|
||||
**Modern alternative**: For most use cases, clear headings, whitespace, and explicit language ("Using the athlete information below...") work just as well with less overhead.
|
||||
|
||||
### Role prompting
|
||||
|
||||
Role prompting defines expert personas and perspectives in how you phrase your query. While this can be effective, modern models are sophisticated enough that heavy-handed role prompting is often unnecessary.
|
||||
|
||||
**Example**: "You are a financial advisor. Analyze this investment portfolio..."
|
||||
|
||||
**Important caveat**: Don't over-constrain the role. "You are a helpful assistant" is often better than "You are a world-renowned expert who only speaks in technical jargon and never makes mistakes." Overly specific roles can limit the AI's helpfulness.
|
||||
|
||||
**When role prompting might help**:
|
||||
|
||||
* You need consistent tone across many outputs
|
||||
* You're building an application that requires a specific persona
|
||||
* You want domain expertise framing for complex topics
|
||||
|
||||
**Modern alternative**: Often, being explicit about what perspective you want is more effective: "Analyze this investment portfolio, focusing on risk tolerance and long-term growth potential" rather than assigning a role.
|
||||
|
||||
## Putting it all together
|
||||
|
||||
You've now seen individual techniques in isolation, but their real power emerges when you combine them strategically. The art of prompt engineering isn't using every technique available—it's selecting the right combination for your specific need.
|
||||
|
||||
**Example combining multiple techniques**:
|
||||
|
||||
```less
|
||||
xtract key financial metrics from this quarterly report and present them in JSON format.
|
||||
|
||||
I need this data for automated processing, so it's critical that your response contains ONLY valid JSON with no preamble or explanation.
|
||||
|
||||
Use this structure:
|
||||
{
|
||||
"revenue": "value with units",
|
||||
"profit_margin": "percentage",
|
||||
"growth_rate": "percentage"
|
||||
}
|
||||
|
||||
If any metric is not clearly stated in the report, use null rather than guessing.
|
||||
|
||||
Begin your response with an opening brace: {
|
||||
```
|
||||
|
||||
This prompt combines:
|
||||
|
||||
* Explicit instructions (exactly what to extract)
|
||||
* Context (why format matters)
|
||||
* Example structure (showing the format)
|
||||
* Permission to express uncertainty (use null if unsure)
|
||||
* Format control (begin with opening brace)
|
||||
|
||||
## Choosing the right techniques
|
||||
|
||||
Not every prompt needs every technique. Here's a decision framework:
|
||||
|
||||
**Start here:**
|
||||
|
||||
1. Is your request clear and explicit? If no, work on clarity first
|
||||
2. Is the task simple? Use core techniques only (be specific, be clear, provide context)
|
||||
3. Does the task require specific formatting? Use examples or prefilling
|
||||
4. Is the task complex? Consider breaking it down (chaining)
|
||||
5. Does it need reasoning? Use chain of thought
|
||||
|
||||
**Technique selection guide**:
|
||||
|
||||
## Troubleshooting common prompt issues
|
||||
|
||||
Even well-intentioned prompts can produce unexpected results. Here are common issues and how to fix them:
|
||||
|
||||
* **Problem: Response is too generic** → Solution: Add specificity, examples, or explicit requests for comprehensive output. Ask the AI to "go beyond the basics."
|
||||
* **Problem: Response is off-topic or misses the point** → Solution: Be more explicit about your actual goal. Provide context about why you're asking.
|
||||
* **Problem: Response format is inconsistent** → Solution: Add examples (few-shot) or use prefilling to control the start of the response.
|
||||
* **Problem: Task is too complex, results are unreliable** → Solution: Break into multiple prompts (chaining). Each prompt should do one thing well.
|
||||
* **Problem: AI includes unnecessary preambles** → Solution: Use prefilling or explicitly request: "Skip the preamble and get straight to the answer."
|
||||
* **Problem: AI makes up information** → Solution: Explicitly give permission to say "I don't know" when uncertain.
|
||||
* **Problem: AI suggests changes when you wanted implementation** → Solution: Be explicit about action: "Change this function" rather than "Can you suggest changes?"
|
||||
|
||||
**Pro tip**: Start simple and add complexity only when needed. Test each addition to see if it actually improves results.
|
||||
|
||||
## Common mistakes to avoid
|
||||
|
||||
Learn from these common pitfalls to save time and improve your prompts:
|
||||
|
||||
* **Don't over-engineer**: Longer, more complex prompts are NOT always better.
|
||||
* **Don't ignore the basics**: Advanced techniques won't help if your core prompt is unclear or vague.
|
||||
* **Don't assume the AI reads minds**: Be specific about what you want. Leaving things ambiguous gives the AI room to misinterpret.
|
||||
* **Don't use every technique at once**: Select techniques that address your specific challenge.
|
||||
* **Don't forget to iterate**: The first prompt rarely works perfectly. Test and refine.
|
||||
* **Don't rely on outdated techniques**: XML tags and heavy role prompting are less necessary with modern models. Start with explicit, clear instructions.
|
||||
|
||||
## Prompt engineering considerations
|
||||
|
||||
### Working with long content
|
||||
|
||||
One of the challenges of implementing advanced prompt engineering is that it adds context overhead through additional token usage. Examples, multiple prompts, detailed instructions—they all consume tokens, and context management is a skill in its own right.
|
||||
|
||||
Remember to use prompt engineering techniques when they make sense and justify their usage. For comprehensive guidance on managing context effectively, check out our blog post on [context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents).
|
||||
|
||||
**Context awareness improvements**: Modern AI models have significantly improved context awareness capabilities that help address historical "lost-in-the-middle" issues where models struggled to attend equally to all parts of long contexts.
|
||||
|
||||
**Why task-splitting still helps**: Even with these improvements, breaking large tasks into smaller, discrete chunks remains a valuable technique—not because of context limitations, but because it helps the model focus on doing its best work within a very specific set of requirements and scope. A focused task with clear boundaries consistently produces higher quality results than trying to accomplish multiple objectives in a single prompt.
|
||||
|
||||
**Strategy**: When working with long contexts, structure your information clearly with the most critical details at the beginning or end. When working with complex tasks, consider whether breaking them into focused subtasks would improve the quality and reliability of each component.
|
||||
|
||||
## Additional resources
|
||||
|
||||
* [Prompt engineering documentation](https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview)
|
||||
* [Interactive prompt engineering tutorial](https://github.com/anthropics/prompt-eng-interactive-tutorial)
|
||||
* [Prompt engineering course](https://anthropic.skilljar.com/claude-with-the-anthropic-api)
|
||||
* [Context engineering guide](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
|
||||
Reference in New Issue
Block a user