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. |
| Is it actually used? | Unknown. | Every skill shows real usage: runs, people, last run. |
| 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, Review, Library, Use, Prove. 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 joins the company's skill library with an owner and a version. The team runs it in Claude with nothing new to install (one command for engineers, zero for everyone else). And every skill shows its real usage, because a skill nobody runs is a problem worth seeing: zero is information.
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 number that tells the truth about adoption.
What to measure
Three numbers per skill are enough to run the whole system: how many times it ran in the last 30 days, how many distinct people ran it, and when it last ran. Together they answer the questions leaders actually ask: is our know-how being reused, by how many people, and which skills are quietly dying. Counting stays event level (skill, version, timestamp), never content, so proof of usage never turns into surveillance of people.
How knacks helps
knacks is the company skill system 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, skills run in Claude everywhere, and real usage is visible on every skill. Nothing enters knacks unless someone chooses to publish it.
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