claude-cowork-marketplace-builder

Claude Cowork Marketplace Builder

Build a full Claude Cowork plugin from a plain-language request, then package it as an install-ready zip.

⚠️ Critical: How Cowork Reads Plugins

Claude Cowork installs one plugin per zip or GitHub repo. A plugin is a single flat folder with:

• .claude-plugin/plugin.json — minimal manifest (see exact format below)
• skills/ — one subfolder per skill, each containing SKILL.md
• commands/ — one .md file per command
• hooks/hooks.json — always present, always {}
• CONNECTORS.md — documents what connectors are needed
• README.md

There is no nested sub-plugin structure. Do not create multiple plugin folders inside a top-level folder. The app will not find skills or commands inside sub-directories — it will show "This plugin doesn't have any skills or agents."

For large multi-domain offices, use command prefixes to namespace by work lane within a single flat plugin. Example: exec-morning-brief.md, sales-account-plan.md, ops-weekly-review.md.

plugin.json — exact format (do not deviate)

{
  "name": "my-plugin-name",
  "version": "1.0.0",
  "description": "One sentence description.",
  "author": { "name": "Owner Name" }
}

Validation rules enforced by the app:

• name MUST be kebab-case: lowercase letters, numbers, and hyphens only — no spaces, no uppercase, no underscores. The app will reject the upload with: "Plugin name must be kebab-case"
• author MUST be an object { "name": "..." }, not a plain string
• Do NOT add type, slug, plugins array, or any other extra fields

Workflow

1. Interpret the user's idea as a set of work lanes (not separate plugins)
2. Design the lane structure: which lanes, what commands, what skills per lane
3. Write a compact JSON spec using the lanes model
4. Run scripts/build_marketplace_scaffold.py <spec.json> <output-dir>
5. Spot-check the output before sharing

Input handling

Start from a plain-language idea by default.

Examples:

• "build a claude cowork plugin for an AI consulting firm"
• "make me an office for recruiting and staffing"
• "create a plugin for legal intake, research, drafting, and review"

Use extra structure if provided: lane names, naming prefix, connectors, command tone, domain workflows. Ask only short follow-up questions when a missing detail would materially change the lane lineup.

Output contract

Always return one install-ready zip:

• .claude-plugin/plugin.json (minimal format, kebab-case name, author as object)
• skills/ — flat, one subfolder per skill, each with SKILL.md
• commands/ — flat, one .md file per command, prefixed by lane
• hooks/hooks.json containing {}
• CONNECTORS.md
• README.md
• optional .mcp.json using official connectors only

Office design rules

Work lanes (not sub-plugins)

Design lanes as logical domains within a single plugin. Each lane contributes prefixed commands and named skills to the shared flat structure.

Good lane prefixes:

• exec- — executive support, briefings, communications
• sales- — prospecting, pipeline, proposals, account management
• cs- — customer success, onboarding, support, renewals
• mkt- — marketing, content, campaigns, social
• ops- — operations, projects, data, process
• people- — recruiting, HR, onboarding, policies
• legal- — contracts, compliance, risk, security
• product- — roadmap, features, IT, releases

Avoid a separate skill for every micro-task. Email drafting, meeting summaries, and proposal writing belong as commands inside broader lane skills.

Command style

Commands are thin routers — they load a skill and pass the user's message. File: commands/lane-command-name.md

---
name: lane-command-name
description: What this command does in one sentence
---

Load the `skill-name` skill.

Treat the user's message after the slash command as the main instruction.

Examples:

• /my-office:exec-morning-brief run my morning brief
• /my-office:sales-account-plan help me prep for Acme
• /my-office:ops-weekly-review review my week and tell me what is slipping

name must exactly match the filename (without .md).

Skill style

Skills own the workflow logic. File: skills/skill-name/SKILL.md

Each skill should clearly state its deliverable, give concrete production instructions, and be practical — not abstract.

Connector policy

Use only official connectors from references/official-connectors.json. Document them in CONNECTORS.md. Optionally wire in .mcp.json.

Good defaults: notion (docs), slack + gmail (comms), google-calendar (scheduling), asana/linear (tasks). Never invent custom MCP URLs.

Build process

1. Design the spec

JSON spec fields:

• plugin_name — kebab-case
• plugin_description — one sentence
• owner_name
• lanes — array, each with prefix, commands, skills

See references/spec-checklist.md.

2. Run the scaffold script

python scripts/build_marketplace_scaffold.py <spec.json> <output-dir>

Generates: single flat plugin folder, correct plugin.json, all skills, all commands, hooks, CONNECTORS.md, README, zip.

3. Spot-check

• Single flat plugin folder in zip (no nested subfolders)
• plugin.json: kebab-case name, author as object, no extra fields
• hooks/hooks.json contains {}
• Every command: name frontmatter matches filename, has description
• Every skill: SKILL.md with name and description frontmatter

When to consult references

• Flat plugin structure: references/plugin-layouts.md
• Lane naming and patterns: references/plugin-role-patterns.md
• Official connectors: references/official-connectors.json
• Spec fields: references/spec-checklist.md
• Command style: references/command-examples.md

Final response

Return the zip. Summarize: lane lineup, command/skill counts, connectors included, assumptions made. If iteration needed, update spec, regenerate, return fresh zip.