| name | skill-creator |
| description | Design and author DeepTutor skills (SKILL.md packages). Use when the user wants to create a new skill, improve an existing skill, or asks how skills work. |
Skill Creator
Guidance for authoring effective DeepTutor skills.
What a skill is
A skill is a self-contained capability package: a SKILL.md playbook plus
optional references/ files. The system prompt only carries each skill's
name + description; the model fetches the full body with the read_skill
tool when a task matches. Skills teach procedural knowledge — workflows,
domain expertise, format conventions — that no model fully possesses.
Behaviour/voice presets (tone, teaching style) are NOT skills — those are
personas, managed separately.
Anatomy
my-skill/
├── SKILL.md (required: frontmatter + instructions)
└── references/ (optional: docs loaded on demand via read_skill)
Frontmatter schema:
---
name: my-skill
description: One line stating WHAT it does and WHEN to use it.
tags: [tool]
always: false
requires:
bins: [git]
env: [GITHUB_TOKEN]
sandbox: shell
---
Core principles
- The description is the trigger. It is the only text the model sees
before deciding to read the skill. State both what the skill does and
the situations that should trigger it. Put ALL "when to use" guidance
here — a "When to Use" section in the body is read too late.
- Concise is key. The context window is shared. Assume the model is
already smart; only add what it doesn't know. Challenge every paragraph:
does it justify its token cost?
- Match freedom to fragility. Open-ended tasks → heuristics and
principles (high freedom). Fragile, error-prone sequences → exact steps
to follow (low freedom).
- Progressive disclosure. Keep
SKILL.md under ~500 lines. Move
schemas, long examples, and variant-specific details into
references/<file>.md, and link them from SKILL.md with a clear note
on when to read each (the model fetches them with
read_skill(name, file="references/<file>.md")).
- No auxiliary files. No README, changelog, or setup guides inside a
skill — only what the model needs to do the job.
Writing workflow
- Collect concrete usage examples. Ask the user: "What would you say
that should trigger this skill? What should it do?" Stop when the
trigger phrases and expected behaviour are clear.
- Plan reusable content. For each example, identify what knowledge is
re-derived every time — that belongs in the skill (body or references).
- Draft the skill. Imperative form throughout. Frontmatter first;
verify the description passes the trigger test: would a model reading
only this line know when to use the skill?
- Create it. Use the skill management UI (Space → Skills) or the
skills API. The name becomes the directory name.
- Iterate from real use. After the skill fires on real tasks, tighten
what the model stumbled over and delete what it never needed.
