Building Custom Cowork Plugins: From Idea to Installation

The official Cowork plugins are useful starting points, but every organization works differently. Your sales team has a specific qualification process. Your finance team has particular account structures. Your product team has naming conventions that no generic tool will understand.

Custom plugins solve this. And the barrier to building one is lower than you might expect — if you can write a document and edit a JSON file, you can build a plugin.

The Anatomy of a Plugin

A Cowork plugin is a folder with a specific structure. No compiled code, no dependencies, no build steps. Here's what it looks like:

my-plugin/
├── .claude-plugin/
│   └── plugin.json          # Plugin manifest (name, description, version)
├── skills/
│   └── SKILL.md             # Domain knowledge Claude uses automatically
├── commands/
│   └── my-command.md        # Slash commands users trigger explicitly
├── .mcp.json                # Tool connections (optional)
└── README.md                # Documentation

That's it. Four types of files, three of which are plain markdown.

The Manifest: plugin.json

This tells Cowork what your plugin is and how to load it:

{
  "name": "my-plugin",
  "version": "1.0.0",
  "description": "What this plugin does in one sentence",
  "skills": ["skills/SKILL.md"],
  "commands": ["commands/my-command.md"]
}

Skills: The Knowledge Layer

Skills are markdown files that encode domain expertise. Claude reads these automatically and applies the knowledge when it's relevant — you don't need to invoke them explicitly.

A skill file has a specific structure:

# Skill Name

## Description
What this skill covers and when Claude should use it.

## Instructions
Step-by-step guidance for how Claude should approach tasks in this domain.

## Context
Background knowledge, terminology, conventions, and constraints.

## Examples
Concrete examples of good outputs in this domain.

The quality of your skill files determines how useful your plugin is. Be specific. Include your actual terminology, your real processes, and concrete examples of what good looks like in your organization.

Good skill instruction: "When preparing a client proposal, always include: executive summary (3-5 sentences), problem statement referencing the client's specific pain points from discovery, our recommended approach using the three-phase framework, timeline with milestones, and investment section using value-based framing rather than cost itemization."

Weak skill instruction: "Help write good proposals."

Commands: Explicit Workflows

Commands are slash-invoked workflows — the user types /my-plugin:do-something and Claude executes a structured process. Each command is a markdown file:

# /my-plugin:weekly-report

## Description
Generate the weekly team status report from project tracker data.

## Instructions
1. Pull all tasks completed this week from the connected project tracker
2. Group by team member
3. Identify blockers and risks
4. Calculate velocity metrics
5. Format using the standard weekly report template

## Output Format
Markdown report with sections: Accomplishments, In Progress, Blockers, Metrics, Next Week Focus

Commands are useful for workflows that should run the same way every time — reports with a defined format, analyses with specific steps, processes with compliance requirements.

Connectors: Wiring Into Your Stack

The .mcp.json file defines which external tools your plugin connects to via the Model Context Protocol:

{
  "mcpServers": {
    "my-project-tracker": {
      "type": "url",
      "url": "https://mcp.example.com/project-tracker"
    },
    "my-crm": {
      "type": "url",
      "url": "https://mcp.example.com/crm"
    }
  }
}

Connectors are optional. Many useful plugins are skills-only — encoding domain knowledge without requiring any external integrations. Start with skills and add connectors when you have a clear need.

Building Your First Plugin: A Walkthrough

Let's build a practical example — a plugin for a consulting team that needs to produce client deliverables with consistent quality.

Step 1: Define the Scope

Start with the question: "What does my team do repeatedly that requires specific knowledge?"

For our consulting team:

• Write client proposals following a specific format
• Produce weekly status updates with defined sections
• Create executive summaries from detailed research
• Review documents against the firm's quality standards

Step 2: Create the Structure

consulting-team/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   ├── SKILL.md
│   └── quality-standards.md
├── commands/
│   ├── proposal-draft.md
│   └── weekly-status.md
└── README.md

Step 3: Write the Core Skill

The main SKILL.md file encodes your team's institutional knowledge:

# Consulting Team Standards

## Description
Quality standards and conventions for all client-facing deliverables
produced by the consulting team. Claude should reference these
standards whenever creating or reviewing documents for clients.

## Terminology
- "Engagement" — not "project" (we always use engagement)
- "Investment" — not "cost" or "price" (value-based framing)
- "Recommended approach" — not "solution" (consultative positioning)

## Document Standards
All client deliverables must:
- Use active voice throughout
- Lead with business impact, not methodology
- Include quantified outcomes where data exists
- Reference the client's stated objectives from discovery
- End with clear next steps and ownership

## Proposal Structure
1. Executive Summary (3-5 sentences, business impact focus)
2. Understanding (restate client's challenge in their language)
3. Recommended Approach (three-phase framework)
4. Expected Outcomes (quantified where possible)
5. Timeline and Milestones
6. Investment (value-framed, not itemized)
7. Next Steps

## Common Mistakes to Avoid
- Starting with methodology instead of business impact
- Using internal jargon the client hasn't used
- Providing cost breakdowns instead of value framing
- Missing the client's stated priorities from discovery notes

Step 4: Build Commands

The proposal command (commands/proposal-draft.md):

# /consulting-team:proposal

## Description
Draft a client proposal following team standards. Requires client
name and either discovery notes or a brief description of the engagement.

## Instructions
1. Review any uploaded discovery notes or client context
2. Identify the client's primary pain points and stated objectives
3. Draft the proposal following the structure in quality-standards
4. Use the client's own language where possible
5. Quantify expected outcomes based on comparable engagements
6. Frame investment using value-based positioning
7. Include specific next steps with dates

## Output
Markdown document following the standard proposal structure.
Ready for review and conversion to the firm's branded template.

Step 5: Write the Manifest

{
  "name": "consulting-team",
  "version": "1.0.0",
  "description": "Client deliverable standards and workflows for the consulting team",
  "skills": [
    "skills/SKILL.md",
    "skills/quality-standards.md"
  ],
  "commands": [
    "commands/proposal-draft.md",
    "commands/weekly-status.md"
  ]
}

Step 6: Install and Test

In Cowork, you can upload the plugin folder directly. In Claude Code:

claude plugin install ./consulting-team

Test by asking Cowork to draft a proposal — it should automatically pick up your terminology conventions, document structure, and quality standards from the skill files.

Practical Tips from Building Plugins

Start with skills, not commands. Skills give you the most leverage because they apply automatically across all interactions. Commands are useful but narrower — they only fire when explicitly invoked.

Be specific about what "good" looks like. Vague instructions produce vague outputs. Include concrete examples, real terminology, and actual standards. The more specific your skill files, the more useful the plugin.

Encode what you'd tell a smart new hire. Think of skill files as onboarding documents for an exceptionally capable but context-free team member. What would they need to know on day one to produce work that meets your standards?

Version and share through git. Plugin folders are just files — they work perfectly with version control. Put your team plugin in a private repository, track changes, and let everyone pull updates.

Iterate based on output quality. After testing, look at where Cowork's outputs miss the mark. Usually the fix is adding specificity to the skill file — a convention it didn't know, a preference it couldn't infer, a standard it wasn't told about.

Use the Plugin Management plugin. Cowork includes a built-in plugin for creating and customizing plugins. If you prefer a guided process over manual file editing, start there.

Distributing Plugins Across Your Organization

For teams and enterprises, plugins become an organizational asset. The distribution model works in tiers:

Team level. Share the plugin folder through your team's repository. Everyone installs the same version with the same standards.

Organization level. Create a private marketplace — a git repository with a marketplace.json manifest listing your approved plugins. Admins control what's available, and teams install from a curated catalog.

Customization at scale. Start with an official Anthropic plugin, customize it for your organization, and distribute the modified version. The Apache 2.0 license explicitly allows this.

The organizational question isn't "should we build plugins?" — it's "who curates what our AI agents know about how we work?" That's a governance question with real implications for consistency, quality, and institutional knowledge preservation.

What's Next

The plugin ecosystem is moving fast. The February 2026 enterprise expansion added connectors for Google Workspace, DocuSign, WordPress, and domain-specific plugins for finance, HR, design, and engineering. Partner-built plugins from Salesforce, S&P Global, and others are in development.

For organizations building custom plugins now, the advantage compounds. Every piece of institutional knowledge you encode into a plugin is knowledge that every team member's AI assistant can draw on from day one. That's not just a productivity gain — it's a fundamentally different approach to how organizational knowledge scales.

Frequently Asked Questions

Continue Reading

• Claude Cowork: AI That Works With Your Files, Not Just Your Chat — The complete guide to Cowork itself
• Claude Cowork Plugins: Connect Your AI to Everything — The full plugin ecosystem overview
• Custom MCP Servers: Building AI Agents That Understand Your Business Context — Going deeper with the protocol layer
• Your AI Can Access Everything. Who Decided That? — Why plugin governance matters