create-cowork-plugin

Name: create-cowork-plugin
Author: anthropics

2.1kinstalls2.7kforks

How to install create-cowork-plugin?

anthropics/knowledge-work-plugins/create-cowork-plugin

$npx -y skills add anthropics/knowledge-work-plugins --skill create-cowork-plugin

Installs into the current project.

Summary

Guide users through creating a new plugin from scratch in a cowork session. Use when users want to create a plugin, build a plugin, make a new plugin, develop a plugin, scaffold a plugin, start a plugin from scratch, or design a plugin. This skill requires Cowork mode with access

Files · 1

View on GitHub

SKILL.md

1	# Create Cowork Plugin
2
3	Build a new plugin from scratch through guided conversation. Walk the user through discovery, planning, design, implementation, and packaging — delivering a ready-to-install `.plugin` file at the end.
4
5	## Overview
6
7	A plugin is a self-contained directory that extends Claude's capabilities with skills, agents, hooks, and MCP server integrations. This skill encodes the full plugin architecture and a five-phase workflow for creating one conversationally.
8
9	The process:
10
11	1. Discovery — understand what the user wants to build
12	2. Component Planning — determine which component types are needed
13	3. Design & Clarifying Questions — specify each component in detail
14	4. Implementation — create all plugin files
15	5. Review & Package — deliver the `.plugin` file
16
17	> Nontechnical output: Keep all user-facing conversation in plain language. Do not expose implementation details like file paths, directory structures, or schema fields unless the user asks. Frame everything in terms of what the plugin will do.
18
19	## Plugin Architecture
20
21	### Directory Structure
22
23	Every plugin follows this layout:
24
25	```
26	plugin-name/
27	├── .claude-plugin/
28	│ └── plugin.json # Required: plugin manifest
29	├── skills/ # Skills (subdirectories with SKILL.md)
30	│ └── skill-name/
31	│ ├── SKILL.md
32	│ └── references/
33	├── agents/ # Subagent definitions (.md files)
34	├── .mcp.json # MCP server definitions
35	└── README.md # Plugin documentation
36	```
37
38	> Legacy `commands/` format: Older plugins may include a `commands/` directory with single-file `.md` slash commands. This format still works, but new plugins should use `skills/*/SKILL.md` instead — the Cowork UI presents both as a single "Skills" concept, and the skills format supports progressive disclosure via `references/`.
39
40	Rules:
41
42	- `.claude-plugin/plugin.json` is always required
43	- Component directories (`skills/`, `agents/`) go at the plugin root, not inside `.claude-plugin/`
44	- Only create directories for components the plugin actually uses
45	- Use kebab-case for all directory and file names
46
47	### plugin.json Manifest
48
49	Located at `.claude-plugin/plugin.json`. Minimal required field is `name`.
50
51	```json
52	{
53	"name": "plugin-name",
54	"version": "0.1.0",
55	"description": "Brief explanation of plugin purpose",
56	"author": {
57	"name": "Author Name"
58	}
59	}
60	```
61
62	Name rules: kebab-case, lowercase with hyphens, no spaces or special characters.
63	Version: semver format (MAJOR.MINOR.PATCH). Start at `0.1.0`.
64
65	Optional fields: `homepage`, `repository`, `license`, `keywords`.
66
67	Custom component paths can be specified (supplements, does not replace, auto-discovery):
68
69	```json
70	{
71	"commands": "./custom-commands",
72	"agents": ["./agents", "./specialized-agents"],
73	"hooks": "./config/hooks.json",
74	"mcpServers": "./.mcp.json"
75	}
76	```
77
78	### Component Schemas
79
80	Detailed schemas for each component type are in `references/component-schemas.md`. Summary:
81
82	\| Component \| Location \| Format \|
83	\| ---------------------------------- \| ------------------- \| --------------------------- \|
84	\| Skills \| `skills/*/SKILL.md` \| Markdown + YAML frontmatter \|
85	\| MCP Servers \| `.mcp.json` \| JSON \|
86	\| Agents (uncommonly used in Cowork) \| `agents/*.md` \| Markdown + YAML frontmatter \|
87	\| Hooks (rarely used in Cowork) \| `hooks/hooks.json` \| JSON \|
88	\| Commands (legacy) \| `commands/*.md` \| Markdown + YAML frontmatter \|
89
90	This schema is shared with Claude Code's plugin system, but you're creating a plugin for Claude Cowork, a desktop app for doing knowledge work.
91	Cowork users will usually find skills the most useful. *Scaffold new plugins with `skills//SKILL.md` — do not create `commands/` unless the user explicitly needs the legacy single-file format.**
92
93	### Customizable plugins with `~~` placeholders
94
95	> Do not use or ask about this pattern by default. Only introduce `~~` placeholders if the user explicitly says they want people outside their organization to use the plugin.
96	> You can mention this is an option if it seems like the user wants to distribute the plugin externally, but do not proactively ask about this with AskUserQuestion.
97
98	When a plugin is intended to be shared with others outside their company, it might have par

People who liked this also viewed

6 picks

Type

create-cowork-plugin

2.1kinstalls2.7kforks

View on GitHub

How to install create-cowork-plugin?

anthropics/knowledge-work-plugins/create-cowork-plugin

$npx -y skills add anthropics/knowledge-work-plugins --skill create-cowork-plugin

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Create Cowork Plugin
2
3	Build a new plugin from scratch through guided conversation. Walk the user through discovery, planning, design, implementation, and packaging — delivering a ready-to-install `.plugin` file at the end.
4
5	## Overview
6
7	A plugin is a self-contained directory that extends Claude's capabilities with skills, agents, hooks, and MCP server integrations. This skill encodes the full plugin architecture and a five-phase workflow for creating one conversationally.
8
9	The process:
10
11	1. Discovery — understand what the user wants to build
12	2. Component Planning — determine which component types are needed
13	3. Design & Clarifying Questions — specify each component in detail
14	4. Implementation — create all plugin files
15	5. Review & Package — deliver the `.plugin` file
16
17	> Nontechnical output: Keep all user-facing conversation in plain language. Do not expose implementation details like file paths, directory structures, or schema fields unless the user asks. Frame everything in terms of what the plugin will do.
18
19	## Plugin Architecture
20
21	### Directory Structure
22
23	Every plugin follows this layout:
24
25	```
26	plugin-name/
27	├── .claude-plugin/
28	│ └── plugin.json # Required: plugin manifest
29	├── skills/ # Skills (subdirectories with SKILL.md)
30	│ └── skill-name/
31	│ ├── SKILL.md
32	│ └── references/
33	├── agents/ # Subagent definitions (.md files)
34	├── .mcp.json # MCP server definitions
35	└── README.md # Plugin documentation
36	```
37
38	> Legacy `commands/` format: Older plugins may include a `commands/` directory with single-file `.md` slash commands. This format still works, but new plugins should use `skills/*/SKILL.md` instead — the Cowork UI presents both as a single "Skills" concept, and the skills format supports progressive disclosure via `references/`.
39
40	Rules:
41
42	- `.claude-plugin/plugin.json` is always required
43	- Component directories (`skills/`, `agents/`) go at the plugin root, not inside `.claude-plugin/`
44	- Only create directories for components the plugin actually uses
45	- Use kebab-case for all directory and file names
46
47	### plugin.json Manifest
48
49	Located at `.claude-plugin/plugin.json`. Minimal required field is `name`.
50
51	```json
52	{
53	"name": "plugin-name",
54	"version": "0.1.0",
55	"description": "Brief explanation of plugin purpose",
56	"author": {
57	"name": "Author Name"
58	}
59	}
60	```
61
62	Name rules: kebab-case, lowercase with hyphens, no spaces or special characters.
63	Version: semver format (MAJOR.MINOR.PATCH). Start at `0.1.0`.
64
65	Optional fields: `homepage`, `repository`, `license`, `keywords`.
66
67	Custom component paths can be specified (supplements, does not replace, auto-discovery):
68
69	```json
70	{
71	"commands": "./custom-commands",
72	"agents": ["./agents", "./specialized-agents"],
73	"hooks": "./config/hooks.json",
74	"mcpServers": "./.mcp.json"
75	}
76	```
77
78	### Component Schemas
79
80	Detailed schemas for each component type are in `references/component-schemas.md`. Summary:
81
82	\| Component \| Location \| Format \|
83	\| ---------------------------------- \| ------------------- \| --------------------------- \|
84	\| Skills \| `skills/*/SKILL.md` \| Markdown + YAML frontmatter \|
85	\| MCP Servers \| `.mcp.json` \| JSON \|
86	\| Agents (uncommonly used in Cowork) \| `agents/*.md` \| Markdown + YAML frontmatter \|
87	\| Hooks (rarely used in Cowork) \| `hooks/hooks.json` \| JSON \|
88	\| Commands (legacy) \| `commands/*.md` \| Markdown + YAML frontmatter \|
89
90	This schema is shared with Claude Code's plugin system, but you're creating a plugin for Claude Cowork, a desktop app for doing knowledge work.
91	Cowork users will usually find skills the most useful. *Scaffold new plugins with `skills//SKILL.md` — do not create `commands/` unless the user explicitly needs the legacy single-file format.**
92
93	### Customizable plugins with `~~` placeholders
94
95	> Do not use or ask about this pattern by default. Only introduce `~~` placeholders if the user explicitly says they want people outside their organization to use the plugin.
96	> You can mention this is an option if it seems like the user wants to distribute the plugin externally, but do not proactively ask about this with AskUserQuestion.
97
98	When a plugin is intended to be shared with others outside their company, it might have par

People who liked this also viewed

6 picks

Type