Install cowork-plugin-management, the plugin that builds plugins

A plugin in the Claude Code / Cowork sense is a bundle of skills, slash commands, agents, hooks, and MCP connectors you install as one unit. cowork-plugin-management, published in Anthropic's knowledge-work-plugins marketplace, is the plugin that builds and adapts other plugins. It occupies a deliberate meta-position: instead of giving Claude domain knowledge about sales or data, it gives Claude the scaffolding rules, file layout, and component schemas needed to author a plugin of your own from a conversation.

Why pick this as Thursday's plugin. The three plugins already on the menu — engineering, productivity, and data — are pre-built bundles you install and use. This one is the opposite end of the lifecycle: it is the tool for when no bundle fits your team and you would otherwise hand-write plugin.json, a skills/ tree, and an .mcp.json by hand. It encodes the conventions so your first plugin has the same structure as the official ones, which matters because a plugin that gets the directory layout or the SKILL.md frontmatter slightly wrong fails quietly at install time.

create-cowork-plugin. The first of its two skills runs a five-phase workflow: discovery (what problem, what scope), planning (which components), design (the schema for each), implementation (write the files), and review (package a [name].plugin you can install). You describe a workflow in plain English — "a plugin that drafts our on-call handoff notes from PagerDuty and posts them to Slack" — and it produces the scaffolding rather than a paragraph telling you how to. The output is files on disk, not advice.

cowork-plugin-customizer. The second skill adapts an existing plugin to your stack. Anthropic's bundles stay tool-agnostic through a placeholder convention: a skill refers to ~~Jira or ~~data warehouse rather than naming the product, and the customizer resolves those placeholders to what you actually run — ~~Jira becomes Asana, ~~data warehouse becomes Snowflake. It also does scoped edits ("change just the standup skill") and broader behavior changes, so you can pull down the engineering plugin and bend it to your team's terminology instead of starting from zero.

The schema it enforces is worth knowing even if you never run the plugin. A manifest lives at .claude-plugin/plugin.json; skills are skills/*/SKILL.md (Markdown plus YAML frontmatter carrying the trigger description); MCP servers are declared in .mcp.json; agents are agents/*.md; hooks are hooks/hooks.json for PreToolUse / PostToolUse / SessionStart events. It scaffolds skills with progressive disclosure — metadata always in context, the SKILL.md body loaded on trigger, heavy reference docs pulled from references/ only on demand — and it uses ${CLAUDE_PLUGIN_ROOT} for intra-plugin paths so the package stays portable.

The trap to avoid is scaffolding a plugin for something that should stay a single skill. A plugin earns its overhead when you have several related skills, a connector or two, and a workflow you repeat across a team; for a one-off transformation you would run once, a plain skill or a slash command is lighter and easier to maintain. Reach for this when the thing you are packaging is genuinely a bundle, not a single action dressed up as one. See the try-it block to install it and scaffold your first plugin.