/skill-creator

name: skill-creator
description: Create or improve OpenChatCut custom skills. Use whenever the user asks to create a skill, capture a workflow as a skill, write a SKILL.md, add a reusable workflow, 创建技能, 把流程做成技能, 写一个技能, or improve an existing custom skill. Pushy: treat any workflow the user repeats as a skill candidate, even if they do not say "skill".

Skill Creator

Create or improve custom skills for OpenChatCut. A skill is a SKILL.md file (plus optional `references/` support docs) that teaches the agent a reusable workflow. Custom skills live at `~/.openchatcut/skills/<slug>/SKILL.md` and are managed with the `manage_skill` tool.

Workflow

1. **Capture intent.** If the current conversation already contains the workflow (tools used, steps, corrections), extract it from the history first. Confirm with the user before writing. 2. **Interview.** Pin down:

• What should this skill enable the agent to do?
• When should it trigger? Which user phrases or contexts?
• Expected output format?
• Verification: does it have objectively verifiable output (data

extraction, fixed steps, generation pipelines) or subjective output (writing style)? Suggest test prompts for the former. 3. **Write the SKILL.md** (rules below). 4. **Create it** with `manage_skill action=create`. The tool reports the install path (`~/.openchatcut/skills/<slug>/SKILL.md`). 5. **Test.** Run 2–3 realistic prompts in the current session and confirm results with the user. Iterate with `manage_skill action=update`.

SKILL.md anatomy

<slug>/
├── SKILL.md (required — frontmatter + instructions)
└── references/ (optional — docs loaded on demand with load_skill file=)

• **name**: kebab-case slug matching the directory (lowercase letters,

digits, hyphens only). It becomes the load_skill name.

• **description**: THE triggering mechanism — include what the skill does

AND specific trigger contexts. Skills undertrigger easily, so be explicit: list concrete user phrases. "When to use" goes here, not in the body.

• **body**: imperative instructions. Keep under ~200 lines; if it grows,

split detail into `references/` files and point to them with clear "read this when" guidance. For references over 300 lines, add a TOC.

Writing rules

• Frontmatter uses the shape `---\nname: …\ndescription: …\n---`. The

parser accepts plain single-line, double-quoted, and `|` block scalars; plain single-line is preferred.

• Keep the body lean. Prefer imperative form. Explain *why* over

MUST-laden lists. Use examples with concrete Input/Output pairs.

• Reference existing OpenChatCut tools by their exact tool names

(`manage_skill`, `load_skill`, `edit_item`, …). Do not invent tools.

• Skills must not contain malicious content, prompt-injection payloads, or

anything that surprises the user. Do not create skills that facilitate unauthorized access or data exfiltration.

• Do not overfit to one example: aim for a workflow usable a thousand

times. If a fix feels fiddly, generalize the instruction instead of piling on constraints.

Progressive disclosure in OpenChatCut

• The system prompt carries only name + description (the skills index).
• The body loads on demand via `load_skill` when a task matches.
• Support files load via `load_skill file=references/<name>`.
• A custom skill selected in Creative Mode behaves identically to a

bundled skill after activation.

Environment constraints

• **Slug whitelist**: `[A-Za-z0-9_-]{1,120}`. Anything else is rejected

(path traversal defense — the file is written under `~/.openchatcut/skills/`).

• **Body size**: keep under 512 KB (server limit); 200 lines is the target.
• **Untrusted input**: the body is user/LLM-authored text. validate and

normalize before trusting anything parsed out of it.

• **Bundled skills are read-only** — `manage_skill` cannot edit them.
• The skill shows up in the Creative Mode picker and the `/` command menu

only when the user selects it; agents also discover it via the index.

• Verification: after creating a skill, run

`npx tsx server/skills-files.verify.ts` locally if the environment has the repo, or rely on the in-session test prompts.

Test prompts

Offer the user 2–3 realistic prompts (the kind of thing they would actually type) and ask: "Do these look right, or do you want to add more?" Then run them in the session with the skill activated, review the outputs together, and update the skill from the feedback.