3. Building a Plugin in CoWork

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

This is the first build lesson. We're not reading about plugins anymore — we're making one.

The Map explained the concepts. Module 2 walked through how activation works. Module 3 is where you open Cowork, describe a plugin in plain English, and watch Claude build it for you — agent, skill, reference file and all.

We're building a content plugin. One skill: content ideation. Two modes inside that skill: brainstorm ideas for a topic, or scan what's trending in a niche. By the end you'll have a working plugin installed in Cowork, you'll have run it, and you'll understand exactly how the three layers — plugin, agent, skill — relate to each other.

🎯 What you'll build

A content ideation plugin, built entirely through natural language in Cowork. No manual file creation.

🗂️ The three layers

→ Plugin — the container. Drives the /content slash command. Everything lives inside it.

→ Agent — a grouping layer. Mostly visual. It tells Cowork which skills belong together. Agents become important when you have a lot of skills and need something to help orchestrate between them — for now, they're simple.

→ Skill (SKILL.md) — this is the actual work. The skill file is your standard operating procedure. It holds the instructions, the capability menu, and the logic for what happens when someone activates it. The skill can also reference extra files it reads at runtime — frameworks, guidelines, brand voice.

✅ What you'll leave with

A working /content skill running in Cowork — two modes, a reference file, web search, live results.

How to add a second skill to an existing plugin using Cowork's customizer.

Why plugins are intentionally read-only once installed, and how the local copy override model works — including how to share a plugin with a team and let them version it safely.


Part 2 — Lesson Body

The three layers

Before we build, here's the mental model you need.

Plugin is the container. The name you give it drives the slash command — name it content and you get /content. Everything else lives inside it.

Agent is a grouping layer. It's mostly visual — it tells Cowork "here are the skills I own" and acts as an organiser. In production content plugins we run, you'll see agents with copywriters, graphic designers, multiple workflows all grouped together. But the agent itself doesn't execute instructions. When you only have one or two skills, you'll barely notice the agent is there. It only becomes genuinely useful when you have many skills and need something to help navigate between them automatically.

Skill (SKILL.md) is where the actual work happens. Think of it as the standard operating procedure that the skill is replacing. It holds the instructions, the mode options the user sees on activation, and what Claude does in each case. A plugin can have multiple skills — each one is a focused set of capabilities.

References are extra files the skill reads at runtime. Your SKILL.md tells Claude when to pull them in — they don't load automatically. A framework file, brand voice doc, ideation process — anything the skill needs to reference without loading into every conversation.


Building in Cowork

Open Cowork and go to Customize → Create Plugin → Create with Claude.

This is natural language. You're not writing config files — you're describing what you want. Claude does the heavy lifting, but you need to describe it accurately enough that it builds the right thing.

Here's the prompt we use:

Build me a content plugin called "content". It's a content ideation assistant. When I activate it I want to choose between two modes — ideation mode and trend scanning mode. For ideation mode, give it a framework: define the niche, identify audience pain points, generate content angles for each pain point. That framework should live in its own reference file the skill reads when it runs. Keep it minimal — one agent, one skill, one reference file.

One thing worth adding to your prompt: mention that this is just one workflow you're starting with, and that you'll be adding more skills to this plugin over time. That helps Claude structure it in a way that's easy to extend — rather than building it as if this is all it will ever do.


What Cowork shows you while it builds

A few things to notice while Claude works:

Expand the thinking. As you get more familiar with Cowork, always expand the thinking blocks. You'll see Claude planning step by step, tracking its own progress through the build, showing which skills and plugins it's using. It's one of the best ways to build intuition for how the AI actually works — not just what it produces.

The context folder. While the build is running, you'll see a context folder that shows which skills and connectors Claude is using. In this case you'll see it using Cowork's own built-in "create cowork plugin" skill — Claude has a built-in skill specifically for building plugins in the correct folder structure. That structure gets updated as Anthropic makes changes to how plugins work.

The working folder. Once the build is done, you can open the working folder and see the actual files Claude created. This is your plugin, built and ready to save.


Saving the plugin

When you click Save Plugin, the plugin goes from your local working session into Cowork's hosted plugin store. It becomes available in your Plugins tab.

This is important: before you save, the plugin only exists in your current session. After saving, it's hosted — available across sessions, and shareable with a team.

Once saved, you'll see it appear in the Plugins tab with the agent and skills listed. Click through and you'll see the front matter for each — the name and description that Cowork uses to register each piece.


Running your first skill

Trigger the skill via slash command: type /content and select the content ideation skill.

You'll see it present two modes:

  • Ideation mode — give it a topic, get back content ideas
  • Trend scanning mode — scan what's trending in a niche

It'll ask for your niche, your audience, and what platforms you're creating for. Answer those and it runs.

Two things to watch as it goes:

It reads the reference file. You'll see in the thinking that it reads from the ideation framework reference file you built. That's the runtime file loading in action — the skill pulled it in because the instructions told it to, not because it was pre-loaded.

It uses web search. The skill will search the web to surface real signals — trending topics, actual data points — and in a typical run it'll hit 30 to 40 sources in a matter of seconds. The output isn't generic advice — it's grounded in what's actually happening in your space.


Skills need tweaking

What Cowork builds is a solid starting point, not a finished product.

The first thing you should do after running any new skill is start noting what to change. The skill has general guidance built in, but you want detailed guidelines: what it should never do, how it should format output, what level of specificity you expect. We call these constraints. Over time, the constraints are what make the difference between a skill that outputs something useful and one that outputs something you'd actually use.

Don't expect the first run to be perfect. Expect it to show you what to tune.


When agents matter

With one skill, you barely notice the agent exists. With three skills, it's still mainly a grouping label. The agent becomes genuinely useful when you have many skills — say ten or more — and you want Claude to decide autonomously which skill to use based on what you ask. That's when the agent acts as an orchestrator: knowing which SOP applies to which situation without you having to name it explicitly.

For where you are right now — one or two or three skills — the fastest and most reliable path is to call skills directly via slash command. You always get exactly what you asked for.


Adding a second skill

Once the plugin is saved, adding more skills is straightforward.

Go back to the plugin → Customize. Cowork puts you right into the customizer with your plugin context already loaded. Describe what you want to add in natural language:

I want to add another skill. When we do content ideation, I want to be able to feed that output into a new skill that writes a full script for long-form YouTube content based on the idea we generated.

Cowork will use the customizer skill to make the edits, build the new skill file, update the version number (you'll see it go from v0.1.0 to v0.2.0 automatically), and prompt you to save.

Click Save, and your plugin is updated. The new YouTube Script Writer skill appears alongside the original ideation skill, with its own reference file for the script framework.


The local/remote model

Plugins installed from the catalog or saved through Cowork are hosted — they live in the remote plugin store. That store is intentionally read-only. You can't directly edit those files.

This is by design. The idea is that you build a plugin, share it with your team, and they install it. If they could edit the files directly, you'd end up with fragmented versions across the team with no way to know what changed or go back.

The correct flow for editing is through Cowork's customizer. When you customize a hosted plugin, Cowork creates a local copy on your machine — a working version you can modify. You make your changes, save, and the updated version becomes the new hosted version. If something breaks, you can always revert to the previous hosted version and pull back a clean copy.

This is also how team sharing works: you build the plugin, they install it, they can customize their own local version if they want, but the shared hosted version stays intact unless you explicitly push an update.


What you now have

A working content ideation plugin — installed, tested, two skills (ideation + YouTube scripts), each with a reference file the skill reads at runtime.

More importantly, you've seen the complete workflow: describe → Cowork builds → save → run → tweak → add skills → version up. That's the loop you'll repeat for every plugin you build from here.

CW-4 is about writing better skills — tighter instructions, better constraints, skills that consistently produce output you'd actually use.