Use when creating new skills, improving existing skills, or when the user requests help with skill authoring. Creates optimized Claude Code skills (SKILL.md files) following official best practices for descriptions, structure, content patterns, and validation.
This skill inherits all available tools. When active, it can use any tool Claude has access to.
For foundational instruction authoring principles (token economics, imperative language, formatting, anti-patterns), invoke the authoring-prompts skill first. This skill focuses on skill-specific requirements.
Create Claude Code skills that produce consistent, deterministic agent behavior. Optimize for LLM execution efficiency, not human aesthetics.
Requirements:
Naming convention: Use gerund form (verb + -ing) for clarity.
Good: processing-pdfs, analyzing-spreadsheets, writing-tests
Avoid: helper, utils, tools
Requirements:
The description determines skill invocation. Claude Code selects skills based on description relevance. Frontload invocation triggers with clear, action-oriented language.
Pattern 1: Imperative invocation trigger first
Frontload with directive action when the skill should be invoked proactively:
# Strong - imperative trigger first
description: Use when working with .cs files, .NET projects, implementing C# features, advising on C#/.NET architecture and patterns, or answering questions about C#/.NET development. Covers async patterns, dependency injection, LINQ, and testing conventions.
# Weak - buried trigger
description: C# and .NET patterns for async, DI, LINQ, and testing. Use when working with .cs files or .NET projects.
Pattern 2: Descriptive capability with explicit triggers
For skills invoked based on context, state capabilities then enumerate clear trigger conditions:
# Strong - clear domain and triggers
description: Ruby on Rails conventions for models, controllers, routes, and testing. Use when working with Rails projects, ActiveRecord models, or Rails-specific patterns.
# Weak - vague triggers
description: Helps with Ruby on Rails development tasks.
Pattern 3: "Invoke when" for foundational skills
For skills that should be loaded before other operations, make invocation mandatory:
# Strong - explicit invocation requirement
description: Invoke this skill first when authoring any AI agent instructions. Foundational principles for writing LLM instructions (skills, CLAUDE.md, rules, commands). Covers token economics, imperative language, formatting, emphasis modifiers, and anti-patterns.
# Weak - passive suggestion
description: Foundational principles for writing instructions. Reference when creating skills or documentation.
Vague scope:
description: Helps with documentsdescription: Extract text and tables from PDF files. Use when working with PDFs, forms, or document extraction.Buried triggers:
description: C# patterns including async and LINQ. Use when writing C# code.description: Use when working with .cs files or C# projects. Covers async patterns, LINQ, DI, and testing.Generic verbs without specificity:
description: Assists with testing activitiesdescription: Write xUnit tests with Moq and Bogus. Use when creating unit tests or integration tests in C#.Multiple trigger conditions without clear enumeration:
description: Use for various Rails tasksdescription: Use when working with Rails projects, ActiveRecord models, controllers, routes, or Rails testing.Target: Under 500 lines for optimal performance
When approaching this limit:
SKILL.md serves as an overview that points Claude to detailed materials as needed.
Pattern 1: Reference files for advanced features
## Quick start
[Basic instructions inline]
## Advanced features
**Form filling**: See [references/forms.md](references/forms.md)
**API reference**: See [references/api.md](references/api.md)
Pattern 2: Domain-specific organization
When skills cover multiple domains, organize content by domain to avoid loading irrelevant context.
skill-name/
├── SKILL.md (overview and navigation)
└── references/
├── domain-a.md
├── domain-b.md
└── domain-c.md
Critical rules:
skill-name/
├── SKILL.md # Required: overview and core instructions
├── scripts/ # Executable code (executed, not loaded into context)
├── references/ # Documentation (loaded as needed)
└── templates/ # Templates and examples
Provide templates for output format. Match strictness to requirements.
For strict requirements (API responses, data formats):
ALWAYS use this exact template structure:
[template here]
For flexible guidance:
Here is a sensible default format, adjust as needed:
[template here]
Provide concrete input/output pairs for tasks where output quality depends on seeing examples.
## Commit message format
**Example 1:**
Input: Added user authentication
Output:
feat(auth): implement JWT-based authentication
Add login endpoint and token validation
**Example 2:**
Input: Fixed date display bug
Output:
fix(reports): correct date formatting
Use UTC timestamps consistently
Include 3-5 diverse examples covering different scenarios and edge cases.
Break complex operations into clear sequential steps. For particularly complex workflows, provide a checklist.
## Multi-step workflow
Copy this checklist and track progress:
**Step 1: Analyze input**
[Detailed instructions for step 1]
**Step 2: Create mapping**
[Detailed instructions for step 2]
For quality-critical operations, implement validation cycles:
1. Perform action
2. **Validate immediately**: Run validation script
3. If validation fails:
- Review error messages
- Fix issues
- Run validation again
4. **Only proceed when validation passes**
5. Continue to next step
Guide through decision points:
1. Determine the task type:
**Creating new?** → Follow "Creation workflow"
**Editing existing?** → Follow "Editing workflow"
2. Creation workflow:
[Steps for creation]
3. Editing workflow:
[Steps for editing]
Avoid information that will become outdated.
Bad: "If doing this before August 2025, use old API"
Good: Use "old patterns" section with details/summary tags:
## Current method
[Current approach]
## Old patterns
<details>
<summary>Legacy v1 API (deprecated 2025-08)</summary>
[Historical context]
</details>
Use techniques from prompt engineering to reduce hallucinations:
For consistent outputs:
When including scripts in skills:
Include scripts for operations requiring consistent results. Scripts are more reliable than generated code and save tokens.
Make execution intent clear:
Scripts should:
Example with clear error handling:
def process_file(path):
"""Process file, creating if missing."""
try:
with open(path) as f:
return f.read()
except FileNotFoundError:
print(f"File {path} not found, creating default")
with open(path, 'w') as f:
f.write('')
return ''
List required packages in SKILL.md. Verify they're available in the code execution environment.
Note runtime environment constraints:
Before completing a skill, verify:
Metadata:
Content:
Structure:
Quality:
Execution: