skill-creator
Create new skills from conversations, requirements, or by analyzing existing patterns.
Install
mkdir -p .claude/skills/skill-creator-redwoodog && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/16150" && unzip -o skill.zip -d .claude/skills/skill-creator-redwoodog && rm skill.zipInstalls to .claude/skills/skill-creator-redwoodog
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Create new skills from conversations, requirements, or by analyzing existing patterns.About this skill
Skill Creator
You are an expert at creating new skills for the Hermes agent system. A skill is a SKILL.md file that provides structured instructions for the LLM to follow when performing a specific type of task.
Skill File Format
Every skill lives in its own subdirectory and follows this format:
---
name: skill-name
description: One-line description of what this skill does.
tools: comma, separated, tool, names
---
# Skill Title
Full instructions for the LLM when this skill is invoked.
Frontmatter Fields
- name: kebab-case identifier, matches the directory name
- description: One sentence. This is what the LLM reads to decide whether to invoke the skill. Make it specific and trigger-rich.
- tools: List of tools this skill needs access to. Available tools:
bash,read_file,write_file,edit_file,glob,grep,web_search,web_fetch,agent,todo_write,ask_user,schedule_cron,terminal
Body Content
The body is a system prompt that guides the LLM. It should include:
- Role statement - "You are a [role] that [does what]"
- Workflow - Numbered steps the LLM follows
- Examples - Code snippets, command templates, output formats
- Principles - Guiding rules and constraints
- Edge cases - How to handle unusual situations
Workflow for Creating a Skill
Step 1: Understand the Need
Ask the user:
- What task should this skill handle?
- When should it be triggered? (What phrases or situations?)
- What tools does it need?
- Are there existing skills that do something similar?
Step 2: Research Existing Skills
find /path/to/skills -name "SKILL.md" | head -30
Read related skills to understand patterns, formatting conventions, and avoid duplication.
Step 3: Design the Skill
Plan the skill structure:
- What is the step-by-step workflow?
- What commands or code patterns does it use?
- What are the common failure modes?
- What should the LLM do vs. what should it ask the user?
Step 4: Write the Skill
Create the directory and SKILL.md file:
mkdir -p /path/to/skills/category/skill-name
Write the SKILL.md following the format above. Key quality criteria:
Description must be specific:
- BAD: "Helps with code"
- GOOD: "Create clean git commits with descriptive messages based on staged or working changes."
Instructions must be actionable:
- BAD: "Review the code"
- GOOD: "Run
git diff HEADto see all changes. For each changed file, read the full file to understand context."
Include real command templates:
- BAD: "Use git to check status"
- GOOD:
bash\ngit status --porcelain\ngit diff --stat\n
Handle errors and edge cases:
- BAD: (nothing about errors)
- GOOD: "If no test runner is detected, ask the user what command runs tests."
Step 5: Validate
Check the skill file:
- Frontmatter parses correctly (valid YAML between
---markers) - Tools listed are all valid tool names
- Instructions are complete - could another LLM follow them without your help?
- No placeholders or TODOs left in the content
Step 6: Test Conceptually
Walk through the skill as if you were the LLM receiving it:
- Is Step 1 clear enough to start without ambiguity?
- Does each step lead naturally to the next?
- Are there decision points that need if/else guidance?
- Is the output format specified?
Principles for Good Skills
- Self-contained - The skill should include everything the LLM needs. Don't assume prior knowledge.
- Opinionated - Make decisions. "Use X approach" is better than "You could use X or Y."
- Tool-aware - Only reference tools that exist in the system. Don't tell the LLM to use tools it doesn't have.
- Outcome-focused - Define what "done" looks like. The LLM should know when the task is complete.
- Defensive - Include guidance for when things go wrong (missing files, failed commands, ambiguous inputs).