skill-creator

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            # lowercase, digits, hyphens; max 64 chars
description: One line stating WHAT it does and WHEN to use it.
tags: [tool]              # optional, user-facing organisation
always: false             # optional: eager-inject into every turn
requires:                 # optional availability gates
  bins: [git]             # host CLI binaries
  env: [GITHUB_TOKEN]     # environment variables
  sandbox: shell          # needs the shell execution sandbox
---

Core principles

1. 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.
2. 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?
3. Match freedom to fragility. Open-ended tasks → heuristics and principles (high freedom). Fragile, error-prone sequences → exact steps to follow (low freedom).
4. 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")).
5. No auxiliary files. No README, changelog, or setup guides inside a skill — only what the model needs to do the job.

Writing workflow

1. 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.
2. Plan reusable content. For each example, identify what knowledge is re-derived every time — that belongs in the skill (body or references).
3. 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?
4. Create it. Use the skill management UI (Space → Skills) or the skills API. The name becomes the directory name.
5. Iterate from real use. After the skill fires on real tasks, tighten what the model stumbled over and delete what it never needed.