# Skills and Plugins

> Two ways to extend an AI assistant: skills teach it reusable know-how, plugins give it new powers. What each is, how they differ, and how to add or write your own.


---

# Skills and Plugins

Out of the box, an AI assistant knows a lot but does little. It can talk about your company's brand guidelines, but it hasn't read them. It can describe how to file a Jira ticket, but it can't file one. The gap between "knows about" and "can actually do" is where skills and plugins live.

These are the two main ways to extend an assistant past its default behavior, and people mix them up constantly. A **skill** is reusable know-how - packaged instructions and reference material the assistant pulls in when the moment calls for it. A **plugin** is a bundle that adds new powers - commands, tools, and connections to outside systems the assistant couldn't reach on its own. One changes what the assistant *knows how to do well*; the other changes what it's *able to touch*. Most real setups use both.

This guide is for anyone customizing an AI assistant for real work - a founder shaping it around their business, an ops lead wiring it into their tools, a writer who wants it to nail their house style every time. You don't need to be an engineer. Phase 1 unpacks skills: what they are and why a few pages of packaged instructions beat re-explaining yourself every session. Phase 2 covers plugins and how they hand the assistant capabilities a plain skill never could. Phase 3 gets practical - installing one someone else built, and writing a small skill of your own from scratch. By the end you'll know which tool fits which job, and you'll have made one yourself.


---

# Skills: Reusable Know-How

Picture the colleague who's done a thing a hundred times. You hand them a messy task and they don't need a tutorial - they have a checklist in their head, the template saved somewhere, the three gotchas they always check. A skill is that, written down and handed to the assistant.

More concretely: a skill is a folder. Inside it sits a short description of what the skill is for, a set of instructions for how to do the task, and any files the assistant might need along the way - a style guide, a template, an example, a small script. The assistant keeps the description in view all the time, but only reads the full instructions when a task actually matches. That last part matters more than it sounds, so let's sit on it.

## Why not put everything in one big prompt

You could. Plenty of people stuff a giant system prompt with every rule they've ever wanted the assistant to follow, then wonder why it ignores half of them.

The problem is attention. An assistant has a working memory - the context window - and everything competing for space in it dilutes everything else. A 4,000-word block covering invoicing, brand voice, code review standards, and your meeting-notes format is mostly irrelevant to any single task. When you ask it to draft a tweet, the invoicing rules are still sitting there taking up room and muddying the signal.

Skills fix this with a two-stage trick. The assistant always sees a one-line description of each skill - something like "Format and validate customer invoices to spec." That's cheap; it's a single line. Only when your request actually looks like invoicing does it open the full skill and pull in the detailed instructions and the invoice template. The right knowledge shows up at the right moment, and the rest stays out of the way.

```text
Always loaded (cheap):
  - "Brand voice: how we write public copy"
  - "Invoice formatting: validate customer invoices"
  - "Meeting notes: turn transcripts into action items"

You ask: "draft the launch announcement"
  -> matches "Brand voice"
  -> assistant opens that skill, reads the full guide + examples
  -> the other two stay closed
```

## What goes in a skill

The heart of a skill is plain instructions written the way you'd brief a sharp new hire. Not abstract principles - concrete steps, named tools, real examples, and the mistakes to avoid.

A brand-voice skill might say: "We write in second person. No exclamation marks. Never call our product 'powerful' or 'seamless.' Here are three before-and-after rewrites." A meeting-notes skill might say: "Output three sections - Decisions, Action Items (with owner and due date), Open Questions. Ignore small talk. Here's an example from last week's standup."

Alongside the instructions, a skill can carry files. This is the quiet superpower. A template document, a checklist, a reference table of your product names, a sample of good output - the assistant reads these when it opens the skill. Instead of describing your invoice layout in words and hoping it reconstructs it, you hand it the actual template and say "match this."

## What a skill is not

A skill doesn't give the assistant new abilities. It can't make a model that can't browse the web suddenly browse the web, and it can't reach into your database or send an email on its own. A skill is knowledge and guidance - it sharpens how the assistant uses the powers it already has. Adding genuinely new powers is what plugins are for, and that's the next phase.

It's also worth being clear about the term. "Skill" in this packaged-folder sense became common through Anthropic's Claude tooling and similar agent platforms, and the exact shape - what files are required, how triggering works - varies between products and is still settling. The *idea* is consistent everywhere: bundled, reusable, loaded-on-demand know-how. The specific file format is not yet a universal standard, so check the docs for whichever assistant you're using.

## When a skill earns its keep

Reach for a skill the moment you notice yourself explaining the same thing twice. If every week you paste the same instructions for formatting a report, that's a skill waiting to be written. If you keep correcting the assistant's tone the same way, that correction belongs in a skill, not in your fingers.

The test is repetition plus specificity. A one-off request doesn't need a skill - ask. But a task you'll do again, with rules particular to you that the model can't guess, is exactly what skills are built for. You write the know-how once. After that, the assistant brings it to the table on its own.


---

# Plugins: New Powers

A skill is a good briefing. A plugin is a new pair of hands.

Here's the line that separates them. A skill makes the assistant *better at* something it could already attempt with words and thinking. A plugin makes the assistant *able to do* something it flatly couldn't before - read a row from your database, post a message to Slack, run a calculation, look up today's exchange rate. No amount of clever instruction gets a model to send a real email. It needs a tool wired to your email system. That wiring is the plugin's job.

## What a plugin actually bundles

"Plugin" is a wrapper word. Open one up and you typically find some mix of three things.

**Tools.** A tool is a specific action the assistant can call, with defined inputs and outputs - `search_orders(customer_id)`, `create_calendar_event(title, time)`, `get_weather(city)`. The assistant decides when to call it and reads back what comes out. This is the part that lets the assistant *act on* the world rather than only talk about it.

**Commands.** Shortcuts you trigger on purpose, often typed as something like `/standup` or `/review`. Where a tool is something the assistant chooses to use mid-task, a command is something *you* invoke to kick off a defined workflow. Many commands are pre-packaged skills with a name on the front.

**Connectors.** The plumbing to an outside service - your GitHub, your Google Drive, your customer database, your project tracker. A connector handles the unglamorous, essential part: authenticating, fetching the right data, and handing it to the assistant in a form it can use. Under the hood, a lot of modern connectors speak a shared protocol called MCP (Model Context Protocol), which has become a common way to plug outside data and tools into AI assistants.

A single plugin might carry all three: a connector to your project tracker, a couple of tools for creating and updating tickets, and a `/triage` command that strings them into a workflow.

## Why this is a different category from skills

Skills and plugins solve different halves of the same problem, and seeing the split saves you a lot of confusion.

| | Skill | Plugin |
|---|---|---|
| What it adds | Know-how and reference material | New actions and connections |
| Changes... | How well the assistant does a task | What the assistant is *able* to touch |
| Typical contents | Instructions, templates, examples | Tools, commands, connectors |
| Reaches outside systems? | No | Yes |
| Who builds it | Often you, in plain language | Usually a developer (code involved) |
| Risk if it goes wrong | Bad output | Real action on real data |

That last row deserves a pause. A skill that misfires gives you a badly formatted invoice - annoying, harmless. A plugin that misfires can delete the wrong record, email the wrong person, or charge the wrong card, because it touches live systems. Powers come with stakes that pure guidance never has.

## The trust question

Because plugins take real actions and often hold access to your accounts, installing one is a trust decision, not a convenience one. A plugin with a connector to your email can, by design, read and send your email. That's the point - and also the risk.

Three habits keep you out of trouble:

- **Know who wrote it.** A plugin from the vendor of a tool you already use is a different proposition from one a stranger posted online. Prefer official and well-known sources.
- **Understand its reach.** When a plugin asks for access, read what it's asking for. "Read your calendar" and "manage your entire Google account" are very different grants. Give the narrowest access that does the job.
- **Watch the first few runs.** Many assistants will ask before a tool takes a consequential action - sending, deleting, paying. Keep that confirmation on while you learn a plugin's behavior. Trust it to act unattended only once you've seen it act sensibly.

None of this is meant to scare you off. Plugins are how an assistant graduates from a smart chat partner into something that actually moves work through your tools. It's the difference between an assistant that *tells you* how to clear your support queue and one that drafts the replies, files the tickets, and flags the three that need a human. The caution is the tax on that reach - pay it, and the powers are yours.

## How they work together

In practice you rarely choose one or the other. The strong setups pair them. A plugin gives the assistant a tool to query your sales database; a skill tells it how *your* team reads that data - which numbers matter, what "churn" means in your business, how to format the summary your CEO actually wants. The plugin supplies the hands. The skill supplies the judgment. Next we'll add both kinds to your own assistant.


---

# Adding and Writing Your Own

Enough theory. Let's add both kinds to a real assistant, then build a skill from scratch - a small one, but yours.

The exact buttons and folders differ by product, so treat the specifics here as the shape of the thing rather than a literal click-path. The concepts carry across; the menus don't.

## Installing something someone else built

Most assistants give you a place to manage extensions - a settings panel, a marketplace, or a config file, depending on how technical the product is.

For a **plugin**, installation usually runs like this:

1. Find it in the assistant's directory or the vendor's site.
2. Install or enable it.
3. Authorize its access - this is where it asks to connect to your Slack, your Drive, your database. Read the request. Grant the narrowest scope that does the job.
4. Test it on something low-stakes before you trust it with anything that matters.

For a **skill**, installation is lighter because there's no live system to connect. You typically drop the skill's folder into a designated location, or import it through the assistant's interface, and it shows up as available. Some assistants ship a settings file where you list the skills and plugins you want active. It tends to look something like this:

```json
{
  "skills": [
    "brand-voice",
    "meeting-notes"
  ],
  "plugins": [
    "github-connector"
  ]
}
```

Once it's in, you generally don't summon a skill by name. The assistant notices when a task matches and reaches for it on its own - which is exactly why the next part matters so much.

## Writing a skill: the three pieces that matter

A skill comes down to three decisions. Get these right and the rest is detail.

### 1. The description - your triggering sentence

The description is one or two lines the assistant always sees, and it's the single most important thing you'll write. It's what the assistant uses to decide *whether this skill applies right now*. Think of it as a label on a drawer: it has to be specific enough that the assistant opens the drawer at the right moment and leaves it shut otherwise.

Vague descriptions are the number-one reason a skill never fires. "Helps with writing" is useless - almost everything is writing. Name the actual job and the cues that signal it:

```text
Weak:   "Helps with documents."
Strong: "Format quarterly board reports: applies our section
         order, tone, and the standard financial summary table.
         Use whenever the user mentions a board report or
         quarterly update."
```

Notice the strong one names the task *and* tells the assistant when to use it. That second part - the trigger condition - is what turns a description into a switch.

### 2. The instructions - the actual know-how

This is the body, and you write it the way you'd brief a capable new hire who's never seen your way of doing things. Concrete beats abstract every time. Don't say "write professionally" - say what professional means to you, with examples of right and wrong.

A workable instruction body has steps, rules, and at least one example:

```text
# Quarterly Board Report

## Steps
1. Open with a 3-sentence executive summary.
2. Then sections, in this order: Financials, Product,
   Hiring, Risks.
3. End with a "Decisions Needed" list, each item one line.

## Rules
- Numbers in tables, not prose.
- No hedging language ("we hope", "should be fine").
- Flag anything you had to assume in a note at the top.

## Example
[paste a real past report here, lightly redacted]
```

That example at the bottom does more work than any rule above it. Showing the assistant one good output teaches it faster than a page of description. If you have a template file, include it in the folder and tell the instructions to match it.

### 3. What it triggers on

Triggering is mostly handled by the description, but you can sharpen it. List the words and situations that should fire the skill, and - equally useful - the ones that shouldn't. If your "board report" skill keeps activating for casual status updates, add a line: "This is for formal quarterly board reports only, not weekly team updates."

You're steering attention. A skill that fires too eagerly is as annoying as one that never fires; a couple of lines about scope fixes both.

## Test it like you mean it

Don't assume it works. Give the assistant a request that *should* trigger the skill and check that it does - and that the output actually follows your instructions. Then give it a near-miss that *shouldn't* trigger it and confirm it stays quiet. Those two checks catch the two failure modes (never fires / always fires) that account for most broken skills.

When something's off, the fix is almost always in the description (for triggering) or in adding a concrete example (for output quality). Tweak, re-run, repeat. A skill is never finished the first time, and that's fine - you're encoding judgment, and judgment gets sharper with a few rounds of use.

Start with one. Pick the task you re-explain most often, write the three pieces, and let the assistant carry that know-how for you from now on. That's the whole point: you teach it once, and it remembers.