feat: add meta-skill create-skill for creating and improving skills

Two modes: Create (gather requirements, generate SKILL.md) and Improve
(diagnose existing skill against best practices, propose changes).
Includes bundled references for frontmatter spec and writing guide.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
olekhondera
2026-03-06 18:24:55 +02:00
parent 9931269907
commit ea21818f76
3 changed files with 298 additions and 0 deletions

View File

@@ -0,0 +1,83 @@
# Frontmatter Specification
Complete reference for SKILL.md YAML frontmatter fields.
## Required Fields
### `name`
- Lowercase-hyphen format: `my-skill-name`
- Max 64 characters
- Must be unique across all skill directories
- Becomes the slash command: `/my-skill-name`
### `description`
- One sentence, under 200 characters
- Should be slightly "pushy" — describe WHEN to use the skill, not just what it does
- Include trigger contexts so the model selects the skill proactively
- Good: "Scaffold a new React component with TypeScript, accessibility, all states, and variant support via cva."
- Bad: "Creates components."
- Pattern: `[Action verb] [what] — [key details]. Use when [trigger contexts].`
## Optional Fields
### `disable-model-invocation`
- `true` — skill only runs when user invokes via `/name`
- `false` (default) — model can auto-invoke when description matches user intent
- Project convention: always set to `true`
### `user-invocable`
- `true` (default) — appears as a slash command
- `false` — background knowledge only, used as reference by other skills
### `argument-hint`
- Shown in autocomplete: `/skill-name [hint]`
- Use brackets for placeholders: `"[file-or-directory]"`, `"[ComponentName]"`
- Omit if the skill takes no arguments
### `context`
- `fork` — runs in a forked context (separate conversation branch)
- Use for: standalone deliverables, analysis reports, code generation that doesn't need follow-up
- The skill gets its own clean context with only the skill instructions
- Omit (no fork) — runs in the main conversation context
- Use for: interactive workflows, multi-step conversations, skills that need conversation history
- When omitted, `agent` field should also be omitted
Decision tree:
1. Does the skill need conversation history? → no fork
2. Does the skill ask the user questions mid-flow? → no fork
3. Does the skill produce a single standalone output? → fork
4. Is it a one-shot analysis or generation? → fork
### `agent`
- Assigns a specialized agent persona. Only meaningful with `context: fork`.
- Available agents:
| Agent | Use for |
|---|---|
| `frontend-architect` | UI, components, CSS, accessibility, browser APIs |
| `backend-architect` | APIs, databases, server logic, system design |
| `code-reviewer` | Code review, quality analysis, diff review |
| `test-engineer` | Test writing, test strategy, coverage analysis |
| `security-auditor` | Security audit, threat modeling, vulnerability analysis |
| `prompt-engineer` | Prompt design, LLM configuration, prompt evaluation |
| `documentation-expert` | Documentation, ADRs, technical writing |
- Omit when: no fork, or skill doesn't fit a specific domain
### `allowed-tools`
- Restrict which tools the skill can use
- Comma-separated list: `allowed-tools: Read, Grep, Glob`
- Omit to allow all tools (default)
### `model`
- Override the model for this skill
- Example: `model: claude-sonnet-4-6`
- Omit to use the default model
### `hooks`
- Lifecycle event handlers (pre/post execution)
- Rarely needed for most skills
### `compatibility`
- Declare dependencies or requirements
- Example: `compatibility: node>=18`

View File

@@ -0,0 +1,96 @@
# Skill Writing Guide
Best practices for writing effective Claude Code skills.
## Two Categories of Skills
1. **Capability uplift** — teaches the agent something it couldn't do before (scaffold component, run audit, deploy)
2. **Encoded preference** — captures your specific way of doing something the agent could already do (commit style, review checklist, naming conventions)
Know which you're building — it changes how much detail to include.
## Description Optimization
The description is the most important line. It determines when the skill gets triggered.
- List trigger contexts explicitly: "Use when the user wants to X, Y, or Z"
- Think about should-trigger / should-not-trigger scenarios
- A slightly "pushy" description is better than a vague one
- Test: would this description make the model select this skill for the right prompts?
## Writing Instructions
### Explain WHY, not just rules
- Bad: "MUST use semantic HTML"
- Good: "Use semantic HTML elements (nav, main, aside) because screen readers depend on landmarks for navigation"
### Avoid heavy-handed MUSTs
- Reserve MUST/NEVER for genuine constraints (security, data loss)
- For preferences, explain the reasoning and let the agent make good decisions
### Progressive disclosure
Three levels of instruction loading:
1. **Frontmatter** — always loaded (name, description). Keep minimal.
2. **Body** — loaded when skill is invoked. Core instructions here.
3. **Bundled resources** — loaded on demand via `Read`. Put reference tables, specs, examples here.
Use bundled resources (`references/`, `scripts/`, `assets/`) for content that would bloat the main SKILL.md.
### Every sentence should change behavior
- Delete filler: "It is important to...", "Make sure to...", "Please note that..."
- Delete obvious instructions the agent would do anyway
- Test: if you removed this sentence, would the output change? No → delete it.
## Structure Conventions
### Project conventions (this repo)
- Always set `disable-model-invocation: true`
- Use H1 for the skill title (short action phrase)
- Reference `$ARGUMENTS` early in the body
- Use `!` backtick for live data injection (git diff, file listings)
- Numbered steps, imperative voice
- Output format in a fenced markdown block if structured
### Bundled resources pattern
```
.claude/skills/my-skill/
SKILL.md # Main instructions
references/ # Specs, guides, schemas
scripts/ # Shell scripts, templates
assets/ # Static files
```
Reference from SKILL.md: `Read ${CLAUDE_SKILL_DIR}/references/spec.md`
## Length Guidelines
- Simple skills (encoded preference): 30-50 lines
- Standard skills (capability uplift): 50-100 lines
- Complex skills (multi-mode, research): 100-200 lines
- Maximum: 500 lines (if exceeding, split into bundled resources)
## Common Mistakes
1. **Overfitting to test cases** — write general instructions, not scripts for specific inputs
2. **Too many rules** — the agent ignores rules after ~20 constraints. Prioritize.
3. **No examples** — for complex output formats, show one complete example
4. **Ignoring conversation context** — skills without fork can use prior conversation. Leverage it.
5. **Forgetting edge cases** — what happens with empty input? Invalid arguments? Missing files?
## Improvement Workflow
1. Draft the skill
2. Test with 3-5 realistic prompts
3. Review output — does every instruction change behavior?
4. Remove filler, tighten descriptions
5. Add edge case handling for failures observed in testing
6. Re-test after changes
## Evaluation Criteria
When reviewing a skill, score against:
- **Trigger accuracy** — does the description match the right prompts?
- **Instruction clarity** — can the agent follow without ambiguity?
- **Output quality** — does the skill produce useful, consistent results?
- **Conciseness** — is every line earning its place?
- **Robustness** — does it handle edge cases and errors?