Skills, tools and knowledge bases are what make Claude Desktop productive. Used well they save time; used badly you get the next plugin glut. Here I sort out the terms and show how a skill library stays clean in a team.<\/p>\n\n\n\n
Skill: an instruction for a recurring task.<\/strong> A skill bundles a description, prompts and examples for a clearly defined task. Claude selects it as soon as the task matches the description.<\/p>\n\n\n\n Tool: a concrete function Claude may call.<\/strong> Tools usually arrive in the app via MCP servers. A tool sends an email, reads a file or creates an appointment \u2013 an atomic command with input and output.<\/p>\n\n\n\n Extension: a bundle of skills, tools and configuration.<\/strong> An extension packages a coherent set, for example for research or code review. You install it once and get a consistent experience.<\/p>\n\n\n\n Knowledge base: a structured knowledge store.<\/strong> A knowledge base supplies Claude with long-lived context \u2013 product docs, brand ground rules or common answers. It complements skills, it does not replace them.<\/p>\n\n\n\n A clear task description.<\/strong> The front matter states when the skill applies. If the description is vague, Claude picks it either too rarely or too often.<\/p>\n\n\n\n Two or three examples.<\/strong> Concrete before-and-after examples beat abstract rules. A skill without examples feels like an unused template in practice.<\/p>\n\n\n\n The expected result format.<\/strong> Markdown, table, JSON or free text \u2013 define the result and you get reliable output.<\/p>\n\n\n\n Clean boundaries.<\/strong> A skill should describe what it does not do. That avoids hallucinations at the edge of the task.<\/p>\n\n\n\n I introduce five ground rules as soon as more than three people are involved.<\/p>\n\n\n\n Recurring questions.<\/strong> If the same explanation shows up in five threads a week, a knowledge base saves more time than it costs to build.<\/p>\n\n\n\n A stable source.<\/strong> Product docs, brand ground rules or contracts are ideal. Fast-changing content belongs in a live source via MCP instead.<\/p>\n\n\n\n Clear ownership.<\/strong> One person keeps the knowledge base current. Without an owner, every knowledge store goes stale in under six months.<\/p>\n\n\n\n Skills bundle knowledge, prompts and examples for a recurring task. MCP servers provide functions or data. Skills use MCP but are not servers themselves. Simplified: MCP is the socket, a skill is the tool plugged into it.<\/p>\n\n\n\n In the app’s configuration path under the skills directory. Each skill is a folder with a description in the file skill.md and optionally further files such as templates or example prompts.<\/p>\n\n\n\n Yes. Skills are a client-side feature of the app and are available on all plans. For shared skill libraries in a team, though, at least the Team plan is advisable because you need central management.<\/p>\n\n\n\n Less is more. Three to seven well-described skills per role are enough in practice. A sprawling library makes Claude pick the wrong skills \u2013 that costs time and trust.<\/p>\n\n\n\n Yes, via a shared repository. The skill folders are versioned, the configuration path symbolically linked. Everyone sees the same tools and updates roll out in a controlled way.<\/p>\n\n\n\nHow I write skills that hold up day to day<\/h2>\n\n\n\n
How to avoid the plugin graveyard<\/h2>\n\n\n\n
\n
When a knowledge base really pays off<\/h2>\n\n\n\n
Frequently asked questions<\/h2>\n\n\n\n
What is the difference between skills and MCP servers?<\/h3>\n\n\n
Where do I store my own skill?<\/h3>\n\n\n
Do skills work without a Pro or Team plan?<\/h3>\n\n\n
How many skills make sense?<\/h3>\n\n\n
Can we share skills across a team?<\/h3>\n\n\n