Skip to main content
ClaudeREF.com
← content/article
6 September 202610:003 min readby Shai Chikorel

Use /skill-doctor to trim Claude Code skill context safely

A practical, reversible workflow for using Claude Code's /skill-doctor report to find unused skill listings, reduce context overhead, and keep the skills that earn their place.

#claude-code#skills#context#workflowsource ↗
Use /skill-doctor to trim Claude Code skill context safely

// key takeaways

  • /skill-doctor identifies loaded skills that have gone unused and shows their context cost; it does not prove a skill is useless.
  • Use the report to make a small, reversible change, then retest a real task before removing more skills.
  • Keep skills with a clear, recurring job even when they are not used in every session.
  • Run the command in the terminal session on the machine that owns the skills; Remote Control cannot provide its usage report.
On this page

Start with evidence, not a purge

Claude Code's skill list is part of the context it prepares so the model can discover available workflows. That makes a large skill collection worth inspecting, but an unused skill is not automatically bad. A release-only skill, a migration playbook, or an incident-response workflow may be exactly the thing you need once a quarter.

The useful question is narrower: which skills are paying a context cost in ordinary sessions without helping the work you actually do? Anthropic announced /skill-doctor in the v2.1.261 release notes, while the current skills reference lists v2.1.252 or later as the minimum version. It reports loaded skills that have gone unused and their context cost, so you can decide which ones to prune. Anthropic's v2.1.261 release notes and the current skills reference document the command's rollout, availability, and purpose.

Run it at the end of a representative terminal session:

/skill-doctor

Choose a session that reflects normal work: for example, an implementation task that uses your usual project instructions, plugins, and skills. Do not treat one short documentation edit as a verdict on every specialized workflow in your setup.

Read the report as a triage list

The report gives you two useful signals: whether a loaded skill was invoked, and what it costs in context. Start with a high-cost skill that has not been used across the kind of work you do most. Then classify it before changing anything.

  • Keep a skill with a clear owner and a real recurring or high-risk job. Security review, deployment, and incident skills can be valuable even when they are infrequent.
  • Improve a useful skill whose description is vague or overlaps another skill. Better names, clearer descriptions, and narrower triggers can make the right workflow easier for Claude to select.
  • Disable temporarily a duplicate, obsolete, experimental, or project-irrelevant skill. This is the best first move because it gives you a comparison without throwing away the source.
  • Remove only after the disabled version has survived real work and you know where the original is versioned or recoverable.

This distinction matters. The report measures recent usage and context impact; it does not assess whether the instructions are correct, safe, or strategically important.

Make one reversible change

Use the setting scope that matches where the skill belongs. A project-only experiment should live in that project's local settings; a personal skill can be disabled in your user settings. Keep the change small enough that you can attribute the result.

{
  "skillOverrides": {
    "old-release-notes": "off"
  }
}

The exact setting location and available scopes are documented in Anthropic's skills guide. Do not disable a skill by deleting its files first. A reversible override lets you restore it immediately when a task exposes a gap.

After changing one or two candidates, start a fresh normal session and repeat the same class of task. Look for concrete effects: did Claude still select the right workflow, did it miss an important instruction, and did the session feel easier to steer? Re-run /skill-doctor after enough representative work to see whether the change reduced the listing without creating a new problem.

Know the boundaries

/skill-doctor is a local-session diagnostic, not a universal inventory system. Anthropic's release notes describe the command as showing loaded skills that go unused and their context cost. That means its result is tied to the current machine and session context. It is also not a reason to remove bundled or managed capabilities that you do not control.

When using Remote Control from a phone or browser, run the command in the terminal on the machine where the session is running. The usage report needs that local session information, so a remote connection cannot supply it.

A maintenance cadence that stays useful

Run /skill-doctor after a plugin-installation spree, after retiring a project, or once every few weeks if your personal setup evolves quickly. Keep a short note beside each disabled skill saying why it was turned off and how to re-enable it. That converts a one-time cleanup into a controlled maintenance practice.

The win is not the smallest possible skill list. It is a skill list where every loaded instruction has a job, an owner, and a reason to be there.