Use Your Skills

Use your skills

A drift corrector for skill-use discipline: the skills are in context to be used, not ignored. The method, re-anchor, audit the work in flight, correct forward, report, and the tone that firing this is not an accusation, lives in ${CLAUDE_PLUGIN_ROOT}/context/re-anchor-audit-correct.md. Read it; this file adds only what is specific to discovering and invoking the skills already available.

The discipline this re-anchors

A skill listing is loaded into context so the model knows what is available: every model-invocable skill's name (always) and its description (subject to the listing budget), with the full body loading only when the skill is invoked (Skills docs, fetched 2026-08-10). The listing covers only what the MODEL can reach, a skill set to disable-model-invocation: true is manual-only: its description is not in the model's context and the model never auto-invokes it, so it surfaces only when a user types /name (the inverse, user-invocable: false, stays in the model's listing but is hidden from the / menu). This corrector therefore audits only what the model could actually have reached: a model-visible skill that sat in the listing and went unused, its procedure reinvented. Or skipped. Instead of invoked. It does not fault the model for not auto-firing a manual-only skill that was never in its listing. Over a long session the listing loses salience the same way a standing rule does; this re-anchors the habit of consulting it.

The discipline, at each of the three surfaces where skills apply:

• This conversation. Before doing multi-step or specialized work, scan the in-context listing for a skill that already owns it, and invoke that skill rather than improvising the procedure. A skill's description is written to say when it applies. Read it as a routing signal, not decoration.
• The current task. Map the task's shape to the skills that fit it. Often more than one across a task's phases (research, plan, implement, review), and invoke each at its moment rather than carrying the whole task by hand.
• Delegated (subagent) work. A fresh non-fork subagent does not inherit your skill listing. It discovers project, user, and plugin skills on disk through the Skill tool during execution (Subagents docs, re-verified 2026-09-06 against Claude Code 2.1.263; recheck when that page stops stating that a subagent can invoke unlisted project, user, and plugin skills through the Skill tool, or a release note names skill preloading). So name the relevant skills in the delegation prompt so the subagent knows to reach for them. For a custom subagent that should always carry a discipline, recommend its skills: frontmatter, which preloads the full skill content into the subagent at startup (preload, not access. The Skill tool is already available to the subagent unless removed via tools / disallowedTools). One caveat, doc-confirmed: skills: can preload only a model-invocable skill; a skill set to disable-model-invocation: true cannot be preloaded (Claude Code skips it and logs a warning), because preloading draws from the same set the model can invoke. For a manual-only discipline, put its guidance in the prompt directly rather than expecting a preload. This is guidance, not a config change the skill performs.

Audit. What to look for

Name concrete, located findings (per the method doc's step 2, self-audit):

• a multi-step or specialized task carried by hand where a skill in the listing already owns that exact procedure;
• a procedure reinvented from scratch that a listed skill would have supplied;
• a task phase (research, planning, review, verification) done ad hoc where a fitting skill went unconsulted;
• a delegation prompt to a subagent that names no skills, leaving the subagent to rediscover, or miss, a discipline it should have carried;
• a custom subagent that repeatedly needs a discipline but does not preload it via skills:.

Correct each forward now: invoke the skill this turn and let it govern the work rather than merely noting it existed; re-issue the delegation prompt with the relevant skills named; and where a subagent should always carry a discipline, recommend the skills: preload. Where the audit finds the right skills were in fact used, say so, a clean audit is a correct outcome.

Out of scope. Routed, not owned

This skill corrects session behavior. what should have fired and didn't. It does not own the levers that decide whether a skill can surface. Route those:

• A skill's description quality. Key use case first, natural trigger keywords, within the per-entry character cap, is skill-authoring QA. Route to /skill-quality:check, invoked via the Skill tool (degrade to prose guidance when not installed).
• The listing budget across all installed skills, the listing is capped at a fraction of the context window, and on overflow descriptions are dropped from the least-invoked skills first, so a real skill can silently lose its triggering keywords. That machine-level overflow is a configuration concern; route to /claude-config:audit, invoked via the Skill tool (degrade to prose). /doctor estimates the listing's cost.
• Deterministic per-prompt routing. A UserPromptSubmit hook that injects a task-to-skill mapping on every message is an always-on mechanism with a per-prompt token cost, owned by a hooks-capable plugin, not by this corrector. Recommend it to the user only when the soft re-anchor repeatedly fails to surface a skill that was in the listing.

The dividing line: if a skill was in the listing and simply went unused, that is this skill. If a skill could not surface because its description was thin or the listing overflowed its budget, that is the routed territory above.

What this skill does NOT do

• Does not tune descriptions or budgets. Description hygiene routes to /skill-quality:check; listing-budget overflow routes to /claude-config:audit. Both are invoked via the Skill tool. This skill audits use, not surfaceability.
• Does not force-invoke an ill-fitting skill. The goal is to use the skill that fits, not to fire one for its own sake; "no skill fits, proceeding directly" is a valid outcome.
• Does not mutate config or frontmatter at runtime. The subagent skills: preload and hook options are recommendations routed to the user, not changes the skill makes.
• Does not fabricate a finding. Work that already invoked the fitting skills audits clean; say so.

Gotchas

• The listing carries every skill name always, but when many skills are installed the descriptions can be trimmed to fit the budget, so a skill whose description looks absent may be budget-dropped, not missing. That is a routed concern (above), not evidence the skill does not exist.
• A subagent's silence on skills is easy to miss: it will not error, it will just do the work without the discipline the parent took for granted. The fix lives in the delegation prompt (name the skills) or the agent definition (skills: preload), not in the subagent's own run.
• Invoking a skill IS the re-anchor. Reading its description and then improvising the procedure anyway is the exact drift this corrects.