Meta-skill for authoring Markdown Skill files with YAML frontmatter and progressive disclosure via create_skill. Use when: adding a new skill, generating SKILL.md with references or templates, or checking description rules.
Resources
3Install
npx skillscat add xuiltul/animaworks/skill-creator Install via the SkillsCat registry.
We need to produce a 2-3 sentence plain-text summary, objective, factual, no marketing language, no superlatives, no calls to action. Must explain what the skill does, what problem it solves, when to use it. At most 60 words. No quotes, no markdown. Just plain text. The skill is meta-skill for authoring Markdown Skill files with YAML frontmatter and progressive disclosure via create_skill.
skill-creator
Skill file structure
A Skill file consists of YAML frontmatter and Markdown body.
Required frontmatter fields are name and description.
Optional metadata may include tool constraints, trust/provenance fields, category, prompt policy, and routing hints. Use optional fields only when they help selection, safety, or maintenance.
---
name: skill-name
description: >-
Concise third-person summary of what the skill does.
Use when: comma-separated scenarios where this skill applies.
allowed_tools:
- read_memory_file
trust_level: trusted
source:
type: anima
origin: manual
category: communication
use_when:
- drafting partner emails
trigger_phrases:
- draft a partner email
negative_phrases:
- personal diary
domains:
- gmail
routing_examples:
- Prepare a reply draft for the bank thread
---description is the primary field for discovery and selection: the model uses it to decide relevance.
The body is read when you open the path from the system prompt skill catalog with read_memory_file (e.g. skills/foo/SKILL.md, common_skills/bar/SKILL.md).
Supported create_skill optional arguments include references, templates, allowed_tools, trust_level, source_type, source_origin, category, promotion_status, skill_policy, use_when, trigger_phrases, negative_phrases, domains, and routing_examples.
Authoring format: follow Use when: as described in references/description_guide.md (Agent Skills standard).
After editing, validate with python scripts/lint_skill.py path/to/SKILL.md.
Writing description
Do not use legacy 「」 keyword lists. Use a short third-person capability line plus Use when: with concrete verbs and nouns.
See references/description_guide.md for rules (250 characters, no XML tags, examples, checklist).
Domain-specific and concrete
Generic wording causes false positives. Prefer tool names, operations, and targets specific to the skill.
Progressive disclosure
Skill information is disclosed in three levels.
| Level | Content | When shown |
|---|---|---|
| Level 1 | name + description |
Skill catalog / tool descriptions (budgeted) |
| Level 2 | body | Loaded with read_memory_file(path="skills/.../SKILL.md") or common_skills/.../SKILL.md |
| Level 3 | External files | Loaded per body instructions (references/, templates/) |
Keep Level 1 concise; put procedures in Level 2; offload long material to Level 3.
Creation procedure
Step 1: Clarify
- What to automate or document
- Personal vs common Skill (procedures use
procedures/*.mdseparately) - Use when: scenarios (when to choose this skill)
Step 2: Design
- name: kebab-case (e.g.
my-skill); use*-toolnaming for external tool guides when applicable - description: third-person summary +
Use when:(seereferences/description_guide.md) - body: section structure; optional
{{now_local}}and other builtins - references / templates: optional
- allowed_tools: optional soft constraint
- trust/source/category/policy/routing: optional trust level, provenance, category, prompt policy, and routing metadata (
use_when,trigger_phrases,negative_phrases,domains,routing_examples)
Step 3: Create
create_skill(skill_name="{name}", description="{description}", body="{body}")Common skills:
create_skill(skill_name="{name}", description="{description}", body="{body}", location="common")You can also pass references, templates, allowed_tools, trust_level, source_type, source_origin, category, promotion_status, skill_policy, use_when, trigger_phrases, negative_phrases, domains, and routing_examples when those fields are useful.
Prefer create_skill for new skills; flat skills/foo.md alone may not match skills/foo/SKILL.md for read_memory_file.
Step 4: Verify
- Re-read with
read_memory_file(path="skills/{name}/SKILL.md")(or thecommon_skills/...path from the catalog) - Run
python scripts/lint_skill.pyon the file (recommended)
Checklist
- YAML frontmatter delimited by
--- -
nameanddescriptionpresent -
Use when:present; no「」keyword enumeration - Domain-specific, concrete wording (avoid vague “manage” / “check” alone)
- Body has actionable steps
- Avoid relying only on
## Overviewfor description; prefer frontmatter - Optional metadata (
trust_level,source,category,skill_policy,use_when,trigger_phrases,negative_phrases,domains,routing_examples) matches the actual skill - Created via
create_skillwith{name}/SKILL.mdlayout where applicable
Template
Use templates/skill_template.md bundled with this skill, or:
---
name: {{skill_name}}
description: >-
{{Line 1: concise capability summary}}
Use when: {{comma-separated usage scenarios}}
---
# {{skill_name}}
## Procedure
1. ...
2. ...
## Notes
- ...Notes
- Skills are Markdown playbooks, not Python tools
- Required frontmatter:
name,description - Optional:
allowed_tools, trust/provenance fields,category,skill_policy, and routing metadata. Keep metadata minimal when the description is sufficient - Keep body around 150 lines when practical; use
references/for long material