Want to understand how skills work under the hood? This guide breaks down every part of a skill file.
skills/
βββ my-skill-name/
βββ SKILL.md β Required: The main skill definition
βββ examples/ β Optional: Example files
β βββ example1.js
β βββ example2.py
βββ scripts/ β Optional: Helper scripts
β βββ helper.sh
βββ templates/ β Optional: Code templates
β βββ template.tsx
βββ references/ β Optional: Reference documentation
β βββ api-docs.md
βββ README.md β Optional: Additional documentation
Key Rule: Only SKILL.md is required. Everything else is optional!
Every SKILL.md file has two main parts:
Letβs break down each part:
The frontmatter is at the very top, wrapped in ---:
---
name: my-skill-name
description: "Brief description of what this skill does"
category: development
risk: safe
source: community
source_type: community
date_added: "YYYY-MM-DD"
---
namestripe-integrationdescription"Stripe payment integration patterns including checkout, subscriptions, and webhooks"categorycategory: developmentriskValues: none |
safe |
critical |
offensive |
unknown |
risk: safenone β pure text/reasoning, no commands or mutationssafe β reads files, runs non-destructive commandscritical β modifies state, deletes files, pushes to productionoffensive β pentesting/red-team tools; must include βAuthorized Use Onlyβ warningunknown β legacy or unclassified; prefer a concrete level for new skillssourcesource: community, source: "https://example.com/original""self" if you are the original authorsource_repoOWNER/REPOsource_repo: Dimillian/Skillssource_typeValues: official |
community |
self |
source_type: official, source_type: communityself means no external README repo credit is requireddate_addedYYYY-MM-DDdate_added: "2026-03-06"Some skills include additional metadata:
---
name: my-skill-name
description: "Brief description"
category: development
risk: safe
source: community
source_type: community
date_added: "YYYY-MM-DD"
tags: ["react", "typescript", "testing"]
tools: [claude, cursor, gemini]
---
license (optional)MIT, Apache-2.0, CC-BY-4.0)license: MITsource_repo points to material under a known license. Omitting it signals βlicense not verifiedβ to downstream tooling.license_source (optional)license_source: "https://github.com/owner/repo/blob/main/LICENSE"license: so automated tooling can verify the claim. If the upstream repo has no LICENSE file, omit this field.source_repo and source_type.source_type: official means the repo must appear in README.md under ### Official Sources.source_type: community means the repo must appear in README.md under ### Community Contributors.source: self plus source_type: self is the correct shape for original repository content.data/source-credits.json ledger. Declare accurate provenance; ordinary new imports do not require hand-editing README credit sections. Custom descriptions and legacy corrections belong in the ledger. Canonical sync owns the rendered README blocks.After the frontmatter comes the actual skill content. Hereβs the recommended structure:
# Skill Title
## Overview
A brief explanation of what this skill does and why it exists.
2-4 sentences is perfect.
## When to Use This Skill
- Use when you need to [scenario 1]
- Use when working with [scenario 2]
- Use when the user asks about [scenario 3]
Why this matters: Helps the AI know when to activate this skill
## How It Works
### Step 1: [Action]
Detailed instructions...
### Step 2: [Action]
More instructions...
This is the heart of your skill - clear, actionable steps
## Examples
### Example 1: [Use Case]
```javascript
// Example code
```
### Example 2: [Another Use Case]
```javascript
// More code
```
Why examples matter: They show the AI exactly what good output looks like
## Best Practices
- β
Do this
- β
Also do this
- β Don't do this
- β Avoid this
## Common Pitfalls
- **Problem:** Description
**Solution:** How to fix it
If your skill includes:
add a dedicated section before final wrap-up:
## Security & Safety Notes
- This is safe/unsafe scope
- Required confirmation or authorization
- Example allowlist notes (if needed):
`<!-- security-allowlist: ... -->`
## Related Skills
- `@other-skill` - When to use this instead
- `@complementary-skill` - How this works together
β Bad:
You might want to consider possibly checking if the user has authentication.
β Good:
Check if the user is authenticated before proceeding.
β Bad:
The file should be created...
β Good:
Create the file...
β Bad:
Set up the database properly.
β Good:
1. Create a PostgreSQL database
2. Run migrations: `npm run migrate`
3. Seed initial data: `npm run seed`
If your skill needs helper scripts:
scripts/
βββ setup.sh β Setup automation
βββ validate.py β Validation tools
βββ generate.js β Code generators
Reference them in SKILL.md:
Run the setup script:
```bash
bash scripts/setup.sh
```
Real-world examples that demonstrate the skill:
examples/
βββ basic-usage.js
βββ advanced-pattern.ts
βββ full-implementation/
βββ index.js
βββ config.json
Reusable code templates:
templates/
βββ component.tsx
βββ test.spec.ts
βββ config.json
Reference in SKILL.md:
Use this template as a starting point:
```typescript
```
External documentation or API references:
references/
βββ api-docs.md
βββ best-practices.md
βββ troubleshooting.md
name, description, category, risk, source, date_added)name, description, category, risk, source, date_added)source_repo/source_type for external GitHub-derived skills and optional fields where usefulRule of thumb: Start small, expand based on feedback
Always specify the language:
```javascript
const example = "code";
```
Use consistent formatting:
- Item 1
- Item 2
- Sub-item 2.1
- Sub-item 2.2
**important***emphasis*Code for commands/code: `code`[Link text](https://example.com)
Before finalizing your skill:
Letβs analyze a real skill: brainstorming
---
name: brainstorming
description: "You MUST use this before any creative work..."
---
Analysis:
# Brainstorming Ideas Into Designs
## Overview
Help turn ideas into fully formed designs...
Analysis:
## The Process
**Understanding the idea:**
- Check out the current project state first
- Ask questions one at a time
Analysis:
## Instructions
If the user is working with React:
- Use functional components
- Prefer hooks over class components
If the user is working with Vue:
- Use Composition API
- Follow Vue 3 patterns
## Basic Usage
[Simple instructions for common cases]
## Advanced Usage
[Complex patterns for power users]
## Related Workflows
1. First, use `@brainstorming` to design
2. Then, use `@writing-plans` to plan
3. Finally, use `@test-driven-development` to implement
How to know if your skill is good:
For Beginners:
skills/brainstorming/SKILL.md - Clear structureskills/git-pushing/SKILL.md - Simple and focusedskills/copywriting/SKILL.md - Good examplesFor Advanced:
skills/systematic-debugging/SKILL.md - Comprehensiveskills/react-best-practices/SKILL.md - Multiple filesskills/loki-mode/SKILL.md - Complex workflows## Instructions
Make the code better.
β Fix:
## Instructions
1. Extract repeated logic into functions
2. Add error handling for edge cases
3. Write unit tests for core functionality
## Instructions
[5000 words of dense technical jargon]
β Fix: Break into multiple skills or use progressive disclosure
## Instructions
[Instructions without any code examples]
β Fix: Add at least 2-3 realistic examples
Use React class components...
β Fix: Keep skills updated with current best practices
../../CONTRIBUTING.mdRemember: Every expert was once a beginner. Start simple, learn from feedback, and improve over time! π