$npx -y skills add muratcankoylan/Agent-Skills-for-Context-Engineering --skill templateTemplate for creating new Agent Skills for context engineering. Use this template when adding new skills to the collection.
| 1 | # Skill Name |
| 2 | |
| 3 | Provide a clear, concise description of what this skill covers and when to use it. This description appears in skill discovery and should help agents (and humans) determine when this skill is relevant. |
| 4 | |
| 5 | **Important**: Keep the total SKILL.md body under 500 lines for optimal performance. Move detailed reference material to separate files in the `references/` directory. |
| 6 | |
| 7 | Every skill body must make its ownership boundary explicit. The description and `When to Activate` section should say what the skill owns and which adjacent skills own nearby work. This prevents broad skills from stealing activation from narrower skills. |
| 8 | |
| 9 | ## When to Activate |
| 10 | |
| 11 | Describe specific situations, tasks, or contexts where this skill should be activated. Include both direct triggers (specific keywords or task types) and indirect signals (broader patterns that indicate skill relevance). |
| 12 | |
| 13 | Write in third person. The description is injected into the system prompt, and inconsistent point-of-view can cause discovery problems. |
| 14 | |
| 15 | - Good: "Processes Excel files and generates reports" |
| 16 | - Avoid: "I can help you process Excel files" |
| 17 | |
| 18 | Include a short "Do not activate" block for adjacent skills. Example: |
| 19 | |
| 20 | - Do not activate for project-level pipeline shape: `project-development`. |
| 21 | - Do not activate for individual tool schema design: `tool-design`. |
| 22 | |
| 23 | ## Core Concepts |
| 24 | |
| 25 | Explain the fundamental concepts covered by this skill. These are the mental models, principles, or frameworks that the skill teaches. |
| 26 | |
| 27 | Default assumption: Claude is already very smart. Only add context Claude does not already have. Challenge each piece of information: |
| 28 | - "Does Claude really need this explanation?" |
| 29 | - "Can I assume Claude knows this?" |
| 30 | - "Does this paragraph justify its token cost?" |
| 31 | |
| 32 | Prefer behavior-changing mechanisms over general background. If a concept should be reusable across the corpus, add or update a record in `researcher/mechanisms/registry.jsonl`. |
| 33 | |
| 34 | ## Detailed Topics |
| 35 | |
| 36 | ### Topic 1 |
| 37 | |
| 38 | Provide detailed explanation of the first major topic. Include specific techniques, patterns, or approaches. Use examples to illustrate concepts. |
| 39 | |
| 40 | ### Topic 2 |
| 41 | |
| 42 | Provide detailed explanation of the second major topic. Continue with additional topics as needed. |
| 43 | |
| 44 | For longer topics, consider moving content to `references/` and linking: |
| 45 | - See [detailed reference](./references/topic-details.md) for complete implementation |
| 46 | |
| 47 | ## Practical Guidance |
| 48 | |
| 49 | Provide actionable guidance for applying the skill. Include common patterns, anti-patterns to avoid, and decision frameworks for choosing between approaches. |
| 50 | |
| 51 | Match the level of specificity to the task's fragility: |
| 52 | - **High freedom**: Multiple approaches are valid, decisions depend on context |
| 53 | - **Medium freedom**: Preferred pattern exists, some variation acceptable |
| 54 | - **Low freedom**: Operations are fragile, specific sequence must be followed |
| 55 | |
| 56 | Practical guidance should be executable by an agent: a workflow, checklist, decision table, or concrete operating rule. If a section only explains history or motivation, move it to `references/`. |
| 57 | |
| 58 | ## Examples |
| 59 | |
| 60 | Provide concrete examples that illustrate skill application. Examples should show before/after comparisons, demonstrate correct usage, or show how to handle edge cases. |
| 61 | |
| 62 | Use input/output pairs for clarity: |
| 63 | |
| 64 | **Example:** |
| 65 | ``` |
| 66 | Input: [describe input] |
| 67 | Output: [show expected output] |
| 68 | ``` |
| 69 | |
| 70 | ## Guidelines |
| 71 | |
| 72 | List specific guidelines to follow when applying this skill. These should be actionable rules that can be checked or verified. |
| 73 | |
| 74 | 1. Guideline one with specific, verifiable criteria |
| 75 | 2. Guideline two with clear success conditions |
| 76 | 3. Continue as needed |
| 77 | |
| 78 | ## Gotchas |
| 79 | |
| 80 | List experience-derived failure modes, common mistakes, and counterintuitive behaviors. These are the highest-signal content in any skill. Each gotcha should be specific, actionable, and non-overlapping with guidance already in the skill body. Use numbered format: |
| 81 | |
| 82 | 1. **Short descriptive title**: One to two sentences explaining what goes wrong and how to prevent it. |
| 83 | 2. **Another gotcha title**: Description of the failure mode and what to do instead. |
| 84 | |
| 85 | ## Integration |
| 86 | |
| 87 | Explain how this skill integrates with other skills in the collection. List related skills as plain text (not links) to avoid cross-directory reference issues: |
| 88 | |
| 89 | - skill-name-one - Brief description of relationship |
| 90 | - skill-name-two - Brief description of relationship |
| 91 | |
| 92 | ## References |
| 93 | |
| 94 | Internal reference (use relative path to skill's own reference files): |
| 95 | - [Reference Name](./references/reference-file.md) - Description |
| 96 | |
| 97 | Related skills in this collection: |
| 98 | - skill-name - Relationship description |
| 99 | |
| 100 | External resources: |
| 101 | - Research papers, documentation, or guides |
| 102 | |
| 103 | Numeric, benchmark, volatile, or vendor-performance claims need an inline `claim-*` ID backed by `researcher/claims/index.jsonl`, or they should be softened and moved to |