| name | skill-creator |
| description | Create new Claude Code skills with proper structure and best practices. Use when building a new skill, understanding skill architecture, or deciding between skills vs prompts vs CLAUDE.md. Use when this capability is needed. |
| metadata | {"author":"dimitri-vs"} |
Skill Creation Guide
This skill helps you create well-structured Claude Code skills following official best practices.
When to Create a Skill
| Use Case | Solution |
|---|
| One-off task instruction | Just tell Claude in the conversation |
| Project-wide context | Add to CLAUDE.md |
| Repeatable workflow across projects | Create a Skill |
| Domain expertise that loads on-demand | Create a Skill |
| Composable capability with scripts/templates | Create a Skill |
Key insight: Skills load on-demand via progressive disclosure. CLAUDE.md loads every conversation. Use skills for domain expertise you don't always need.
Required Structure
Every skill needs a directory with at minimum a SKILL.md file:
skill-name/
└── SKILL.md
SKILL.md Format
---
name: skill-name
description: What this skill does and WHEN to use it. Claude uses this to decide when to invoke the skill automatically.
---
[Step-by-step guidance for Claude to follow]
[Concrete examples of using this skill]
Field Requirements
name (required):
- Max 64 characters
- Lowercase letters, numbers, hyphens only
- No reserved words: "anthropic", "claude"
description (required):
- Max 1024 characters
- Must explain both WHAT and WHEN
- Claude uses this to decide when to invoke
Optional Frontmatter
---
name: skill-name
description: Description here
disable-model-invocation: true
user-invocable: false
allowed-tools: Read, Grep, Glob
context: fork
agent: Explore
---
Invocation Control Matrix
| Setting | User /skill | Claude Auto | Use For |
|---|
| (default) | Yes | Yes | General-purpose skills |
disable-model-invocation: true | Yes | No | Side effects (deploy, email) |
user-invocable: false | No | Yes | Background knowledge |
Progressive Disclosure (3 Levels)
Skills load content in stages to minimize token usage:
| Level | When Loaded | Token Cost | Content |
|---|
| 1. Metadata | Always (startup) | ~100 tokens | name + description only |
| 2. Instructions | When triggered | <5k tokens | SKILL.md body |
| 3. Resources | As needed | Unlimited | Scripts, templates, reference files |
Implication: You can bundle extensive reference materials without token penalty until actually used.
Adding Resources
For complex skills, add additional files:
skill-name/
├── SKILL.md # Main instructions (required)
├── REFERENCE.md # Additional docs (loaded when referenced)
├── templates/
│ └── template.yaml # Templates to apply
└── scripts/
└── validate.sh # Scripts Claude can execute
Reference these in SKILL.md:
For API details, see [REFERENCE.md](REFERENCE.md).
Use the template in [templates/template.yaml](templates/template.yaml).
Dynamic Context Injection
Use backtick commands to inject live data before the skill runs:
- Branch: !`git branch --show-current`
- Status: !`git status --short`
The command output replaces the placeholder before Claude sees the content.
Arguments Pattern
Skills can receive arguments when invoked:
Generate documentation for: $ARGUMENTS
When user runs /skill-name src/utils.ts, $ARGUMENTS becomes src/utils.ts.
Best Practices
-
Keep it focused - One workflow per skill. Multiple focused skills compose better than one large skill.
-
Write clear descriptions - Claude uses the description to decide when to invoke. Be specific about triggers.
-
Start simple - Begin with basic instructions in Markdown before adding scripts.
-
Use examples - Include example inputs/outputs so Claude understands success.
-
Test incrementally - Test after each change rather than building complex skills all at once.
-
Tool docstrings matter - If your skill references scripts, their docstrings help Claude understand usage.
-
Avoid secrets - Never hardcode API keys or passwords.
Example: API Documentation Skill
api-doc/
├── SKILL.md
└── openapi-template.yaml
SKILL.md:
---
name: api-doc
description: Generate OpenAPI documentation for an endpoint. Use when documenting API routes or creating API specs.
---
Generate OpenAPI documentation for the endpoint at $ARGUMENTS.
Use the template in [openapi-template.yaml](openapi-template.yaml) as the structure.
1. Read the endpoint code
2. Extract path, method, parameters, request/response schemas
3. Fill in the template with actual
Example: Deploy Skill (User-Only)
---
name: deploy-staging
description: Deploy current branch to staging environment
disable-model-invocation: true
---
- Branch: !`git branch --show-current`
- Status: !`git status --short`
1. Verify all changes are committed
2. Run `railway up --detach` from the correct directory
3. Monitor logs: `timeout 10 railway logs`
4. Report deployment status
Example: Background Knowledge Skill
---
name: project-conventions
description: Code style and patterns for this project. Apply when writing or reviewing code.
user-invocable: false
---
- Components: PascalCase
- Utilities: camelCase
- Files: kebab-case
- Use `Result<T, E>` for fallible operations
- All API responses: `{ data, error, meta }`
- No `any` types
- No `console.log` in production
References
Converted and distributed by TomeVault — claim your Tome and manage your conversions.