Menú
Meta-skill for learning from skill usage. Tracks uncertainties, human interventions, and gaps discovered during use, then proposes concrete skill patches.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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.
Graceful context transfer before session end or compaction. Commits work, documents pending threads, captures learnings, and prepares the next instance to continue seamlessly.
Find scattered enforcement of a single invariant — N competing guards for one rule, exemption flags that defeat several at once, one setting under several env-var names/defaults, one resource with several definitions, overlapping thresholds owned by different components, and settings whose meaning depends on which process reads them. Use when config feels duplicated, when a documented setting mysteriously didn't apply, after an incident where "the safety net didn't fire", or before refactoring a subsystem that has accumulated guards.
Audit whether the code tells the truth about itself — names that lie (validate_* that doesn't validate, get_* with side effects), docstrings and comments claiming behavior or guarantees the code no longer has, comments citing mechanisms that exist but are neutralized, one concept under many names, the same logic forked under different names, and band-aid layers each sensible in isolation that together form unnecessary complexity. Use after high-velocity or AI-assisted development, before onboarding someone, or when the code "reads fine" but keeps surprising people.
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.
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.
| 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):