| 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
- 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.
- 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.
- Write the SKILL.md (rules below).
- Create it with
manage_skill action=create. The tool reports the
install path (~/.openchatcut/skills/<slug>/SKILL.md).
- 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.
