Turn workflows from your MemSearch memory into reusable skills. Use when the user asks to make/create/extract/distill a skill from what they just did or from past work, review skill candidates, install a distilled skill, or 'turn this into a skill'. Manages MemSearch
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/memory-to-skill
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Turn workflows from your MemSearch memory into reusable skills. Use when the user asks to make/create/extract/distill a skill from what they just did or from past work, review skill candidates, install a distilled skill, or 'turn this into a skill'. Manages MemSearch
📊 Stats
Stars2,369
Forks207
LanguagePython
LicenseMIT
📦 Ships with memsearch
</> SKILL.md
memory-to-skill.SKILL.md
---name: memory-to-skill
description: "Turn workflows from your MemSearch memory into reusable skills. Use when the user asks to make/create/extract/distill a skill from what they just did or from past work, review skill candidates, install a distilled skill, or 'turn this into a skill'. Manages MemSearch procedural-memory candidates under .memsearch/skill-candidates/, not Claude Code's own skills system."
context: fork
allowed-tools: Bash
---You manage MemSearch's **procedural memory**: skills distilled from the work you
repeat — a third layer beside the daily journals (episodic) and PROJECT.md /
USER.md (semantic). State once that this is MemSearch skill distillation, not
Claude Code's built-in skills system.
Stages: **0** memory journals → **1** candidate (`.memsearch/skill-candidates/`,
a git-tracked store that keeps evolving) → **2** installed (an agent skill dir).
Candidates are never installed automatically; installing is always a human step.
User requests may stop at candidate creation/review, or continue to installation
in the same turn after explicit approval; match the requested stage.
## Intent routing
- "make/turn this into a skill", "from what we just did" → **A. Capture now**.
- "what skills / review candidates / install X" → **B. Review & install**.
- "mine my history / find recurring workflows" → **C. Distill from history**.
- "enable / configure / how eager" → **D. Configure**.
- Unclear or empty → run **B**'s `list`; if empty, offer A or C.
## A. Capture what you just did (0→1→2)
You already have the context, so **draft the skill yourself** — do not call the
background distiller for this. Write a SKILL.md **body** (markdown, no
frontmatter): imperative numbered steps for the recurring task, concrete commands
and paths, no secrets, self-contained.
**Be exact — do not guess.** You have the live session for what you just did, so use the real commands, paths, and output, not approximations. If a detail is uncertain, verify it (re-read the relevant files or the transcript) or keep that step general — a wrong command is worse than a vague one. Then persist it as a candidate:
`skills status` compares each candidate's current `SKILL.md` content hash with
the hash recorded by the last `skills install`. It does not inspect live agent
skill directories. A pending installed skill means the candidate source evolved
after the last deliberate install; reinstall only after reviewing the candidate.
Before recommending or installing, skim the candidate's body: if a step looks uncertain or loosely summarized, re-check it against the source (open the transcript if needed) or flag it to the user and let them decide — installing copies the candidate as-is, so this is the last chance to catch a wrong step.
When showing candidates, mention the store's recent git history when it helps
explain whether a candidate is new, evolved, removed, or re-created.
Treat installation as an interactive checkpoint. Show the candidate, apply any
requested tweaks before installing, and confirm the install destination with the
user. Resolve install targets from config first: if `paths` is a non-empty
list, present those paths as the proposed destinations and pass each entry as a
`--path` after confirmation. If it is empty, ask the user where to install; do
not silently fall back to a default path.
```bash
memsearch config get plugins.claude-code.memory_to_skill.paths 2>/dev/null || echo "[]"
After installation, remind the user to start a fresh agent session or reopen the
conversation so the newly installed skill is loaded.
If the list is **empty**, background distillation is likely off or has not run.
Offer the user a choice: capture from recent work now (**A**), distill from
history (**C**), or enable the background pass (**D**).
## C. Mine history for recurring workflows (0→1)
To pull skills out of past work (not just the current session), read the recent
journals yourself — they live in `.memsearch/memory/*.md` — and look for
multi-step procedures that recur across several sessions. Draft each genuinely
reusable one and persist it with `memsearch skills add` (one call per skill), the
same way as **A**. Use your own judgment: only propose procedures that recur and
generalize, not one-offs from a single day.
**Drill into the original before drafting.** The journal bullets are a lossy summary; the exact commands, flags, and paths live in the original transcript. Each journal entry has an anchor naming the transcript file (`transcript:<file>.jsonl` with a `turn:` id). Run `memsearch transcript <file>` (add `--turn <id>` when the anchor has one) to get the original turns **with their tool calls** — it auto-detects the format and includes the executed commands and output. Write the skill from that. If the shown excerpt feels incomplete, skim nearby turns in the same original source before committing to exact commands or paths. Only if that command fails (unknown format) fall back to reading the JSONL directly. If you cannot confirm a detail, keep the step general or omit it — never fabricate.
The background pass mines automatically when enabled, starting from the summaries; doing it here on demand lets you inspect the original transcripts more deliberately, so the result can be more accurate.
## D. Configure
```bash
memsearch config get plugins.claude-code.memory_to_skill.enabled 2>/dev/null || echo "false"
# enable the background pass globally (do not enable silently)
memsearch config set plugins.claude-code.memory_to_skill.enabled true
# how eagerly history-mining distils (default 3; lower = more eager)
memsearch config set plugins.claude-code.memory_to_skill.min_occurrences 3
# pre-set install targets (otherwise you are asked at install time)
memsearch config set plugins.claude-code.memory_to_skill.paths '[".claude/skills"]'
```
Since v0.4.11, project-local `.memsearch.toml` accepts only allowlisted local
indexing keys. Do not use `--project` for `plugins.*` settings such as
`memory_to_skill.enabled`, `min_occurrences`, or `paths`; put them in global
config instead.
Note: `enabled` only gates the **background** (session-end) pass. The explicit
commands above (`skills add`, `skills install`) always work, and you can mine history (C) directly.
## Install paths
- `.claude/skills` — **project-local (recommended)**: a skill from this project's
memory is usually most relevant here.
- `~/.claude/skills` — global: available across all your projects.
- a custom path, or several (one skill can be installed to multiple dirs).
Each agent reads skills from its own directory: Claude Code `.claude/skills/`;
Codex and OpenCode `.agents/skills/` (the shared standard, also read by Cursor
etc.); OpenClaw `.openclaw/skills/`. Claude Code does **not** read `.agents/skills/`.
Install to multiple paths to cover several agents.
## Guardrails
- Never enable the feature, change install paths, or install a candidate without
the user's go-ahead.
- Do not hand-edit the store; create candidates with `memsearch skills add` and let
the git-tracked store at `.memsearch/skill-candidates/` keep history.
