| name | skillMaker |
| description | Create new Claude Code skills following best practices. Use when user asks to "create a skill", "criar skill", "criar um skill", "make a new skill", "build a skill", "generate skill", "gerar skill", "novo skill", "new skill", "custom skill", "skill personalizado", mentions "skill maker", "skillMaker", "skill generator", "gerador de skill", discusses "creating Claude Code automations", "criar automação", "build automation", "skill development", "desenvolvimento de skill", "skill creation", "criação de skill", wants help "building custom Claude skills", "construir skills", "design a skill", "desenhar skill", or asks about "how to make a skill", "como criar skill", "skill template", "template de skill", "skill structure", "estrutura de skill", "skill patterns", "padrões de skill". |
| version | 1.1.0 |
| allowed-tools | Read, Write, Edit, Glob, Bash |
Skill Maker - Claude Code Skill Generator
Create production-ready Claude Code skills following established patterns and best practices.
Overview
This skill guides you through creating well-structured, effective Claude Code skills by:
- Understanding the skill's purpose and trigger conditions
- Gathering requirements through targeted questions
- Generating appropriate file structure and content
- Following optimization patterns and conventions
When This Skill Activates
Use this skill when the user wants to:
- Create a new Claude Code skill from scratch
- Understand skill structure and patterns
- Generate skill templates with best practices
- Convert manual workflows into reusable skills
Skill Creation Workflow
Phase 1: Requirements Gathering
Ask the user these key questions (use AskUserQuestion for efficiency):
-
Purpose & Trigger
- What should this skill do?
- When should Claude invoke it automatically?
- What phrases or keywords would users say to trigger it?
-
Invocation Control
- Who can invoke it?
- Both user and Claude (default)
- User-only (for side-effect tasks: deploy, commit, delete)
- Claude-only (for background knowledge/reference)
-
Argument Pattern
- Does it need arguments? (e.g.,
/migrate-component SearchBar React Vue)
- If yes, what are they and how should they be used?
-
Tool Requirements
- What tools will it need? (Read, Write, Edit, Bash, Grep, Glob, Agent, etc.)
- Should tool access be restricted for safety?
-
Complexity Level
- Simple reference skill (conventions, patterns)
- Task workflow skill (multi-step process)
- Dynamic context skill (uses shell commands)
- Bundled skill (includes templates, scripts, examples)
-
Execution Context
- Inline in main conversation (default)
- Isolated subagent (
context: fork)
- Specific agent type (
agent: Explore)
Phase 2: Structure Decision
Based on requirements, determine file structure:
Simple skill (reference/conventions):
.claude/skills/skill-name/
└── SKILL.md
Bundled skill (with supporting files):
.claude/skills/skill-name/
├── SKILL.md # Main instructions
├── templates/ # Templates for generation
│ └── template.md
├── examples/ # Example outputs
│ └── example.md
├── references/ # Detailed reference docs
│ └── patterns.md
└── scripts/ # Helper scripts
└── helper.sh
Phase 3: Content Generation
Generate skill content following these patterns:
A. Frontmatter Configuration
---
name: skill-name
description: |
[Action] when user asks to "[phrase]",
"[another phrase]", mentions "[keyword]",
or discusses [topic].
version: 1.0.0
disable-model-invocation: true
user-invocable: false
allowed-tools: Read, Grep, Glob
model: claude-3-5-haiku
context: fork
agent: Explore
---
Description Writing Formula:
- Start with verb: "Create", "Analyze", "Generate", "Review"
- Include specific trigger phrases users would say
- List relevant keywords
- Mention the domain/topic area
Examples:
description: Generate API documentation from code. Use when user asks to "document the API", "create API docs", mentions "OpenAPI" or "Swagger", or discusses API documentation needs.
description: Helps with documentation tasks.
B. Main Content Structure
Follow this template for SKILL.md body:
# [Skill Name] - [One-line Purpose]
[2-3 sentence overview of what this skill does and its value]
## Overview
[Detailed explanation of the skill's capabilities and when to use it]
## When This Skill Activates
[List specific scenarios that trigger this skill]
## Workflow / Process
[Step-by-step instructions if it's a task skill]
### Phase 1: [First Phase Name]
[Instructions for first phase]
### Phase 2: [Second Phase Name]
[Instructions for second phase]
## Guidelines / Patterns
[Best practices, conventions, or patterns to follow]
## Examples
[Include 2-3 concrete examples if relevant]
## Supporting Files
[Reference any templates, examples, or scripts]
- For [use case], see [file-name.md](file-name.md)
- Script for [action]: `${CLAUDE_SKILL_DIR}/scripts/helper.sh`
## Common Patterns
[Include reusable patterns or code snippets]
## Optimization Tips
[Performance or quality improvements]
C. Supporting Files
When to create supporting files:
-
templates/ - Create when:
- Skill generates structured output (API docs, test files, configs)
- Users need consistent format across invocations
- Content follows a repeatable pattern
-
examples/ - Create when:
- Complex output that benefits from reference
- Multiple valid approaches to show
- Helping users understand expected results
-
references/ - Create when:
- Detailed reference material (>500 lines)
- Technical specifications or API docs
- Comprehensive pattern libraries
- Keep main SKILL.md focused, reference these for details
-
scripts/ - Create when:
- Preprocessing data before Claude sees it
- Complex calculations or transformations
- External tool integration
- File system operations
Reference linking pattern:
## Additional Resources
For complete details, see:
- API patterns: [references/api-patterns.md](references/api-patterns.md)
- Code examples: [examples/sample-output.md](examples/sample-output.md)
- Generation template: [templates/component-template.md](templates/component-template.md)
- Preprocessing script: `${CLAUDE_SKILL_DIR}/scripts/analyze.sh`
D. Dynamic Context Injection
Use shell command substitution for live data:
## Current Project Context
- Repository: !`git remote get-url origin 2>/dev/null || echo "No git remote"`
- Current branch: !`git branch --show-current 2>/dev/null || echo "Not a git repo"`
- Recent commits: !`git log --oneline -3 2>/dev/null || echo "No commits"`
- Staged files: !`git diff --cached --name-only 2>/dev/null || echo "No staged files"`
## Dependencies
- Node version: !`node --version 2>/dev/null || echo "Node not installed"`
- Package manager: !`[ -f "package-lock.json" ] && echo "npm" || [ -f "yarn.lock" ] && echo "yarn" || [ -f "pnpm-lock.yaml" ] && echo "pnpm" || echo "Unknown"`
Command patterns for common needs:
| Need | Command Pattern |
|---|
| Git status | git status --short |
| Recent commits | git log --oneline -N |
| Changed files | git diff --name-only |
| PR info | gh pr view --json title,body 2>/dev/null || echo "Not in a PR" |
| Project type | ls package.json pyproject.toml go.mod |
| Dependencies | cat package.json | jq '.dependencies' |
| File count | find src -name "*.js" | wc -l |
Phase 4: Optimization
Apply these optimizations:
A. Context Efficiency
- Keep SKILL.md under 500 lines
- Move detailed references to separate files
- Use dynamic injection for live data
- Reference supporting files explicitly
B. Tool Restrictions
allowed-tools: Read, Grep, Glob
allowed-tools: Read, Write, Edit
allowed-tools: Read, Write, Edit, Bash(npm *), Bash(git *)
C. Invocation Control
disable-model-invocation: true
user-invocable: false
D. Execution Context
context: fork
agent: Explore
context: fork
Phase 5: Testing & Validation
After generating the skill, validate:
- Frontmatter syntax - Valid YAML
- Description clarity - Specific trigger conditions
- File references - All referenced files exist
- Shell commands - Valid syntax in dynamic injection blocks
- Tool alignment - allowed-tools matches actual needs
- Invocation logic - Flags match intended behavior
Test invocation:
/skill-name arg1 arg2
Skill Templates by Category
Template 1: Reference/Conventions Skill
---
name: coding-standards
description: Apply coding standards and conventions. Use when writing code, reviewing code, or when user asks about "code style", "conventions", or "standards".
user-invocable: false
---
Apply these conventions when writing code:
- Variables: camelCase
- Constants: UPPER_SNAKE_CASE
- Classes: PascalCase
[patterns...]
[guidelines...]
Template 2: Task Workflow Skill
---
name: create-feature
description: Create a new feature following project standards. Use when user asks to "add a feature", "create new feature", "implement feature", or discusses adding functionality.
disable-model-invocation: true
allowed-tools: Read, Write, Edit, Bash
---
Create a complete feature following project patterns.
1. Read existing similar features
2. Identify files to modify/create
3. Confirm approach with user
1. Create feature files
2. Add tests
3. Update documentation
1. Run tests
2. Check formatting
3. Create commit
$0 - Feature name (kebab-case)
$1 - Feature type (component|page|api)
Template 3: Dynamic Context Skill
---
name: pr-summarizer
description: Summarize pull request changes. Use when user asks to "summarize PR", "explain changes", mentions "pull request summary", or discusses PR content.
allowed-tools: Bash(gh *)
---
- Title: !`gh pr view --json title -q .title 2>/dev/null || echo "Not in a PR context"`
- Author: !`gh pr view --json author -q .author.login 2>/dev/null || echo "N/A"`
- Status: !`gh pr view --json state -q .state 2>/dev/null || echo "Unknown"`
!`gh pr diff 2>/dev/null || echo "No PR diff available"`
Analyze the PR and provide:
1. High-level summary (2-3 sentences)
2. Key changes by file
3. Potential impacts
4. Testing recommendations
Template 4: Bundled Skill with Templates
---
name: api-documenter
description: Generate API documentation from code. Use when user asks to "document API", "create API docs", mentions "OpenAPI" or "Swagger", or discusses API documentation.
allowed-tools: Read, Write, Bash
---
Generate comprehensive API documentation.
Use these templates for structured output:
- OpenAPI spec: [templates/openapi.yaml](templates/openapi.yaml)
- Endpoint docs: [templates/endpoint.md](templates/endpoint.md)
1. Scan for API routes
2. Extract endpoint details
3. Generate documentation using templates
4. Validate with: `${CLAUDE_SKILL_DIR}/scripts/validate-openapi.sh`
See [examples/sample-api-docs.md](examples/sample-api-docs.md) for expected format.
Generation Checklist
Before finalizing, verify:
Installation & Usage
After creating the skill:
-
Save to correct location:
- Project:
.claude/skills/skill-name/SKILL.md
- Personal:
~/.claude/skills/skill-name/SKILL.md
-
Test invocation:
/skill-name [arguments]
-
Verify activation:
- Check skill appears in
/ autocomplete
- Verify description triggers work
- Test with and without arguments
Best Practices Recap
DO:
- Write specific, trigger-rich descriptions
- Keep SKILL.md focused and under 500 lines
- Use supporting files for complex content
- Restrict tools when possible for safety
- Use dynamic context for live data
- Include concrete examples
- Test trigger phrases
DON'T:
- Write vague descriptions ("helps with tasks")
- Put everything in one huge SKILL.md
- Forget to reference supporting files
- Over-restrict tools unnecessarily
- Hardcode data that can be dynamic
- Create skills with overlapping triggers
- Skip testing invocation patterns
Common Patterns Library
Pattern: Multi-Argument Skill
Fix $0 by $1 in $2 files.
Pattern: Optional Arguments
Generate tests for ${1:-all components}.
Pattern: Conditional Logic
!`[ -f "package.json" ] && cat package.json || echo "{}"`
Pattern: Error Handling
!`git status 2>/dev/null || echo "Not a git repository"`
Skill Quality Metrics
Evaluate skill quality:
| Metric | Good | Needs Improvement |
|---|
| Description | 3+ trigger phrases, specific keywords | Generic, vague |
| Size | < 500 lines in SKILL.md | > 500 lines, no supporting files |
| Structure | Organized sections, clear flow | Wall of text, unclear |
| References | Explicitly linked supporting files | References missing |
| Examples | 2-3 concrete examples | No examples or too abstract |
| Dynamic context | Uses shell injection for live data | All static content |
| Tool restrictions | Aligned with actual needs | Too broad or too narrow |
Troubleshooting
Skill doesn't auto-trigger:
- Check description has specific trigger phrases
- Verify no
disable-model-invocation: true flag
- Test with exact phrases from description
Skill not in autocomplete:
- Verify SKILL.md in correct location
- Check frontmatter YAML is valid
- Ensure no
user-invocable: false flag
Shell commands fail:
- Verify dynamic injection syntax (backticks with exclamation prefix)
- Add error handling with
|| echo "fallback"
- Check commands available in user's environment
Related Tools
- Hooks: For automatic actions on tool events
- Subagents: For parallel execution and isolation
- Plugins: For bundling multiple related skills
- MCP Servers: For external tool integration
Supporting Files
For detailed skill patterns and examples: