$npx -y skills add tobihagemann/turbo --skill self-improveExtract lessons from the current session and route them to the appropriate knowledge layer (project AGENTS.md, auto memory, existing skills, or new skills). Use when the user asks to \"self-improve\", \"distill this session\", \"save learnings\", \"update CLAUDE.md with what we l
| 1 | # Self-Improve |
| 2 | |
| 3 | Review the current conversation to extract durable lessons and route each one to the right knowledge layer. |
| 4 | |
| 5 | ## Step 1: Detect Context |
| 6 | |
| 7 | Available destinations: |
| 8 | |
| 9 | - **Project CLAUDE.md / AGENTS.md** — The root `.claude/CLAUDE.md` (may be a symlink to `../AGENTS.md` — resolve it), plus any nested `CLAUDE.md` / `AGENTS.md` files in subdirectories. Claude Code loads a subdirectory's file on demand when files in that subtree are accessed, so a lesson scoped to one subtree belongs in the nearest enclosing file, with the root reserved for project-wide rules. |
| 10 | - **Auto memory** — The project-specific memory directory at `~/.claude/projects/<project-hash>/memory/`. Read `MEMORY.md` there if it exists. |
| 11 | - **Skills** — Project skills at `skills/` or `.claude/skills/` (resolve symlinks) |
| 12 | |
| 13 | Discover the project CLAUDE.md/AGENTS.md files (the root file and any nested ones in subdirectories) and read them, then read MEMORY.md. List all skill directories but do not read them yet — Step 2 needs to run first so you know what to look for. |
| 14 | |
| 15 | ### Turbo Skill Detection |
| 16 | |
| 17 | Read `~/.turbo/config.json` for `repoMode`. If `repoMode` is `"fork"` or `"source"`, turbo skill improvements can be contributed upstream. |
| 18 | |
| 19 | If `~/.turbo/repo/` exists, identify which installed skills are turbo skills: |
| 20 | |
| 21 | - List directories in `~/.turbo/repo/claude/skills/` |
| 22 | - Any skill in `~/.claude/skills/` that has a matching directory in `~/.turbo/repo/claude/skills/` is a turbo skill |
| 23 | - Skills only in `~/.claude/skills/` (no match in the repo) are user/project skills |
| 24 | |
| 25 | **Verification rule (mandatory before routing in Step 4):** For every candidate skill that is about to be routed as turbo, confirm with a fresh `test -d ~/.turbo/repo/claude/skills/<name>` check that the skill actually lives in the turbo repo. Do not rely on remembered listings from earlier in the session, filename hits in grep output, or assumptions based on where a SKILL.md was read from. A miss here mislabels a user/project skill as turbo, triggers the contribution flow unnecessarily, and can introduce session-specific content into a shared skill — so the check is not optional. |
| 26 | |
| 27 | **Exception:** If the current project IS the turbo repo (i.e., the working directory contains this skill collection), route turbo skill lessons through the **Existing user/project skill** destination in Step 4 — edits go directly to `claude/skills/<name>/` in the project, with no installed-copy indirection and no contribution flow. |
| 28 | |
| 29 | ## Step 2: Identify Session Skills and Scan for Lessons |
| 30 | |
| 31 | ### Identify Session Skills |
| 32 | |
| 33 | Before scanning for lessons, identify which skills were loaded during this session: |
| 34 | |
| 35 | - Scan the conversation for Skill tool invocations and SKILL.md reads from `~/.claude/skills/` |
| 36 | - Build a list of session skills, marking each as turbo or user/project skill (using the detection from Step 1) |
| 37 | - This list informs routing in Step 4: when a lesson clearly arose from a specific skill's workflow, that skill is the natural routing target |
| 38 | |
| 39 | ### Scan for Lessons |
| 40 | |
| 41 | Scan the full conversation with this priority: |
| 42 | |
| 43 | 1. **Corrections** — Where the user interrupted, said "no", "actually", "stop", "not like that", redirected, or manually fixed something Claude did wrong. Highest-value lessons. |
| 44 | 2. **Repeated guidance** — Instructions the user gave more than once. |
| 45 | 3. **Skill-shaped knowledge** — Domain expertise that was needed repeatedly, tool/API integration details that had to be looked up, decision frameworks that emerged for evaluating options, content templates or writing conventions that were refined, and multi-step workflows where ordering mattered (as reusable domain knowledge, not the workflow itself — see #4). |
| 46 | 4. **New workflows** — Did this session establish a novel multi-step procedure, coordination pattern, or automation that worked? A successful workflow that would need to be repeated is a prime skill candidate — even if it ran fine this time. Distinct from #3: this captures the procedure itself as a repeatable artifact, not knowledge about how to do it. Flag it. |
| 47 | 5. **Preferences** — Formatting, naming, style, or tool choices the user expressed. |
| 48 | 6. **Failure modes** — Approaches that failed, with what worked instead. For tool or script call failures, trace back to the information source that led to the error and route the fix there (e.g., clarify a reference file, update skill instructions, add missing documentation). |
| 49 | 7. **Domain knowledge** — Facts or conventions Claude needed but did not have. |
| 50 | 8. **Improvement opportunities** — Out-of-sco |