Create Cowork Plugin
Author a Cowork plugin with correctly structured skills, frontmatter, and reference layouts following Anthropic component schemas.
Overview
Create Cowork Plugin is an agent skill most often used in Build (also Idea, Validate) that teaches how to implement Cowork plugin components with valid SKILL.md frontmatter and schema-compliant structure.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill create-cowork-pluginWhat is this skill?
- Documents required SKILL.md frontmatter fields: name, description, optional metadata map
- Specifies third-person descriptions with quoted trigger phrases for reliable skill routing
- Body style rules: imperative steps and SKILL.md bodies ideally 1,500–2,000 words with references/ for overflow
- Skill directory structure pattern with SKILL.md at skills/skill-name/SKILL.md
- References detailed component schemas for every plugin component type in Phase 4
- SKILL.md body guidance under 3,000 words with 1,500–2,000 word ideal
- Required frontmatter fields: name and description
Adoption & trust: 1.6k installs on skills.sh; 19.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want a Cowork plugin but your skills use inconsistent frontmatter, vague triggers, and oversized single files agents cannot maintain.
Who is it for?
Builders authoring their first or fifth Cowork plugin who need copy-paste-correct skill structure and schema alignment.
Skip if: Teams only consuming existing marketplace skills with no intent to author or extend plugin packages.
When should I use this skill?
User asks to design a Cowork plugin, implement plugin components in Phase 4, or needs api-design-style skill structure and REST guidance packaging.
What do I get? / Deliverables
You ship plugin skills with third-person trigger descriptions, imperative bodies, and reference splits that match the documented component schemas.
- Schema-compliant SKILL.md files
- Plugin skill directory layout with optional references/
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Plugin authoring is shelved under Build agent-tooling because it produces reusable agent capabilities rather than shipping end-user product features. Agent-tooling is the right subphase for SKILL.md format rules, plugin directory layout, and Phase-4 component implementation guidance.
Where it fits
Sketch which plugin skills you need before committing to a full component tree.
Decide whether one SKILL.md or a references/ split fits the planned API-design workflow.
Implement skills with required name and description fields matching directory names.
Move long schema tables out of SKILL.md into references/ per the under-3,000-word guidance.
How it compares
A meta authoring guide for plugin packages, not a runtime MCP server or a single-task integration skill.
Common Questions / FAQ
Who is create-cowork-plugin for?
Solo and indie developers packaging custom agent workflows as Cowork plugins with multiple skills and reference files.
When should I use create-cowork-plugin?
During Build when implementing Phase 4 plugin components, and in Validate when prototyping whether a workflow deserves its own skill package.
Is create-cowork-plugin safe to install?
Check the Security Audits panel on this page; the skill is documentation-heavy and does not inherently require network or shell by itself.
SKILL.md
READMESKILL.md - Create Cowork Plugin
# Component Schemas Detailed format specifications for every plugin component type. Reference this when implementing components in Phase 4. ## Skills **Location**: `skills/skill-name/SKILL.md` **Format**: Markdown with YAML frontmatter ### Frontmatter Fields | Field | Required | Type | Description | | ------------- | -------- | ------ | ------------------------------------------------------- | | `name` | Yes | String | Skill identifier (lowercase, hyphens; matches dir name) | | `description` | Yes | String | Third-person description with trigger phrases | | `metadata` | No | Map | Arbitrary key-value pairs (e.g., `version`, `author`) | ### Example Skill ```yaml --- name: api-design description: > This skill should be used when the user asks to "design an API", "create API endpoints", "review API structure", or needs guidance on REST API best practices, endpoint naming, or request/response design. metadata: version: "0.1.0" --- ``` ### Writing Style Rules - **Frontmatter description**: Third-person ("This skill should be used when..."), with specific trigger phrases in quotes. - **Body**: Imperative/infinitive form ("Parse the config file," not "You should parse the config file"). - **Length**: Keep SKILL.md body under 3,000 words (ideally 1,500-2,000). Move detailed content to `references/`. ### Skill Directory Structure ``` skill-name/ ├── SKILL.md # Core knowledge (required) ├── references/ # Detailed docs loaded on demand │ ├── patterns.md │ └── advanced.md ├── examples/ # Working code examples │ └── sample-config.json └── scripts/ # Utility scripts └── validate.sh ``` ### Progressive Disclosure Levels 1. **Metadata** (always in context): name + description (~100 words) 2. **SKILL.md body** (when skill triggers): core knowledge (<5k words) 3. **Bundled resources** (as needed): references, examples, scripts (unlimited) ## Agents **Location**: `agents/agent-name.md` **Format**: Markdown with YAML frontmatter ### Frontmatter Fields | Field | Required | Type | Description | | ------------- | -------- | ------ | --------------------------------------------------- | | `name` | Yes | String | Lowercase, hyphens, 3-50 chars | | `description` | Yes | String | Triggering conditions with `<example>` blocks | | `model` | Yes | String | `inherit`, `sonnet`, `opus`, or `haiku` | | `color` | Yes | String | `blue`, `cyan`, `green`, `yellow`, `magenta`, `red` | | `tools` | No | Array | Restrict to specific tools | ### Example Agent ```markdown --- name: code-reviewer description: Use this agent when the user asks for a thorough code review or wants detailed analysis of code quality, security, and best practices. <example> Context: User has just written a new module user: "Can you do a deep review of this code?" assistant: "I'll use the code-reviewer agent to provide a thorough analysis." <commentary> User explicitly requested a detailed review, which matches this agent's specialty. </commentary> </example> <example> Context: User is about to merge a PR user: "Review this before I merge" assistant: "Let me run a comprehensive review using the code-reviewer agent." <commentary> Pre-merge review benefits from the agent's structured analysis process. </commentary> </example> model: inherit color: blue tools: ["Read", "Grep", "Glob"] --- You are a code review specialist focused on identifying issues across security, performance, maintainability, and correctness. **Your Core Responsibilities:** 1. Analyze code structure and organization 2. Identify security vulnerabilities 3. Flag performance concerns 4. Check adherence to best practices **Analysis Process:** 1. Read all files in scope 2. Identify p