Over the past four days, you have explored the official plugin library β Productivity, Research, Enterprise Search, Sales, Marketing, Finance, and Legal. These plugins cover broad professional domains, but every team has unique workflows that no general-purpose plugin can anticipate.
Maybe your engineering team has a specific deployment checklist. Maybe your HR department has a particular onboarding flow. Maybe your customer success team has a health scoring methodology that is unique to your product. The official plugins will not cover these β but you can build plugins that do.
Today you learn how to build custom plugins from scratch. The good news: it is far simpler than you might expect. Plugins are just files β Markdown and JSON β organized in a specific structure. If you can write a document, you can build a plugin.
Before we get into the how, let us be clear about the why. Custom plugins are worth building when:
You repeat the same workflow frequently. If you find yourself giving Cowork the same instructions session after session β "Here is how we do quarterly reviews," "Remember, our deployment process has these seven steps" β that is a sign you need a plugin. Encode the workflow once, use it forever.
Your team has specialized knowledge. Every team develops institutional knowledge: naming conventions, evaluation criteria, process steps, quality standards. A custom plugin captures this knowledge in a format Cowork can use, making it accessible to every team member.
You want consistent outputs. When multiple people on your team use Cowork for the same task, you want consistent results. A custom plugin ensures everyone gets the same structured workflow, the same quality checks, and the same output format β not whatever each person happens to prompt for.
You want to combine multiple tools. If your workflow involves pulling data from one system, analyzing it in a specific way, and then pushing results to another system, a custom plugin with MCP connectors can automate that entire chain.
The return on investment is straightforward: spend an hour building a plugin, save five minutes every time you use it. If you use it twice a day, you break even in six days. After that, it is pure productivity gain β for you and everyone on your team who installs it.
A custom plugin is a directory containing specific files. Here is the architecture:
Skills (Markdown files) β These are the core of your plugin. Each skill file describes a capability: what it does, when to use it, and how to execute it. A skill file is written in plain Markdown with a specific structure:
- A description of what the skill does
- Instructions that tell Cowork how to perform the task step by step
- Context that provides domain knowledge Cowork needs
- Output format specifications for consistent results
For example, a deployment-checklist skill might describe your team's deployment process, list every step in order, specify what checks to run at each stage, and define the format for the deployment report.
Connectors (JSON configuration) β These define MCP integrations with external services. A connector file specifies the service to connect to, authentication details, and available operations. If your plugin needs to read from Jira, write to Slack, or query a database, you define those connections here.
Slash Commands (Markdown files) β These create shortcut triggers for specific workflows. A slash command file maps a command name (like `/deploy:checklist` or `/onboard:new-hire`) to the skill and context that should be activated when the command is used.
Sub-agent Definitions (JSON files) β These define specialized workers for complex tasks. A sub-agent might handle a specific part of a larger workflow in the background. For most custom plugins, you will not need sub-agents β they are an advanced feature for complex, multi-step processes.
The file structure looks something like this:
```
my-plugin/
plugin.json # Plugin metadata
skills/
skill-one.md # First skill
skill-two.md # Second skill
commands/
my-command.md # Slash command definition
connectors/
service.json # MCP connector config
```
Everything is human-readable. You can open any file in a text editor, understand what it does, and modify it.
The Plugin Create plugin is your shortcut to building custom plugins. Instead of creating every file manually, you describe what you want and Plugin Create generates the structure for you.
Here is the typical workflow:
Step 1: Describe your plugin. Tell Cowork what domain the plugin covers, what workflows it should support, and what external services it needs to connect to. Be as specific as you can about your team's actual process.
Step 2: Plugin Create generates the structure. Cowork creates the plugin directory with all the necessary files: the plugin.json metadata, skill files with initial content, slash command definitions, and connector configurations. This generated output is a solid starting point, not a finished product.
Step 3: Customize the skill files. Open the generated skill files and refine them with your team's specific knowledge. Add your terminology, your process steps, your quality criteria, your output format preferences. This is where the plugin goes from generic to tailored.
Step 4: Test and iterate. Use the plugin, see how it performs, and refine. Adjust instructions that produce unclear outputs. Add context that was missing. Tweak output formats. Plugin development is iterative β your first version will not be perfect, and that is fine.
Step 5: Share with your team. Once you are happy with the plugin, share it with teammates. Because plugins are just files, sharing is as simple as sharing a directory. Everyone installs the same plugin and gets the same capabilities.
As you build custom plugins, keep these principles in mind:
Be specific in your skill instructions. Vague instructions produce vague results. Instead of "analyze the client's health," write "calculate the health score by weighting these five metrics: usage frequency (30%), support ticket volume (20%), NPS score (20%), feature adoption (15%), and executive engagement (15%). Score each on a 1-10 scale."
Include examples in your skill files. Show Cowork what good output looks like. Include a sample of the format you want, a real example of a completed analysis, or a template with placeholder values. Examples are the most powerful way to guide behavior.
Version your plugins. Use the version field in plugin.json and keep notes about what changed between versions. When you share plugins with teammates, versioning prevents confusion about which version someone is running.
Start small and expand. Build a plugin with one or two skills, test it thoroughly, then add more. A plugin with two well-tuned skills is infinitely more useful than a plugin with ten untested skills.
Document your customizations. When you modify a generated skill file, add a comment explaining why. Three months from now, you will want to know why you chose specific thresholds or process steps.