Migrate from skills

If you already keep engineering knowledge as a directory of SKILL.md files — especially one grown by an introspection skill that writes new skills as it learns — you have built a manual version of this. Migration copies it across.

rose migrate                    # plan: scans ./.claude/skills, ~/.claude/skills, and the .codex equivalents
rose migrate --apply            # write the lessons
rose migrate --path ~/other/skills --limit 5
rose migrate --apply --all      # include the skill-writing skills too

It is a copy, and deliberately nothing else#

One skill becomes one lesson. The body is copied byte for byte, the description: becomes the gist, the name: the title, the directory name the family. No model calls at all — importing a five-thousand-line library costs reading five thousand lines off disk.

This reversed an earlier design, and the reason is worth knowing. Migration used to ask a model to split each skill into atomic lessons, on the argument that a skill is several claims in a trench coat while a lesson is one claim plus its trigger. That is true. It also cost a call per document, and every call was a chance to paraphrase away the exact flag, the exact error string, the exact constant — the specifics that make a lesson worth retrieving. On one real library, 24 skills became 122 lessons that no longer said quite what the originals said.

The constraint that justified splitting was retrieval: a long document was expensive to route past and hard to match. Both halves of that have gone.

Selection is a search now, not a rendered candidate list, so a long lesson costs nothing to route past. Length stopped being a retrieval tax.
Compaction is driven by observed use, so a lesson that turns out to be four-fifths padding gets cut down by evidence — rather than by a guess made at import time, before anything is known about which parts matter.

So import the original unedited, and let the stage that measures which parts do work be the thing that shortens it. Import cheaply, condense on evidence.

What it will not import#

Rule	Why
Skill-writing machinery is skipped	Skills whose subject is writing or syncing skills — `introspect`, `create-skill`, `sync-skills` — are reported as superseded. ROSE does that itself; importing them would fill the store with instructions for maintaining the system you are leaving. It is a short name list, not a judgement, so `--all` overrides it.
Nothing is deleted	Migration only adds. Retiring a skill is your call, made after you have seen `rose recall` return the same knowledge.
The same skill installed twice imports once	Project-local and global copies of one library are common, and worktree checkouts hold a full second copy. Deduplicated by directory name — a string comparison, not a model call.

The list errs toward importing. An early draft skipped sync-repos and handoff on the strength of their names; the first clones git repositories and the second writes a runbook for a human, and both are exactly the kind of hard-won procedure worth keeping. Wrongly importing something costs a lesson nobody retrieves; wrongly skipping one loses knowledge silently, and you have no reason to go looking for it.

Afterwards#

Check a few things you know a skill covered: rose recall -p "deploy the schema registry". When ROSE returns the same knowledge, the superseded skills are the safest to delete first.

Imported lessons are long, and that is fine — they cost nothing per prompt, because the store is searched rather than sent. If a skill referred to files beside it (a references/ directory, a script), the lesson carries a line naming where it came from, so those citations still resolve.