Your team has too many AI skills. Two rules decide which ones stay.

Once everyone on a team has an AI agent, everyone starts writing skills. A coding skill, a skill for replying to customers, a skill for weekly reports. Six months later, ask how many skills the team has and nobody knows. Ask how many are in use and the answer is worse.

We run into this at almost every team we work with, and we ran into it ourselves. In How to make AI work for teams we said the deeper you deploy AI, the fewer skills you need. This post is the practical version: what a skill is for, why more of them makes things worse, and the two rules we use to decide which ones stay.

What a skill actually is

A skill is an SOP plus the knowledge and standards behind it: how a job is done, what good looks like, what must never happen. Most agents now read the same open Agent Skills format, a folder with a SKILL.md, so one skill can work across Claude Code, Codex, Cursor and others.

That explains what goes inside a skill. It does not explain why a skill should exist as its own thing. Here is our answer: a skill is a button. It is the point where a person explicitly asks AI to do a job a particular way. Everything else an agent does, it can work out from the team's shared context. A skill earns its place because someone decides to press it.

Seen as buttons, the problem with having many skills is obvious.

Why more skills makes things worse

• Idle buttons. Every new skill splits the same people across more buttons. The more skills you have, the fewer people use each one, and the more sit untouched.
• Ten versions of one job. When everyone writes their own coding skill, the team ends up with ten skills for the same work. None of them pools what the whole team knows. You have one strong way of working, split into ten weaker ones.
• Knowledge locked in the wrong place. Customer lists, brand rules, pricing and product facts get pasted into skills. Each copy drifts, and the next skill starts from scratch.
• Nobody can take over. Picture the colleague who wrote a hundred skills and then left. Nobody knows which ones matter, and nobody wants to maintain someone else's hundred files.

Design skills around taste

Before writing a skill, ask one question: which jobs need a person to apply judgment? Approving a campaign. Deciding whether a customer reply is good enough to send. Choosing which feature request goes on the roadmap. Those jobs need a button, because a person has to be in the loop.

Everything else is either knowledge, which belongs in the team's shared context, or pure execution, which should run on its own.

The two rules

Any skill that stays must pass both:

1. Someone uses it every week. If nobody pressed the button this week, the skill does not need to exist.
2. It needs a person's judgment. If the job is pure execution, automate it fully and stop asking people to press anything.

Put together, every skill lands in one of four boxes:

Teams are usually surprised by how little survives. That is the point. The few that remain are the jobs where your team's taste lives, which makes them the core of how you work.

Running the audit

You can do a first pass in an afternoon:

1. List every skill, everywhere. Personal agent folders, repositories, shared drives. Include the ones people forgot.
2. For each one, write down three things: who used it in the last two weeks, what judgment it asks a person to make, and what knowledge is pasted into it.
3. Move the knowledge out. Facts about customers, products, brand and pricing go into the team's shared context, where every agent and every skill reads the same copy. The skill keeps only the method.
4. Merge duplicates. For ten coding skills, pick whose approach survives. This is a management decision and a matter of taste, so make it deliberately instead of letting the newest file win.
5. Apply the two rules. Keep, automate, retire, or delete.

Fewer skills does not mean less care

The skills that remain are team assets, so treat them that way.

• Give each one an owner with high standards, someone who cares whether the output is good.
• Make it a daily entry point. Put the skill at the step that matters, so people open it and respond to it every day.
• Improve it at least once a week. A skill that stops changing has stopped learning from the people who use it.
• Keep one shared copy. Everyone runs the same version. A change is reviewed once and then applies to everyone.

What about the hundreds of skills in community directories and courses? Browsing many skills is a good way to learn methods and find ideas. Inside one company, though, narrow the buttons and put the knowledge back where everyone can reach it.

How Busabase handles this

In Busabase, skills live in the workspace as Skill nodes, stored next to the data they explain. That makes the rules above the default behavior:

• One copy for everyone. Every connected agent reads the same skill body, so results do not depend on whose laptop the skill happens to sit on.
• Changes are reviewed once. Edits to a skill go through a change request, and once merged they apply to every agent at the same moment.
• No copies per repository. busabase-cli skill link writes a small pointer file that fetches the body when it is used, so five repositories do not end up with five drifting copies.
• Agents find the button themselves. Before starting a job, agents look for a matching skill in the workspace, so a well-named skill gets used. Agent Playbooks explains how to name and describe one so it is found.
• The skill outlives its author. It belongs to the workspace, not to the person who wrote it.

Start with the audit, not the tool. Count your skills this week, apply the two rules, and see what is left. If you want one shared place for the survivors, start free on Busabase Cloud.

Fewer buttons. Better buttons.