learn

name

learn

description

Distill a reusable skill from anything — a directory, a URL, pasted notes, or what you just did together — or refine an existing skill with new learnings. Use when the user says '/learn', 'learn this', 'turn this into a skill', 'capture this workflow', 'make a skill from <source>', or 'improve/update the <name> skill'. Produces or updates a .claude/skills/<name>/SKILL.md authored to NanoClaw's skill guidelines. (This CREATES or REFINES a skill from a source; it does not install existing skills from a registry.)

Learn — Distill a Skill from Anything

Turn a source — a directory, a URL, pasted notes, or the work just done in this conversation — into a clean, reusable NanoClaw skill. The output is a new .claude/skills/<name>/SKILL.md (plus optional scripts/, references/, templates/) authored to the project's skill guidelines.

This skill is instruction-only: it uses the tools you already have (Read, Grep, Glob, WebFetch, Write) — there is no separate distillation engine and no reach-ins into core code.

When to use

Invoke when the user wants to capture a workflow as a reusable skill:

• /learn <path> — read a project/dir and build a skill for working with it
• /learn <url> — read docs / an API page and build a usage skill
• /learn what we just did — distill the current conversation's workflow
• /learn + pasted notes — turn notes into a structured skill

If the user instead wants to find and install an existing community skill, that is a different task — this skill creates new skills, it does not import them.

Workflow

1. Identify the source — and whether this is a new skill or a refine

• A path → read the code/files.
• A URL → fetch and read the page.
• "what we just did" / "this" → use the current conversation as the source.
• Pasted text → use it directly.

Then check .claude/skills/ for an existing skill that already covers this topic (the user may name it, e.g. "update the wow-on-steam-deck skill", or the subject may obviously match one). If one exists, this is a REFINE, not a fresh create — go to step 4's "Refining" branch.

If it is ambiguous what the skill should do, ask one clarifying question before proceeding.

2. Gather the material

• Path: Glob the structure, Read the key files, Grep for the important entry points. Read enough to understand the repeatable procedure, not every line.
• URL: WebFetch the page; pull out the concrete commands/steps, not the prose.
• Conversation: re-read what was actually done — the commands, the gotchas, the decisions — and keep the parts that generalize.

3. Distill — find the reusable procedure

Strip the one-off specifics; keep the repeatable shape. A good skill answers: "Next time someone needs to do X, what are the exact steps, files, commands, and gotchas?" Capture:

• the trigger / when-to-use,
• the step-by-step procedure (commands, file paths, decision points),
• the non-obvious gotchas that were hit — usually the most valuable part,
• any scripts or templates worth shipping alongside.

4. Author the SKILL.md

Refining an existing skill? First Read the current .claude/skills/<name>/SKILL.md, then update it in place — do not blindly overwrite:

• Keep what is still correct; weave the new learnings into the right sections.
• Dedupe — don't append a near-duplicate step or a second gotcha that says the same thing.
• Correct anything the new source proves stale (a changed path, command, or flag).
• Preserve the existing name/folder and overall structure; the diff should read as a focused improvement, not a rewrite.

New skill? Write .claude/skills/<kebab-name>/SKILL.md.

Frontmatter (required):

---
name: <kebab-case, matches the folder>
description: "<what it does + when to use it + likely trigger phrases>"
---

description is what the agent reads to decide relevance — make it concrete and include the phrases a user would actually say.

Body: open with one paragraph on what the skill does, then a ## When to use section and a ## Workflow of numbered steps (the actual procedure). Use tables for command/file references, and add a short examples or troubleshooting section when the gotchas warrant it.

House authoring rules (from docs/skill-guidelines.md):

• Additive, minimal reach-ins — prefer adding files; make the smallest possible edit to existing code, and only via single-line calls into skill-owned functions.
• Instruction-only when possible — if Claude can do it by following prose plus existing tools, ship no code. These are the easiest skills to maintain and to merge.
• If apply leaves anything behind, ship a REMOVE.md that fully reverses every change (no soft-disabled/commented-out removals).
• If the skill adds an integration point in core code, add a test that goes red if the wiring is deleted or drifts.
• Anti-patterns to avoid: separate VERIFY.md files, incomplete cleanup, raw SQL against core DBs, branch merges (use additive fetch), hand-maintained duplicate copies.

5. Place and verify

• Write into .claude/skills/<name>/; confirm the folder name matches the name frontmatter and the YAML parses.
• If feasible, dry-run the procedure the skill describes to confirm it is correct.
• Tell the user the skill exists and how to invoke it (/<name>).

Example

/learn what we just did after a multi-step setup:

1. Re-read the conversation's commands and gotchas.
2. Distill the repeatable procedure.
3. Write .claude/skills/<topic>-setup/SKILL.md with the steps, file paths, and the gotchas hit along the way.
4. Report: "Created /<topic>-setup — invoke it next time to repeat this."

Notes

• Keep skills focused — one capability per skill (mirrors the project's "one change per PR" rule).
• The most valuable content is the gotchas, not the happy path.
• This skill is prose and safe to re-run — use it again to refine an existing skill.