create-a-user-skill

name	Create a user skill
description	Create a new user skill at setting/skills/<id>/SKILL.md.
appliesTo	["operate"]
userInvokable	true

Create a user skill

You were called because the user typed /create-skill <instructions> in the chat input. Your job for this turn is create a brand-new user skill that captures the reusable how-to / recipe / pattern they described — no analysis or judgement required, just author it cleanly and write it.

Inputs you have

• The free-text after /create-skill in the most recent user message — this is the brief. It may be terse ("a skill for warm-healing story outlines") or detailed ("…and use a 5-frame layout with these colour rules…"). Use what's there; do not ask the user clarifying questions unless the brief is literally empty.
• The skill catalogue in your system prompt — scan it briefly to avoid duplicating an existing skill id. If a near-match exists, prefer /update-skill semantics over /create-skill, but only mention this in your final reply; do not silently switch modes.

Pick the id

• Kebab-case, derived from the brief's noun phrase. Keep it short (≤ 5 words).
  • "warm-healing outline" → warm-healing-outline
  • "research paper summary" → research-paper-summary
• Must not collide with an existing skill id (check the catalogue).
• Must match [a-z0-9-]+ — no slashes, dots, underscores, or uppercase.

Compose the file

Submit the entire file via fs_write, including the YAML frontmatter fence. The skill id comes from the <id> directory segment in the path — it is not a frontmatter key. Frontmatter fields:

field	value
name	human-readable label (Title Case is fine)
description	one-sentence catalogue blurb — what the skill does, not when (the body covers when)
appliesTo	array; default to ["ask", "operate"] unless the brief obviously narrows the surface

triggers and version are optional — omit unless the brief calls for them.

Body structure (use these section headings verbatim — keeps user skills consistent and easy to scan):

# <Display name>

## When to use
…short list of scenarios, written from the user's perspective.

## How to apply
…step-by-step / checklist / decision rules. Be concrete.

## Examples
…minimal, copy-pasteable. Optional but very valuable.

Body length: keep it tight. Every byte ends up in someone's prompt later; aim for ≤ 60 lines.

Write it

Use fs_write exactly once:

{
  "path": "skills/<id>/SKILL.md",
  "mode": "overwrite",
  "rationale": "<≥ 20 chars explaining why no existing skill fits>",
  "body": "---\nname: \"…\"\ndescription: \"…\"\nappliesTo: [\"ask\", \"operate\"]\n---\n\n# …\n\n## When to use\n\n…\n"
}

rationale is required by fs_write because this is a skill-create on a path that doesn't yet exist. Make it substantive — "the user explicitly requested this skill via /create-skill: " is the minimum bar; better if you can name a near-miss skill from the catalogue you considered and explain why it didn't fit.

After writing

• Briefly confirm to the user: skill id, one-line summary of what it does, and a reminder that they can now invoke it via /<id>.
• Do not make Space changes in the same turn; this slash skill is write-the-skill-and-stop.