🦞 4minAI.com
1 / 12
Day 12 of 14 Β· Claude Cowork Challenge

Building Custom Plugins

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.

Why Build Custom Plugins

The Case for Team-Specific Tooling

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.

Plugin Architecture

Understanding the Building Blocks

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.

πŸ€–
Claude Cowork
online
I want to build a custom plugin for our customer success team. We have a specific process for quarterly business reviews (QBRs) with clients. Can you help me think through what skills and commands this plugin would need?
Great use case! Here's how I'd structure a QBR plugin for your customer success team: **Plugin: Customer Success QBR** **Skills:** 1. `qbr-prep.md` β€” Gathers client data (usage metrics, support tickets, NPS scores, renewal date) and compiles a pre-meeting briefing 2. `qbr-deck-builder.md` β€” Creates a structured QBR presentation with sections for metrics review, achievements, recommendations, and next quarter goals 3. `health-score.md` β€” Calculates client health score using your team's specific methodology and flags at-risk accounts 4. `action-items.md` β€” After the QBR, generates a structured action item list with owners and deadlines **Slash Commands:** - `/cs:qbr-prep [client name]` β€” Runs the full prep workflow - `/cs:health-check [client name]` β€” Quick health score check - `/cs:post-qbr [client name]` β€” Post-meeting action item generation **Connectors:** - Your CRM (for account data and renewal dates) - Your analytics platform (for usage metrics) - Your support tool (for ticket history and NPS) Want me to use Plugin Create to generate the initial file structure? You can then customize the skill files with your team's specific QBR process and health scoring criteria.
↻ Replay conversation
Using Plugin Create

From Idea to Plugin in Minutes

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.

πŸ€–
Claude Cowork
online
Let's build that QBR plugin. Can you use Plugin Create to generate the initial structure?
I'll generate the plugin structure for you now. **Creating: customer-success-qbr plugin** Here's what I've generated: ``` customer-success-qbr/ plugin.json skills/ qbr-prep.md qbr-deck-builder.md health-score.md action-items.md commands/ qbr-prep.md health-check.md post-qbr.md connectors/ crm.json analytics.json support.json ``` Each skill file has initial instructions based on general QBR best practices. Here's what you should customize next: 1. **health-score.md** β€” Replace the generic scoring criteria with your team's specific health score methodology (what metrics you weight, what thresholds you use) 2. **qbr-deck-builder.md** β€” Add your standard QBR deck structure and any required sections specific to your company 3. **Connector configs** β€” Update the JSON files with your specific CRM, analytics, and support tool connection details The slash commands are already wired up to the corresponding skills. Once you customize the skill content, the commands will use your team's process. Want me to walk through customizing any of these files?
↻ Replay conversation
Best Practices

Building Plugins That Last

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.

Knowledge Check
What file formats are used to build custom Cowork plugins?
A
XML schemas and SQL queries
B
Markdown files and JSON files
C
Python scripts and YAML configurations
D
JavaScript modules and TypeScript definitions
Custom Cowork plugins are built entirely from Markdown and JSON files. Skills and slash commands are written in Markdown, while plugin metadata, connector configurations, and sub-agent definitions use JSON. No traditional coding is required.
Knowledge Check
What is the primary purpose of the Plugin Create plugin?
A
To automatically update existing plugins to newer versions
B
To generate the initial file structure for a new custom plugin based on your description
C
To test plugins for security vulnerabilities
D
To publish your plugins to the Anthropic plugin marketplace
Plugin Create generates the initial plugin structure β€” including the plugin.json metadata, skill files, slash command definitions, and connector configurations β€” based on your description of what the plugin should do. This gives you a solid starting point that you then customize with your team's specific knowledge.
Knowledge Check
When should you consider building a custom plugin?
A
When you have team-specific workflows you repeat frequently and want consistent results
B
Only when Anthropic approves your plugin request
C
Only when you have engineering resources to write code
D
Only when no official plugin exists for your industry
Custom plugins are worth building when you repeat the same workflow frequently, your team has specialized knowledge, you want consistent outputs across team members, or you need to combine multiple tools into an automated chain. Since plugins are file-based, no engineering resources or approval process is needed.
Knowledge Check
What is the most important thing to do after Plugin Create generates your plugin structure?
A
Submit it to Anthropic for review
B
Immediately share it with your entire team
C
Customize the skill files with your team's specific knowledge and processes
D
Install all available MCP connectors
Plugin Create generates a solid starting point based on general best practices, but the real value comes from customizing the skill files with your team's specific methodology, terminology, process steps, and quality criteria. This is what transforms a generic plugin into a tailored tool for your team.
πŸ› οΈ
Day 12 Complete
"Custom plugins turn your team's institutional knowledge into reusable, shareable tools β€” and building them requires nothing more than writing clear Markdown files."
Tomorrow β€” Day 13
Safety & Best Practices
Learn the safety considerations, data handling practices, and workflow tips that make your Cowork usage secure and effective.
πŸ”₯1
1 day streak!