Claude Code knows a lot about programming in general, but very little about the tools and conventions we use every day. Skills close that gap. A skill is nothing more than a Markdown file with instructions that Claude loads when it needs it. Let us see how we can add a few useful ones to our setup, and how we keep that setup from growing out of control.
How to install skills
Most skills ship as plugins, plugins live in marketplaces, and a marketplace is just a Git repository. We add the marketplace and then install the plugin from it:
If we prefer to browse, /plugin opens an interactive menu with everything from all marketplaces we added. After an installation we run /reload-plugins and check the result with /skills.
For Python: the Astral plugin
The Astral plugin brings skills for uv, ruff and ty, so Claude uses these tools the way their authors intended instead of guessing. We invoke a skill directly with /astral:uv.
Claude does not always reach for a skill on its own. The README therefore recommends putting a line like this into our CLAUDE.md:
When working with Python, invoke the relevant
/astral:<skill>foruv,ty, andruffto ensure best practices are followed.
That single sentence is the difference between having skills and actually using them.
For .NET: the official dotnet/skills repository
The .NET team maintains its own curated marketplace, split into one plugin per topic: dotnet, dotnet-test, dotnet-upgrade, dotnet-aspnetcore, dotnet-blazor, dotnet-msbuild and more.
We only install what our projects need, which keeps the noise down. New versions arrive with /plugin update dotnet-test@dotnet-agent-skills.
For frontend work: the official design skill
Anthropic's own marketplace is registered automatically, so this one is a single command:
This frontend design skill pushes Claude away from the default look every AI produces (Inter font, purple gradient, three grid cards) and towards a deliberate design direction. The nice part: we do not have to call it. It activates on its own as soon as we ask for a user interface.
To see the changes in action, we can look at the result of the Image Locator challenge. The first image shows the output before I installed the skill, the second one was with the skill in place – the prompt to create the application was identical:
Three developer skills
Here are three more skills that can help us to develop our applications:
- security-guidance reviews every change Claude makes for common vulnerabilities and has it fix the findings in the same session.
- commit-commands adds the git workflow: commit, push and pull request creation, with messages that describe what changed.
- pyright-lsp or csharp-lsp give Claude a language server. It then sees type errors and missing imports immediately after an edit instead of finding them at the next build. We must install the language server binary ourselves; the plugin does not do it for us.
When skills get in each other's way
The description in a skill is not documentation, it is the trigger. Claude matches our request against it to decide what to load. Two skills with similar descriptions are therefore a real problem: Claude picks the wrong one, or none at all.
The second problem is budget. Claude Code always loads every skill name into context, but the descriptions must fit a character budget of one percent of the context window. If we install too much, descriptions get truncated, starting with the skills we invoke least. The skills we barely use quietly degrade the ones we rely on.
It also helps to know where a skill can live, because the location decides who sees it and which copy wins:
| Level | Where it lives | Who gets it |
|---|---|---|
| Enterprise | rolled out by administrators through managed settings | everyone in the organisation |
| Personal | ~/.claude/skills/<name>/SKILL.md |
all of our own projects, on this machine |
| Project | .claude/skills/<name>/SKILL.md in the repository |
this repository, and everyone who clones it |
| Plugin | the skills/ folder inside the plugin |
wherever that plugin is enabled |
If the same skill name exists at several levels, enterprise beats personal and personal beats project, which is the opposite of what most of us expect. A deploy skill in our home folder therefore silently shadows the deploy skill the team carefully committed to the repository, and nothing warns us about it. Plugin skills are the exception: they are namespaced as plugin-name:skill-name and can never collide.
A skill at any of these levels also replaces a bundled skill with the same name. That is annoying by accident and useful on purpose, because it lets us put our own code-review into the project and have /code-review follow our review checklist instead of the built-in one. The full rules are documented under Where skills live.
The fix is /skills. Highlight an entry, press Space to cycle it between visible, name-only and off, then Enter to save the result to .claude/settings.local.json. A skill set to name-only stays available but stops eating budget.
A health check for our skills
Once a quarter it is worth asking what all of this actually costs us.
Start with /doctor. It estimates how much context our skill listing consumes and names the biggest contributors. /context then shows the Skills row with the size that really reaches the model.
For plugins, open /plugin and go to the Installed tab. Claude Code collects everything we installed ourselves but have not used for at least two weeks across at least ten sessions under a Not used recently heading, and each entry shows a Last used date. That list is our cleanup queue. Plugins that only contribute a theme or an output style are never flagged, because they work without ever being invoked.
Everything on that list still costs us startup time and context on every single session. We disable a candidate first with /plugin disable name@marketplace, work for a week, and only then uninstall it. Anything we do not miss was not helping us.
Next
The right skill will help us to get better results with Claude Code. But do not overdo it and install all the skills that could be helpful. They fill up the context, and we end up with conflicting skills that degrade Claude instead of improving it.
Next week we write our own skill, and we look at skill-creator, the plugin that helps us test whether it actually fires.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.