skill-creator

name	skill-creator
description	创建新skills、修改和改进现有skills。当用户希望创建新skills、更新或优化现有skills、验证skills格式、打包skills为可分发文件时使用。触发词：'创建一个skill'、'写一个skill'、'新建skill'、'帮我做一个skill让它xxx'、'修改skill'、'更新skill'。

Skill Creator

A skill for creating new skills and iteratively improving them.

At a high level, the process of creating a skill goes like this:

• Decide what you want the skill to do and roughly how it should do it
• Write a draft of the skill
• Validate the skill format using {skill_base_dir}/scripts/quick_validate.py
• Package the skill using {skill_base_dir}/scripts/package_skill.py for distribution
• Help the user refine the skill based on their feedback
• Repeat until you're satisfied

Your job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like "I want to make a skill for X". You can help narrow down what they mean, write a draft, validate the format, package it for distribution.

On the other hand, maybe they already have a draft of the skill. In this case you can go straight to validation and packaging.

Of course, you should always be flexible and if the user is like "I don't need to run a bunch of validations, just help me write it", you can do that instead.

Cool? Cool.

Communicating with the user

The skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google "how to install npm". On the other hand, the bulk of users are probably fairly computer-literate.

So please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:

• "validation" and "format" are borderline, but OK
• for "JSON" and "assertion" you want to see serious cues from the user that they know what those things are before using them without explaining them

It's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.

---

Creating a skill

Capture Intent

Start by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say "turn this into a skill"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.

1. What should this skill enable Claude to do?
2. When should this skill trigger? (what user phrases/contexts)
3. What's the expected output format?

Interview and Research

Proactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write skill content until you've got this part ironed out.

Check available resources - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.

Write the SKILL.md

Based on the user interview, fill in these components:

• name: Skill identifier
• description: When to trigger, what it does. This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All "when to use" info goes here, not in the body. Note: currently Claude has a tendency to "undertrigger" skills -- to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit "pushy". So for instance, instead of "How to build a simple fast dashboard to display internal Anthropic data.", you might write "How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'"
• compatibility: Required tools, dependencies (optional, rarely needed)
• the rest of the skill :)

Skill Writing Guide

Anatomy of a Skill

skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (name, description required)
│   └── Markdown instructions
└── Bundled Resources (optional)
    ├── scripts/    - Executable code for deterministic/repetitive tasks
    ├── references/ - Docs loaded into context as needed
    └── assets/     - Files used in output (templates, icons, fonts)

Path References with {skill_base_dir}

Always use the {skill_base_dir} placement when referencing files within your skill directory.

The {skill_base_dir} placement is automatically replaced with the absolute path of your skill directory when the skill is loaded. This ensures your skill works reliably across different environments (project/user/system).

Why use {skill_base_dir}?

• Portable: Skills work in any environment without modification
• Reliable: No dependency on model understanding or working directory
• Maintainable: No need to hardcode absolute paths

When to use {skill_base_dir}:

• Referencing script files in scripts/
• Referencing template files in templates/
• Referencing reference docs in references/
• Referencing any resource files in assets/

Do NOT use {skill_base_dir} for:

• User project files (use absolute paths or relative to project root)
• System paths
• External URLs

Good examples:

## Resources

- Script: `{skill_base_dir}/scripts/analyze.py`
- Template: `{skill_base_dir}/templates/report.md`
- Reference: `{skill_base_dir}/references/api.md`

## Usage

Execute the analysis script:
```bash
python {skill_base_dir}/scripts/analyze.py

Read configuration:

read("{skill_base_dir}/config/settings.json")

**Bad examples**:
```markdown
- Scripts: ./scripts/  ❌ Don't use relative paths
- Execute: python /absolute/path/to/scripts/analyze.py  ❌ Don't hardcode absolute paths
- Template: $SKILL_DIR/templates/report.md  ❌ Don't use environment variables

Common mistakes to avoid:

• Using ./scripts/ instead of {skill_base_dir}/scripts/
• Using /absolute/path/to/scripts/analyze.py instead of {skill_base_dir}/scripts/analyze.py
• Using {SkillBaseDir} (uppercase) - must be lowercase
• Using {skill_base_dir}\ (Windows-style) - must use Unix-style /
• Using $skill_base_dir (environment variable) - must use curly braces {}

Placement syntax rules:

• Must use curly braces: {skill_base_dir}
• Must be lowercase with underscores
• Must be followed by path separator / (Unix-style)
• Will be automatically converted to platform-specific format
• Example: {skill_base_dir}/scripts/analyze.py

Valid examples:

{skill_base_dir}/scripts/analyze.py
{skill_base_dir}/assets/template.json
{skill_base_dir}/references/api.md
{skill_base_dir}/

Invalid examples:

SkillBaseDir/scripts/analyze.py  (missing curly braces)
skill_base_dir\scripts\analyze.py  (Windows-style, use /)
skill_base_dirscripts/analyze.py  (missing separator)
$skill_base_dir/scripts/analyze.py  (using $ symbol)

Important: The {skill_base_dir} placement is only replaced in the SKILL.md file content. It is NOT replaced in:

• Script files (scripts/*.py)
• Reference files (references/*.md)
• Asset files (assets/*)
• Any other bundled resources

If you need to use the skill base path in scripts, pass it as a command-line argument or configuration file.

Progressive Disclosure

Skills use a three-level loading system:

1. Metadata (name + description) - Always in context (~100 words)
2. SKILL.md body - In context whenever skill triggers (<500 lines ideal)
3. Bundled resources - As needed (unlimited, scripts can execute without loading)

These word counts are approximate and you can feel free to go longer if needed.

Key patterns:

• Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.
• Reference files clearly from SKILL.md with guidance on when to read them
• For large reference files (>300 lines), include a table of contents

Domain organization: When a skill supports multiple domains/frameworks, organize by variant:

cloud-deploy/
├── SKILL.md (workflow + selection)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

Claude reads only the relevant reference file.

Principle of Lack of Surprise

Skills must not contain malware, exploit code, or content that could compromise system security. A Skill's behavior must match its stated task workflow. Do not create misleading Skills or Skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Persona and identity belong to digital employees, not Skills.

Writing Patterns

Prefer using the imperative form in instructions.

Defining output formats - You can do it like this:

## Report structure
ALWAYS use this exact template:
# [Title]
## Executive summary
## Key findings
## Recommendations

Examples pattern - It's useful to include examples. You can format them like this (but if "Input" and "Output" are in the examples you might want to deviate a little):

## Commit message format
**Example 1:**
Input: Added user authentication with JWT tokens
Output: feat(auth): implement JWT-based authentication

Writing Style

Try to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.

---

Validating and packaging skills

Step 1: Validate skill format

Before distributing a skill, validate its format using the validation script:

python -m scripts.quick_validate <skill-directory>

This checks:

• SKILL.md exists and has valid YAML frontmatter
• Required fields (name, description) are present
• Name follows kebab-case convention
• Description doesn't contain angle brackets
• Field length limits are respected

Step 2: Package skill for distribution

Once validated, package the skill into a distributable .skill file:

python -m scripts.package_skill <skill-directory> [output-directory]

This creates a .skill file (zip format) containing the skill directory, excluding:

• __pycache__/, node_modules/ directories
• *.pyc files
• .DS_Store files
• evals/ directory at skill root

The packaged .skill file can be shared and installed by other users.

---

Improving the skill

This is the heart of the loop. You've written the skill, validated it, and now you need to make the skill better based on user feedback.

How to think about improvements

1. Generalize from the feedback. The big picture thing that's happening here is that we're trying to create skills that can be used a million times (maybe literally, maybe even more who knows) across many different prompts. Here you and the user are iterating on only a few examples over and over again because it helps move faster. The user knows these examples in and out and it's quick for them to assess new outputs. But if the skill you and the user are codeveloping works only for those examples, it's useless. Rather than put in fiddly overfitty changes, or oppressively constrictive MUSTs, if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working. It's relatively cheap to try and maybe you'll land on something great.

2. Keep the prompt lean. Remove things that aren't pulling their weight. Make sure to read the transcripts, not just the final outputs — if it looks like the skill is making the model waste a bunch of time doing things that are unproductive, you can try getting rid of the parts of the skill that are making it do that and seeing what happens.

3. Explain the why. Try hard to explain the why behind everything you're asking the model to do. Today's LLMs are smart. They have good theory of mind and when given a good harness can go beyond rote instructions and really make things happen. Even if the feedback from the user is terse or frustrated, try to actually understand the task and why the user is writing what they wrote, and what they actually wrote, and then transmit this understanding into the instructions. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.

4. Look for repeated work across examples. Read the transcripts from the skill runs and notice if there are repeated patterns. If all 3 examples resulted in the subagent writing a create_docx.py or a build_chart.py, that's a strong signal the skill should bundle that script. Write it once, put it in scripts/, and tell the skill to use it. This saves every future invocation from reinventing the wheel.

This task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over. I'd suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.

The iteration loop

After improving the skill:

1. Apply your improvements to the skill
2. Re-validate the skill format
3. Re-package if needed

Keep going until:

• The user says they're happy
• The validation passes

---

Reference files

The references/ directory has additional documentation:

• {skill_base_dir}/references/schemas.md — JSON structures for SKILL.md frontmatter

---

Repeating one more time the core loop here for emphasis:

• Figure out what the skill is about
• Draft or edit the skill
• Validate the skill format using quick_validate.py
• Package the skill using package_skill.py for distribution
• Repeat until you and the user are satisfied

Good luck!