Menu
Meta-skill for learning from skill usage. Tracks uncertainties, human interventions, and gaps discovered during use, then proposes concrete skill patches.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Graceful context transfer before session end or compaction. Commits work, documents pending threads, captures learnings, and prepares the next instance to continue seamlessly.
Promote a session's durable cross-project learnings to the shared union store (~/.claude-sync โ the MISTAKES.md ledger, LIBRARY.md and its Index in SHARED-MEMORY.md, and the SHARED-MEMORY.md Journal) and to per-project auto-memory. This is the /meta-update ritual.
Audit the QUALITY of an existing test suite (not just its existence) โ finds tests that can't fail, change-detector/over-mocked tests, unfocused tests, unreadable tests, unactionable failures, weak test values, non-hermetic tests, and risk/coverage gaps. Grounded in the Google Testing Blog / "Testing on the Toilet" canon. Use after a test sprint, before trusting a suite, or when green tests still ship bugs.
Generate Obsidian Canvas (.canvas) files for UX flows, data flows, and testing infrastructure visualization
Systematic codebase review for technical debt - pattern conflicts, test gaps, band-aid fixes, security issues, and documentation holes. Use after rapid development sprints or before major refactors.
Use when docs may have drifted from code, after development sprints, before onboarding, or when unsure if documented guarantees still hold. Surfaces stale docs, undocumented modules, naming conflicts, invalidated proofs, and convention violations.
| name | Skill Update |
| description | Meta-skill for learning from skill usage. Tracks uncertainties, human interventions, and gaps discovered during use, then proposes concrete skill patches. |
A container for empirical skill improvement. When you use any skill and encounter friction โ ambiguity, missing guidance, wrong assumptions, or needed human clarification โ this meta-skill structures those observations into actionable patches.
Announce at start: "Also running Skill Update โ I'll track learnings for [skill name] as I work."
Invoke this alongside another skill when ANY of these occur:
/mu at session end)Most real invocations arrive AFTER the work, via /mu, with no inline observation
log. That's fine: reconstruct observations from the transcript โ but verify each one
against what actually happened (re-read the moment; don't trust narrative memory),
and never pretend a log was kept. The checklist's "maintained observation log" row
reads "or honestly reconstructed" in this mode.
As you work with the primary skill, note observations openly in the conversation when you encounter them. The context window IS the scratchpad โ reasoning traces are already visible, so there's no need for a separate hidden phase. Just call out friction as you hit it:
SKILL_UPDATE observation: [TYPE] <what happened>
Types:
[AMBIGUITY] โ skill was unclear, had to interpret[GAP] โ skill doesn't cover this, but should[WRONG] โ skill's guidance produced a bad result[TIGHT] โ constraints too restrictive for the task[LOOSE] โ more structure was needed[ASKED_HUMAN] โ question asked that skill should have answered[JUDGMENT] โ decision made that the skill should encode[PATTERN] โ reusable pattern discovered during workKeep delivering the primary task. Observations are inline notes, not interruptions.
Once the primary skill's output is delivered, review your log and categorize:
For each observation, assess:
Only propose patches for observations that are recurring + moderate-to-high severity + general.
For each qualified observation, draft a concrete patch:
PATCH: <short title>
TYPE: [addition | modification | removal | restructure]
LOCATION: <which section of the skill to change>
CURRENT: <what the skill currently says (quote or summarize)>
PROPOSED: <exact new text or structural change>
RATIONALE: <why, grounded in the specific experience>
EXAMPLE: <concrete example from this session that illustrates the need>
Skills monotonically grow โ every session adds, nothing subtracts โ until a skill costs more context than it saves. For EVERY patch set, before proposing:
Present patches grouped by type:
For each patch, show:
On user approval:
skill(<name>): <summary of changes>| Don't | Do Instead |
|---|---|
| Stop working to write long reflections | Brief inline note, keep delivering |
| Propose patches for one-off edge cases | Only patch recurring patterns |
| Rewrite the entire skill based on one use | Targeted patches with rationale |
| Add complexity for hypothetical futures | Only encode patterns you've actually hit |
| Conflate "I did it differently" with "skill is wrong" | Ask: would the skill's way have been better? |
| Skip examples | Every patch needs a concrete example from this session |
Use skill โ hit friction โ note inline โ keep working
โ
Deliver primary output
โ
Distill observations โ draft patches
โ
Propose to user โ apply approved changes
โ
Next use benefits from improvements
โ
Repeat (skills converge toward robustness)
Primary skill: canvas-diagrams (L3 data flow) Task: Map Beeper API fields โ storage decisions
Inline observations as they happened:
Building Beeper canvas... the skill says L3 is "5-10 nodes" but I've got 24 fields to map.
SKILL_UPDATE observation: [TIGHT] L3 node count too restrictive for field-level mapping
Need to show discarded fields in red but the skill only has component-type colors.
SKILL_UPDATE observation: [GAP] No color convention for retained vs discarded data fate
Using horizontal layout โ vertical spine doesn't work for sourceโdestination comparison.
SKILL_UPDATE observation: [PATTERN] Data-mapping needs 3-column horizontal, not vertical spine
Resulting patches (after delivery):