Skills changed what it means to be good at Claude. Before skills, expertise lived in prompting habits; now it can live in a file. A skill packages the method in plain language, the reference files it needs, examples, and tests, and Claude applies it whenever the task matches. Write a good renewal prep skill once and every renewal call after that starts from your best version.
That is exactly why skills become a company question the moment more than one person is involved. A skill that saves one rep an hour per call would save the whole team a day per week. But most companies have no answer to the obvious next questions: where do shared skills live, who says a skill is good enough to share, which version is current, and is anyone actually using it?
What is a Claude skill?
A Claude skill is a small, versioned piece of know-how built around a markdown instruction file: when to use the method, the steps, which tools to call, plus the reference files it needs (a pricing grid, a policy document, a report template) and worked examples. Claude reads the format natively, so the skill does the work rather than describing it. Because skills are plain files, they are portable by design: they belong to whoever owns the folder, not to a vendor.
Personal skills vs company skills
The gap between a skill that works for you and a skill a company can rely on is ownership, review, and proof. This is the difference in practice:
| Question | Personal skill | Company skill |
|---|---|---|
| Where does it live? | A local folder or a chat attachment. | One skill library in a repository the company owns. |
| Who says it is good? | Nobody. It worked once. | The team lead (the domain expert) reviews and approves it. |
| Which version is current? | Unknown. Copies diverge silently. | A named owner, a version, and a one line changelog per update. |
| How does it improve? | It does not. It stays as written. | The owner updates it once, changelog included, and everyone gets it. |
| What happens when the author leaves? | The skill leaves with them. | The library keeps it, with an owner to reassign. |
How a team shares Claude skills: the knacks loop
We run team skills through a five step loop we call the knacks loop: Publish, Approve, Ship, Use, Improve. Someone describes a method they keep repeating, in plain English, and it becomes a draft skill with examples and tests. The team lead, not IT, reviews and approves it. The approved skill ships to the whole team in Claude with nothing new to install (one command for engineers, zero for everyone else). And when the owner improves it, everyone is on the latest version immediately, changelog included.
The loop matters more than the tooling. Even a team running it manually in a shared repository beats a folder of unowned prompt files, because every skill has a person who vouches for it and a version everyone can trust.
What to look at
You do not need usage dashboards to run the system, and knacks does not track usage at all: no counters on people, no record of who runs what. What matters is the health of the library itself, and it is fully visible: how many methods became approved skills, whether every skill has a named owner, and how fresh the versions are. A library where skills have owners and recent changelogs is alive; a folder of unowned files is an archive.
How knacks helps
knacks is the approval layer for the AI your employees are building. Today that means company skills, built on this loop. Non-technical people publish methods in plain English, team leads approve them, the skill library lives as plain markdown files in a GitHub repository the company owns, and skills ship to everyone in Claude, current by default. Nothing enters knacks unless someone chooses to publish it, and knacks never tracks who runs what.
Give your team its skill library.
Book a walkthrough. Bring one team and one repeated task, and leave with your first skill: published, approved, and in use.
Book a walkthrough