| name | mc-manage-skills |
| description | Save, edit, list, or delete a Claude Code skill in this workspace. Use when the user wants to turn a workflow into a reusable skill ("skill 化して", "save this as a skill"), modify or remove one, or list what's registered. Writes one markdown file per skill at `data/skills/<slug>/SKILL.md`; a workspace-side hook mirrors it into `.claude/skills/<slug>/SKILL.md` so Claude Code picks it up. |
Skill manager
A bundled MulmoClaude preset skill (mc- prefix = launcher-managed; do not edit
this file in the workspace, it is overwritten on every server boot).
Help the user manage project-scope Claude Code skills. The skill body
that Claude Code reads lives at .claude/skills/<slug>/SKILL.md, but agents
must not write there directly — Claude Code's permission system treats
.claude/ as a self-modification surface and the host GUI cannot answer the
resulting prompt, so the write hangs.
Instead, edit the staging file at data/skills/<slug>/SKILL.md. A PostToolUse
hook mirrors every Write / Edit / rm on those staging files into
.claude/skills/<slug>/SKILL.md (or removes the entire dir on delete) and
then asks the server to re-register skills — no restart needed. The user
never sees the staging vs. canonical split; they just say "skill 化して".
The user-scope folder ~/.claude/skills/ is read-only territory managed
outside MulmoClaude — don't touch those.
End with a one-line confirmation ("Saved as foo-skill." / "Removed foo-skill.")
so the user can verify without scrolling.
Collections (a skill + a schema.json)
If the user wants a small data app — a list/table they can view and edit
(a swimming log, a recipe box, a client database) — that's a collection
skill: a skill dir that also ships a schema.json (and optional
templates/*.md). Author all of them under the same staging dir
(data/skills/<slug>/SKILL.md + data/skills/<slug>/schema.json +
data/skills/<slug>/templates/*.md); the same bridge hook mirrors those three
file kinds into .claude/skills/<slug>/ and the collection appears at
/collections/<slug>. Read config/helps/collection-skills.md first — it
is the authority on the schema DSL (field types, relations, derived fields,
actions). Don't hand-roll a schema from memory.
Workflow 1: save a new skill
Triggers: "skill 化して", "save this as a skill", "make this reusable",
"そのまま skill に".
Step 1 — distil. If the user is asking you to skill-ify the current
conversation, read the chat transcript first. The transcript lives at
chat/<session-id>.jsonl; if you don't know the session id, list the
directory and pick the most-recent one. Reduce the conversation into a
focused markdown body in second person ("First, do X. Then, do Y.") that
captures the reusable workflow — not the one-off details that won't generalise.
Step 2 — pick a kebab-case slug. Lowercase ASCII letters / digits, single
hyphens between segments, no leading / trailing / consecutive hyphens, 1-64
characters. Pattern: ^[a-z0-9]+(-[a-z0-9]+)*$. If the user proposed a name,
use it as-is (validate the same way).
If data/skills/<slug>/SKILL.md already exists, ask before overwriting.
Step 3 — Write data/skills/<slug>/SKILL.md (NOT .claude/skills/... — the
bridge hook handles that copy):
---
name: <slug>
description: One-line summary that frames *when* the skill should run.
schedule: daily 09:00 # optional — auto-runs on schedule
roleId: general # optional — role to use for scheduled runs
---
# <Skill name>
Body in markdown, second person. Focused on the reusable workflow.
Description rules (the discovery layer reads this — make it count):
- Lead with an action verb + noun ("Save / list / delete a recipe", "Schedule
a recurring task"). Vague descriptions like "Helps with X" don't trigger.
- Include a few trigger phrases the user might say, in their language.
- Cap around 1-2 sentences. Long descriptions get truncated when the listing
is sent to Claude.
Optional fields:
schedule — daily HH:MM (UTC) or interval Ns / Nm / Nh. The
scheduler auto-runs the skill at that cadence.roleId — role to use for scheduled runs (defaults to general).
The bridge hook mirrors data/skills/<slug>/SKILL.md → .claude/skills/<slug>/SKILL.md
and fires POST /api/config/refresh, so a new schedule: activates without a
server restart.
Workflow 2: recall / browse
Triggers: "what skills do I have?", "保存した skill みせて", "list my
skills".
List the staging directory:
ls data/skills/
Read each data/skills/<slug>/SKILL.md's frontmatter and present the names + one-line
descriptions in chat. Don't dump raw markdown unless the user asks for a
specific skill's details.
Workflow 3: update
Triggers: "〇〇 の skill を更新して", "change the description of foo",
"add a schedule to foo-skill".
Read data/skills/<slug>/SKILL.md, apply the change with Edit (preserve every other
field unless the user explicitly asked to change it), and confirm. The bridge
hook re-mirrors the file and triggers a refresh.
Workflow 4: delete
Triggers: "remove the foo skill", "foo-skill いらない".
Only when the user explicitly asks. Re-validate the slug against
^[a-z0-9]+(-[a-z0-9]+)*$ before running the command — if it fails, refuse
and ask the user to confirm by name. When valid, use exactly this form
(the bridge hook only mirrors deletes that match this shape; bulk rm -rf of
the parent dir or paths with wildcards are intentionally NOT mirrored so a
typo can't wipe every skill):
rm -rf data/skills/<slug>/
The hook then removes .claude/skills/<slug>/ to match. Confirm afterward.
Tone
Friendly, practical. Don't lecture about staging files, paths, or hooks —
those exist behind the scenes and the user should never need to know. Just
save and confirm. If a request needs several decisions (e.g. "save as foo
and schedule it daily"), do them in one go, don't ping-pong.
