A Claude skill is a folder. That one fact answers most of the lifecycle questions people ask, including how to disable a Claude skill you no longer want firing in every session. The skill lives at ~/.claude/skills/<name>/SKILL.md for your personal skills, or at .claude/skills/<name>/SKILL.md inside a project. Once you accept that skills are just files on disk, enabling, disabling, listing, and deleting them stop being a mystery. They become file management with a few extra knobs.
Most people accumulate skills the way they accumulate browser tabs. You install one to summarize PRs, another to scaffold a component, a third from Slack, and three weeks later Claude is loading a skill you forgot existed. So here is the cleanup guide.
How to list Claude skills that are installed
The fastest way to see what is loaded: ask Claude.
Type What skills are available? in a session and Claude reports the skills it can see, by name. This is the same check the Anthropic docs recommend when a skill is misbehaving. It reflects reality, including project skills picked up from parent directories and any plugin skills in the mix.
For an interactive view, open the /skills menu. It lists your skills and lets you change their visibility state inline, which I will come back to under disabling. There is also /doctor. It tells you whether your skill descriptions are getting truncated because too many are loaded at once. If Claude keeps ignoring a skill you know is installed, /doctor is where you find out the description budget overflowed.
The Claude skills command surface is the / menu itself. Type / and you see every user-invocable skill alongside built-in commands and bundled skills like /code-review and /debug. Skills you can invoke by hand show up there; skills marked user-invocable: false do not.
How to disable a Claude skill
There are four verified ways to disable a skill, and which one you reach for depends on whether you own the file.
If you wrote the skill, edit its frontmatter. Adding disable-model-invocation: true to the SKILL.md stops Claude from loading it automatically. The skill stays installed and you can still run it by hand with /name. Claude just will not decide on its own that now is the time to deploy. The docs are blunt about why this matters for anything with side effects: you do not want Claude running /deploy because your code happens to look ready. And if you want the skill gone from the slash menu too, because it is background knowledge that should never be a command, use user-invocable: false instead.
If you do not want to touch the file, because it is checked into a shared repo or came from an MCP server, use the /skills menu. Highlight a skill, press Space to cycle its states, Enter to save. That writes a skillOverrides entry to .claude/settings.local.json for you. You can also write it by hand:
{
"skillOverrides": {
"deploy": "off",
"legacy-context": "name-only"
}
}
The states are on, name-only, user-invocable-only, and off. Setting a skill to off hides it from Claude and from the / menu without modifying the skill itself. One thing to know: skillOverrides does not touch plugin skills, which you manage through /plugin.
The blunt instrument is permissions. Deny the Skill tool in /permissions and Claude cannot invoke any skill at all. Or deny one by name with Skill(deploy *). Reach for this when you want a hard policy boundary instead of a per-skill toggle. It is also the only option here that an organization can enforce centrally, which is why it tends to show up in locked-down setups.
How to delete a Claude skill
Delete the folder. That is the whole procedure, and it is also the answer to how to remove a Claude skill, because the two words mean the same thing here.
A personal skill at ~/.claude/skills/old-thing/ goes away the moment you remove that directory. Same for a project skill under .claude/skills/. Claude Code watches those directories and picks up the change within your current session, so you do not have to restart to remove a skill mid-session. Creating a brand new top-level skills directory is the one case that needs a restart. Deletion is not.
On macOS or Linux:
rm -rf ~/.claude/skills/old-thing
On Windows PowerShell:
Remove-Item -Recurse -Force ~\.claude\skills\old-thing
If you committed the skill into a project repo, deleting the folder and committing that deletion removes it for your whole team. There is no separate uninstall command to learn, because there was no install database to begin with. The filesystem is the source of truth.
How to enable a Claude skill
Enabling is the inverse of whatever you did to disable it, which is why the file-based mental model pays off.
If the skill is not installed yet, put its folder in place. Adding a skill is the mirror image of removing one, and I wrote a separate walkthrough on that: see how to install a Claude skill.
Disabled it through frontmatter? Remove the disable-model-invocation: true line (or set it to false) and Claude can auto-load it again. Turned it off through skillOverrides? Flip the value back to on in settings.local.json, or cycle it back in the /skills menu. Denied it in permissions? Remove the deny rule. In every case the skill becomes available the moment the change is saved, thanks to the same live-reload that handles deletion.
Disabling versus deleting: pick the right one
These solve different problems and people conflate them constantly.
Disabling keeps the skill on disk and turns off automatic invocation, or hides it from a menu, while leaving you the option to run it manually or re-enable it in seconds. Reach for it when you trust a skill but do not want it firing unprompted, or when you are temporarily silencing one while you debug something else. Deleting is heavier. It removes the folder and the skill is gone until you reinstall it. That is what you want for skills you genuinely do not need anymore, or ones you suspect are unsafe and want off your machine entirely.
My rule of thumb: disable when you are unsure, delete when you are sure. Disabling is reversible with one keystroke in the /skills menu, whereas a deleted personal skill means hunting down the original source again. And if a skill you disabled keeps firing anyway, or one you re-enabled refuses to load, the cause is usually a name collision across scopes or a description that is too vague to match. Both are covered in why your Claude skill is not working.
One more thing, about authoring. The whole lifecycle gets calmer when the skills you install are well-scoped from the start, with tight descriptions and sane invocation defaults, so Claude is not constantly guessing. That is the part Knack handles. You answer a short interview and it produces a clean SKILL.md folder with the frontmatter already set the way you would want it. A skill that was scoped right rarely needs disabling in the first place.
Skills follow the open Agent Skills standard, so the folder-on-disk model carries across the tools that adopt it. Learn the folder, and you have learned the lifecycle.