Skills and plugins

Everything in this area comes down to one question: where does your team’s know-how live, and what makes it show up at the right moment? A skill is the answer that requires nobody to remember anything. You write down how a job should be done, and Claude picks the file up when the job appears.

The mechanic worth understanding is that skills are matched by description, not by you. What Claude keeps in view is a one-line “use this when…” for each skill; the full instructions get read only once one looks relevant. That has a pleasant consequence — installing thirty skills costs you thirty short lines, so the twenty-nine that don’t apply today are close to free — and one demanding one: a sharp description matters more than beautiful instructions, because a skill nobody triggers is a skill nobody has.

A plugin is not a different idea, it’s packaging. It’s a bundle — some skills, some slash commands, maybe a hook and a tool connection — installed with a single /plugin install. Think of it as distribution rather than capability. If you’ve assembled a setup that works and you want twelve colleagues on it by Friday, a plugin is how it travels.

Placing all this against its neighbours is most of the confusion, so: a slash command fires when you type it, a skill fires when Claude judges it relevant, and project memory is always on for one specific project. Same raw material — written instructions — three different triggers. A plugin can carry any of them. The comparison pages below draw those lines properly.

One honest note on effort. Using a skill is invisible; authoring one means creating a file, which puts it on the team-setup side of the line rather than the everyday-chat side. It isn’t coding — the content is prose — but it’s the kind of thing one person usually does on behalf of a team, once, and then everyone inherits it.