Testing and distributing skills
Iterate on skills, share with your team
⏱ Est. ~6 min
01 · Read
Writing a skill is only half the work. You need to test it — and iterate.
A skill that looks right on paper might produce inconsistent results in practice. Maybe Claude follows 4 of your 5 rules and misses one. Maybe its interpretation of an ambiguous instruction differs from yours.
The test loop is simple: activate the skill, give Claude a task that should trigger it, check whether the output follows your rules, refine the skill if it doesn't.
Like code, skills get better through iteration. Most skills need 2-3 rounds of refinement before they work consistently.
Key points
- Test skills by activating with /skill and giving Claude a relevant task
- Check the output against every rule in the skill body
- Test edge cases — what happens with unusual input?
- Iterate: most skills need 2-3 rounds of refinement
- Version-control your skills with git — they're just files
02 · Step-through
Follow this process every time you create or update a skill.
1. Create or update the skill
Write or edit your SKILL.md file. Save it to .claude/skills/your-skill/SKILL.md. If you're updating, change one thing at a time so you can see the effect.
2. Activate with /skill
In a Claude Code conversation, type /skill and pick your skill from the list. Claude now loads your instructions and follows them for the rest of the conversation.
3. Give Claude a relevant task
Ask Claude to do something that should trigger your skill's rules. For a code review skill, ask it to review code. For a commit message skill, ask it to commit. Use real input, not toy examples.
4. Check the output
Does the output follow every rule in your skill? Walk through every bullet, every format requirement, every constraint. Be thorough — partial matches mean the skill needs refinement.
5. Refine and repeat
If something's off, update the skill body. Be more specific where Claude went off track. Add examples of correct output. Remove vague wording. Then test again with the same task.
6. Commit with git
Once the skill works consistently across multiple test cases, commit it. Skills are just files — they belong in version control like everything else. git add .claude/skills/ && git commit -m 'feat: add code-reviewer skill'
03 · Read
Once a skill works consistently, decide where it lives. In the first lesson you learned there are two locations: Project skills (.claude/skills/) are committed to git and shared with the team, and user skills (~/.claude/skills/) are personal and apply across all your projects.
The rule is simple: if it's a team convention, commit it as a project skill. If it's a personal preference, keep it as a user skill.
Key points
- Project skills: commit to git → the whole team benefits
- User skills: stay local → personal preferences only
- Commit project skills like any other code change
04 · Quiz
You just built a skill that enforces your team's commit message format: every commit must start with a type prefix like 'feat:' or 'fix:'. Should this be a project skill or a user skill?
- Project skill — it's a team convention, commit it to git
- User skill — keep in ~/.claude/skills/ for personal use
- Either works
- It should be in a config file, not a skill
05 · Fill in the blank
Skills stored in ~/.claude/skills/ are called _____ skills, because they follow you across all projects.
Other lessons in this chapter
⚠ The full interactive experience needs JavaScript. Please enable it and reload.
※ This is an independent Traditional Chinese teaching project — not an official Anthropic product. Claude™ is a trademark of Anthropic, PBC.