2. How Plugins/Skills Actually Work

🎥 Video lesson — video not yet migrated (source Skool video id: 0041276fcaea47e0a42a3dc7cf12a085).

You've installed a plugin. You've seen the files. But what actually happens when you open Claude and type a message?

This walks through the full activation sequence — from the moment Claude loads through to a skill executing with the right context. We use the sales plugin's call prep skill as a live example, and you'll see exactly which files load, when, and why.

If it doesn't fully click on first watch, that's fine — CW-3 is where you build the plugin from scratch and this will make more sense in practice. But understanding this before you build means you won't be guessing why things work the way they do.

🎯 What you'll learn

The 5-step activation sequence — what Claude does from startup through to skill execution, one step at a time

Why only frontmatter loads at startup — and why the body of a skill only loads when it's actually triggered

How the description field drives auto-invocation — it's not a label, it's logic Claude uses to decide whether to call a skill automatically

What a context window actually is, how tokens work, and why context management determines the quality of your outputs

Why tasks belong in separate conversations — and how the two-phase loading system makes that practical

⚙ The activation sequence

STARTUP → IDLE → MESSAGE SENT → SKILL TRIGGERED → BODY LOADED

At startup, Claude loads the plugin manifest and the frontmatter of every skill — just names and descriptions, nothing else. When you send a message, Claude scans those descriptions and decides whether to auto-invoke a skill. If it does, the full skill body loads. Only what you triggered. Nothing extra.

A 10-skill plugin doesn't dump 10 instruction sets into your conversation. It loads 10 small frontmatter blocks and waits. That's the design.

✅ What you'll leave with

A clear mental model of what's in Claude's context at each stage of a trigger

An understanding of why the description field is the most important field in any skill you build

Practical intuition for context management — why you start a new conversation for each task, and why loading irrelevant information reduces output quality

→ Next up: CW-3 — Build Your First Plugin. You've seen the engine. Now you build one from scratch.


Part 2 — Lesson Body

Why this lesson comes before the build

CW-3 is where you build your first plugin. But before you do that, you need to understand what actually happens when a skill runs — because once you see the activation sequence, every file placement decision in the build makes immediate sense.

If this doesn't fully click before you start building, come back and re-watch after CW-3. The two reinforce each other. But most people get it once they see it live.

We're using the sales plugin — specifically the call prep skill — as a real working example. You'll see it auto-invoke, watch the context load, and then trace back through why each step happened.


Lesson 1: What Claude knows at startup

The moment you open Claude, before you've typed anything, three things have already happened automatically:

  1. Claude has scanned for installed plugins and read their plugin.json manifests
  2. Claude has loaded the frontmatter of every SKILL.md in every plugin
  3. Claude is now idle, waiting for your first message

That frontmatter is small — just the plugin name, version, description, and skill list. For each skill, Claude has seen the name and description. Nothing else. The full instruction bodies haven't loaded yet.

So at this point Claude knows what skills are available, but it hasn't read any of the actual instructions. That's intentional.

What this means practically: If you start a conversation and say "I have a meeting with someone in 30 minutes, can you help me prepare?" — Claude will recognise that the call prep skill is relevant. Not because it's guessed, but because it read the skill's description at startup and can match it to your intent.


Lesson 2: Auto-invocation vs slash command

There are two ways a skill gets triggered: automatically, or via a direct slash command.

Auto-invocation is when Claude matches your message to a skill description and loads it without you asking. You just describe what you need, and if there's a skill for it, it runs.

Slash command is explicit. You type /sales:1-call-prep and Claude will 100% execute that skill — no ambiguity, no matching logic, it just runs.

The slash command is more reliable when you know exactly which skill you want. Auto-invocation is what makes the system feel seamless when you're just talking naturally.

Live demo in Cowork: We'll type a natural-language message — "I'm looking to prepare for a meeting I have with John Smith from McDonald's in 30 minutes, can you please help me prepare?" — and watch Claude auto-invoke the call prep skill. You'll see the context window update in real time as the skill loads.


Lesson 3: The activation sequence step by step

Here's the full sequence from opening Claude to a skill executing:

Step 1 — Startup: plugin manifests load Claude opens and finds all installed plugins. It reads every plugin.json — name, version, skill list. The plugins are registered.

Step 2 — Startup: skill frontmatter loads Claude reads the frontmatter block at the top of every SKILL.md across all plugins. Name and description. Nothing else. Context window is small and clean.

Step 3 — Idle Claude is waiting. Nothing else has loaded. A 10-skill plugin has contributed 10 small frontmatter blocks, not 10 full instruction sets.

Step 4 — Message sent (auto) or slash command typed (manual) You send a message. Claude scans the loaded descriptions and decides whether to auto-invoke a skill. Or you type a slash command directly, which forces the skill to run.

Step 5 — Skill body loads If a skill is triggered, Claude reads the full body of the matching SKILL.md. This is the full instruction set — what the skill does, what it needs, how it should respond. If the skill references additional files (a brand voice document, a template, a client file), those load too.

At this point, context contains: the plugin manifests, all skill frontmatter, and the body of the triggered skill. Nothing else.


Lesson 4: Why the description field is critical

Here's the detail most people miss when building their first plugin.

The description field in your skill's frontmatter is not a label for humans. It's logic Claude uses to decide whether to auto-invoke the skill.

If you write a vague description — "Helps with sales" — Claude won't reliably trigger it. It might trigger it when you don't want it to, or miss it when you do.

If you write a precise description — "Use this skill when the user wants to prepare for an upcoming sales meeting or discovery call" — Claude can make a reliable decision. It knows exactly when this applies and when it doesn't.

The rule: Write descriptions as trigger conditions. "Use this skill when the user wants to [specific intent]." The more specific and accurate the description, the more reliable the auto-invocation.

If Claude doesn't trigger a skill when it should, check the description first. That's almost always the fix.


Lesson 5: Context windows and why they determine output quality

When Claude loaded the skill body, it went into the context window. That's worth understanding clearly.

The context window is the working memory of a conversation. Everything Claude knows in this session — every instruction, every file it's read, everything you've typed — lives in the context window. When it fills up, Claude either has to compact (summarise older content to make room) or stop.

Different models have different limits. Opus sits at around 1 million tokens. Sonnet is typically 200,000. Tokens aren't exactly characters, but you can think of them that way — roughly 1 token per character as a rule of thumb.

Why this matters for plugins:

If you load irrelevant information into a conversation, you're wasting context window space on things Claude doesn't need. And the more irrelevant information is present, the worse the output quality — the model has to work through more noise to find the signal.

This is why the two-phase loading system matters. A 10-skill plugin doesn't load all 10 skill bodies upfront. It loads 10 small frontmatter blocks, and only the triggered skill's body loads when it's actually needed. The context window stays clean until the moment you need something specific.

The practical rule: Don't try to do everything in one conversation. If you're preparing for a sales call, start a conversation and trigger the relevant sales skills. When you want to write a LinkedIn post, start a new conversation and trigger the content skills. Each conversation should have a focused context window built around the specific task you're doing. Generic conversations with everything loaded produce worse results than focused ones with only what's relevant.


Lesson 6: Live trace — what just happened in the demo

After the demo runs, here's the exact sequence that occurred:

  1. Before anything: Claude loaded the sales plugin's plugin.json and the frontmatter of the call prep skill — just name and description
  2. Message sent: "I'm looking to prepare for a meeting in 30 minutes
"
  3. Description matched: Claude read the call prep skill description, recognised it as relevant, and decided to auto-invoke
  4. Body loaded: The full SKILL.md body for call prep loaded into the context window
  5. Execution: Claude ran with those instructions and surfaced follow-up questions to gather more detail about the meeting

You can see this in Cowork's context window panel — it updates visually as each file loads. This is one of the clearest ways to understand what's actually happening behind the messages.


What you now understand

You can trace a plugin trigger from startup to execution. You know what's in the context window at each step. You know why the description field is the most important field you'll write. And you understand why focused conversations — one task, relevant context only — produce better results than open-ended ones.

That's the engine.

CW-3 is where you stop watching and start building. Empty directory to working slash command. Everything in CW-1 and CW-2 was preparation for what happens next.