mc-manage-skills

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.