[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7189D3F8771KBHTRVAWKWJZ":3,"skill-same:01M7189D3F8771KBHTRVAWKWJZ":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M7189D3F8771KBHTRVAWKWJZ","create-cowork-plugin",null,"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 to the outputs directory for delivering the final .plugin file.","anthropics\u002Fknowledge-work-plugins","anthropics","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F76263028?v=4","01M697XGDPXJAVQ8391V2BCYTE","Anthropic","01M7188MPC48111TN566QNQE3X",35660,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fcowork-plugin-management\u002Fskills\u002Fcreate-cowork-plugin\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"create","cowork","plugin","create cowork plugin","scratch","session","environment","for","make","guide","start","directory","when","access","files","desktop app","new","design","mode","app","2026-11-10 10:12:30",false,"---\nname: create-cowork-plugin\ndescription: >\n  Guide users through creating a new plugin from scratch in a cowork session.\n  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.\n  This skill requires Cowork mode with access to the outputs directory for delivering the final .plugin file.\ncompatibility: Requires Cowork desktop app environment with access to the outputs directory for delivering .plugin files.\n---\n\n# Create Cowork Plugin\n\nBuild 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.\n\n## Overview\n\nA 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.\n\nThe process:\n\n1. **Discovery** — understand what the user wants to build\n2. **Component Planning** — determine which component types are needed\n3. **Design & Clarifying Questions** — specify each component in detail\n4. **Implementation** — create all plugin files\n5. **Review & Package** — deliver the `.plugin` file\n\n> **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.\n\n## Plugin Architecture\n\n### Directory Structure\n\nEvery plugin follows this layout:\n\n```\nplugin-name\u002F\n├── .claude-plugin\u002F\n│   └── plugin.json           # Required: plugin manifest\n├── skills\u002F                   # Skills (subdirectories with SKILL.md)\n│   └── skill-name\u002F\n│       ├── SKILL.md\n│       └── references\u002F\n├── agents\u002F                   # Subagent definitions (.md files)\n├── .mcp.json                 # MCP server definitions\n└── README.md                 # Plugin documentation\n```\n\n> **Legacy `commands\u002F` format**: Older plugins may include a `commands\u002F` directory with single-file `.md` slash commands. This format still works, but new plugins should use `skills\u002F*\u002FSKILL.md` instead — the Cowork UI presents both as a single \"Skills\" concept, and the skills format supports progressive disclosure via `references\u002F`.\n\n**Rules:**\n\n- `.claude-plugin\u002Fplugin.json` is always required\n- Component directories (`skills\u002F`, `agents\u002F`) go at the plugin root, not inside `.claude-plugin\u002F`\n- Only create directories for components the plugin actually uses\n- Use kebab-case for all directory and file names\n\n### plugin.json Manifest\n\nLocated at `.claude-plugin\u002Fplugin.json`. Minimal required field is `name`.\n\n```json\n{\n  \"name\": \"plugin-name\",\n  \"version\": \"0.1.0\",\n  \"description\": \"Brief explanation of plugin purpose\",\n  \"author\": {\n    \"name\": \"Author Name\"\n  }\n}\n```\n\n**Name rules:** kebab-case, lowercase with hyphens, no spaces or special characters.\n**Version:** semver format (MAJOR.MINOR.PATCH). Start at `0.1.0`.\n\nOptional fields: `homepage`, `repository`, `license`, `keywords`.\n\nCustom component paths can be specified (supplements, does not replace, auto-discovery):\n\n```json\n{\n  \"commands\": \".\u002Fcustom-commands\",\n  \"agents\": [\".\u002Fagents\", \".\u002Fspecialized-agents\"],\n  \"hooks\": \".\u002Fconfig\u002Fhooks.json\",\n  \"mcpServers\": \".\u002F.mcp.json\"\n}\n```\n\n### Component Schemas\n\nDetailed schemas for each component type are in `references\u002Fcomponent-schemas.md`. Summary:\n\n| Component                          | Location            | Format                      |\n| ---------------------------------- | ------------------- | --------------------------- |\n| Skills                             | `skills\u002F*\u002FSKILL.md` | Markdown + YAML frontmatter |\n| MCP Servers                        | `.mcp.json`         | JSON                        |\n| Agents (uncommonly used in Cowork) | `agents\u002F*.md`       | Markdown + YAML frontmatter |\n| Hooks (rarely used in Cowork)      | `hooks\u002Fhooks.json`  | JSON                        |\n| Commands (legacy)                  | `commands\u002F*.md`     | Markdown + YAML frontmatter |\n\nThis 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.\nCowork users will usually find skills the most useful. **Scaffold new plugins with `skills\u002F*\u002FSKILL.md` — do not create `commands\u002F` unless the user explicitly needs the legacy single-file format.**\n\n### Customizable plugins with `~~` placeholders\n\n> **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.\n> 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.\n\nWhen a plugin is intended to be shared with others outside their company, it might have parts that need to be adapted to individual users.\nYou might need to reference external tools by category rather than specific product (e.g., \"project tracker\" instead of \"Jira\").\nWhen sharing is needed, use generic language and mark these as requiring customization with two tilde characters such as `create an issue in ~~project tracker`.\nIf used any tool categories, write a `CONNECTORS.md` file at the plugin root to explain:\n\n```markdown\n# Connectors\n\n## How tool references work\n\nPlugin files use `~~category` as a placeholder for whatever tool the user\nconnects in that category. Plugins are tool-agnostic — they describe\nworkflows in terms of categories rather than specific products.\n\n## Connectors for this plugin\n\n| Category        | Placeholder         | Options                         |\n| --------------- | ------------------- | ------------------------------- |\n| Chat            | `~~chat`            | Slack, Microsoft Teams, Discord |\n| Project tracker | `~~project tracker` | Linear, Asana, Jira             |\n```\n\n### ${CLAUDE_PLUGIN_ROOT} Variable\n\nUse `${CLAUDE_PLUGIN_ROOT}` for all intra-plugin path references in hooks and MCP configs. Never hardcode absolute paths.\n\n## Guided Workflow\n\nWhen you ask the user something, use AskUserQuestion. Don't assume \"industry standard\" defaults are correct. Note: AskUserQuestion always includes a Skip button and a free-text input box for custom answers, so do not include `None` or `Other` as options.\n\n### Phase 1: Discovery\n\n**Goal**: Understand what the user wants to build and why.\n\nAsk (only what is unclear — skip questions if the user's initial request already answers them):\n\n- What should this plugin do? What problem does it solve?\n- Who will use it and in what context?\n- Does it integrate with any external tools or services?\n- Is there a similar plugin or workflow to reference?\n\nSummarize understanding and confirm before proceeding.\n\n**Output**: Clear statement of plugin purpose and scope.\n\n### Phase 2: Component Planning\n\n**Goal**: Determine which component types the plugin needs.\n\nBased on the discovery answers, determine:\n\n- **Skills** — Does it need specialized knowledge that Claude should load on-demand, or user-initiated actions? (domain expertise, reference schemas, workflow guides, deploy\u002Fconfigure\u002Fanalyze\u002Freview actions)\n- **MCP Servers** — Does it need external service integration? (databases, APIs, SaaS tools)\n- **Agents (uncommon)** — Are there autonomous multi-step tasks? (validation, generation, analysis)\n- **Hooks (rare)** — Should something happen automatically on certain events? (enforce policies, load context, validate operations)\n\nPresent a component plan table, including component types you decided not to create:\n\n```\n| Component | Count | Purpose |\n|-----------|-------|---------|\n| Skills    | 3     | Domain knowledge for X, \u002Fdo-thing, \u002Fcheck-thing |\n| Agents    | 0     | Not needed |\n| Hooks     | 1     | Validate writes |\n| MCP       | 1     | Connect to service Y |\n```\n\nGet user confirmation or adjustments before proceeding.\n\n**Output**: Confirmed list of components to create.\n\n### Phase 3: Design & Clarifying Questions\n\n**Goal**: Specify each component in detail. Resolve all ambiguities before implementation.\n\nFor each component type in the plan, ask targeted design questions. Present questions grouped by component type. Wait for answers before proceeding.\n\n**Skills:**\n\n- What user queries should trigger this skill?\n- What knowledge domains does it cover?\n- Should it include reference files for detailed content?\n- If the skill represents a user-initiated action: what arguments does it accept, and what tools does it need? (Read, Write, Bash, Grep, etc.)\n\n**Agents:**\n\n- Should each agent trigger proactively or only when requested?\n- What tools does it need?\n- What should the output format be?\n\n**Hooks:**\n\n- Which events? (PreToolUse, PostToolUse, Stop, SessionStart, etc.)\n- What behavior — validate, block, modify, add context?\n- Prompt-based (LLM-driven) or command-based (deterministic script)?\n\n**MCP Servers:**\n\n- What server type? (stdio for local, SSE for hosted with OAuth, HTTP for REST APIs)\n- What authentication method?\n- What tools should be exposed?\n\nIf the user says \"whatever you think is best,\" provide specific recommendations and get explicit confirmation.\n\n**Output**: Detailed specification for every component.\n\n### Phase 4: Implementation\n\n**Goal**: Create all plugin files following best practices.\n\n**Order of operations:**\n\n1. Create the plugin directory structure\n2. Create `plugin.json` manifest\n3. Create each component (see `references\u002Fcomponent-schemas.md` for exact formats)\n4. Create `README.md` documenting the plugin\n\n**Implementation guidelines:**\n\n- **Skills** use progressive disclosure: lean SKILL.md body (under 3,000 words), detailed content in `references\u002F`. Frontmatter description must be third-person with specific trigger phrases. Skill bodies are instructions FOR Claude, not messages to the user — write them as directives about what to do.\n- **Agents** need a description with `\u003Cexample>` blocks showing triggering conditions, plus a system prompt in the markdown body.\n- **Hooks** config goes in `hooks\u002Fhooks.json`. Use `${CLAUDE_PLUGIN_ROOT}` for script paths. Prefer prompt-based hooks for complex logic.\n- **MCP configs** go in `.mcp.json` at plugin root. Use `${CLAUDE_PLUGIN_ROOT}` for local server paths. Document required env vars in README.\n\n### Phase 5: Review & Package\n\n**Goal**: Deliver the finished plugin.\n\n1. Summarize what was created — list each component and its purpose\n2. Ask if the user wants any adjustments\n3. Run `claude plugin validate \u003Cpath-to-plugin-json>` to check the plugin structure. If this command is unavailable (e.g., when running inside Cowork), verify the structure manually:\n   - `.claude-plugin\u002Fplugin.json` exists and contains valid JSON with at least a `name` field\n   - The `name` field is kebab-case (lowercase letters, numbers, and hyphens only)\n   - Any component directories referenced by the plugin (`commands\u002F`, `skills\u002F`, `agents\u002F`, `hooks\u002F`) actually exist and contain files in the expected formats — `.md` for commands\u002Fskills\u002Fagents, `.json` for hooks\n   - Each skill subdirectory contains a `SKILL.md`\n   - Report what passed and what didn't, the same way the CLI validator would\n\n   Fix any errors before proceeding.\n4. Package as a `.plugin` file:\n\n```bash\ncd \u002Fpath\u002Fto\u002Fplugin-dir && zip -r \u002Ftmp\u002Fplugin-name.plugin . -x \"*.DS_Store\" && cp \u002Ftmp\u002Fplugin-name.plugin \u002Fpath\u002Fto\u002Foutputs\u002Fplugin-name.plugin\n```\n\n> **Important**: Always create the zip in `\u002Ftmp\u002F` first, then copy to the outputs folder. Writing directly to the outputs folder may fail due to permissions.\n\n> **Naming**: Use the plugin name from `plugin.json` for the `.plugin` file (e.g., if name is `code-reviewer`, output `code-reviewer.plugin`).\n\nThe `.plugin` file will appear in the chat as a rich preview where the user can browse the files and accept the plugin by pressing a button.\n\n## Best Practices\n\n- **Start small**: Begin with the minimum viable set of components. A plugin with one well-crafted skill is more useful than one with five half-baked components.\n- **Progressive disclosure for skills**: Core knowledge in SKILL.md, detailed reference material in `references\u002F`, working examples in `examples\u002F`.\n- **Clear trigger phrases**: Skill descriptions should include specific phrases users would say. Agent descriptions should include `\u003Cexample>` blocks.\n- **Skills are for Claude**: Write skill body content as instructions for Claude to follow, not documentation for the user to read.\n- **Imperative writing style**: Use verb-first instructions in skills (\"Parse the config file,\" not \"You should parse the config file\").\n- **Portability**: Always use `${CLAUDE_PLUGIN_ROOT}` for intra-plugin paths, never hardcoded paths.\n- **Security**: Use environment variables for credentials, HTTPS for remote servers, least-privilege tool access.\n\n## Additional Resources\n\n- **`references\u002Fcomponent-schemas.md`** — Detailed format specifications for every component type (skills, agents, hooks, MCP, legacy commands, CONNECTORS.md)\n- **`references\u002Fexample-plugins.md`** — Three complete example plugin structures at different complexity levels\n","# Create Cowork Plugin\n\nBuild 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.\n\n## Overview\n\nA 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.\n\nThe process:\n\n1. **Discovery** — understand what the user wants to build\n2. **Component Planning** — determine which component types are needed\n3. **Design & Clarifying Questions** — specify each component in detail\n4. **Implementation** — create all plugin files\n5. **Review & Package** — deliver the `.plugin` file\n\n> **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.\n\n## Plugin Architecture\n\n### Directory Structure\n\nEvery plugin follows this layout:\n\n```\nplugin-name\u002F\n├── .claude-plugin\u002F\n│   └── plugin.json           # Required: plugin manifest\n├── skills\u002F                   # Skills (subdirectories with SKILL.md)\n│   └── skill-name\u002F\n│       ├── SKILL.md\n│       └── references\u002F\n├── agents\u002F                   # Subagent definitions (.md files)\n├── .mcp.json                 # MCP server definitions\n└── README.md                 # Plugin documentation\n```\n\n> **Legacy `commands\u002F` format**: Older plugins may include a `commands\u002F` directory with single-file `.md` slash commands. This format still works, but new plugins should use `skills\u002F*\u002FSKILL.md` instead — the Cowork UI presents both as a single \"Skills\" concept, and the skills format supports progressive disclosure via `references\u002F`.\n\n**Rules:**\n\n- `.claude-plugin\u002Fplugin.json` is always required\n- Component directories (`skills\u002F`, `agents\u002F`) go at the plugin root, not inside `.claude-plugin\u002F`\n- Only create directories for components the plugin actually uses\n- Use kebab-case for all directory and file names\n\n### plugin.json Manifest\n\nLocated at `.claude-plugin\u002Fplugin.json`. Minimal required field is `name`.\n\n```json\n{\n  \"name\": \"plugin-name\",\n  \"version\": \"0.1.0\",\n  \"description\": \"Brief explanation of plugin purpose\",\n  \"author\": {\n    \"name\": \"Author Name\"\n  }\n}\n```\n\n**Name rules:** kebab-case, lowercase with hyphens, no spaces or special characters.\n**Version:** semver format (MAJOR.MINOR.PATCH). Start at `0.1.0`.\n\nOptional fields: `homepage`, `repository`, `license`, `keywords`.\n\nCustom component paths can be specified (supplements, does not replace, auto-discovery):\n\n```json\n{\n  \"commands\": \".\u002Fcustom-commands\",\n  \"agents\": [\".\u002Fagents\", \".\u002Fspecialized-agents\"],\n  \"hooks\": \".\u002Fconfig\u002Fhooks.json\",\n  \"mcpServers\": \".\u002F.mcp.json\"\n}\n```\n\n### Component Schemas\n\nDetailed schemas for each component type are in `references\u002Fcomponent-schemas.md`. Summary:\n\n| Component                          | Location            | Format                      |\n| ---------------------------------- | ------------------- | --------------------------- |\n| Skills                             | `skills\u002F*\u002FSKILL.md` | Markdown + YAML frontmatter |\n| MCP Servers                        | `.mcp.json`         | JSON                        |\n| Agents (uncommonly used in Cowork) | `agents\u002F*.md`       | Markdown + YAML frontmatter |\n| Hooks (rarely used in Cowork)      | `hooks\u002Fhooks.json`  | JSON                        |\n| Commands (legacy)                  | `commands\u002F*.md`     | Markdown + YAML frontmatter |\n\nThis 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.\nCowork users will usually find skills the most useful. **Scaffold new plugins with `skills\u002F*\u002FSKILL.md` — do not create `commands\u002F` unless the user explicitly needs the legacy single-file format.**\n\n### Customizable plugins with `~~` placeholders\n\n> **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.\n> 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.\n\nWhen a plugin is intended to be shared with others outside their company, it might have parts that need to be adapted to individual users.\nYou might need to reference external tools by category rather than specific product (e.g., \"project tracker\" instead of \"Jira\").\nWhen sharing is needed, use generic language and mark these as requiring customization with two tilde characters such as `create an issue in ~~project tracker`.\nIf used any tool categories, write a `CONNECTORS.md` file at the plugin root to explain:\n\n```markdown\n# Connectors\n\n## How tool references work\n\nPlugin files use `~~category` as a placeholder for whatever tool the user\nconnects in that category. Plugins are tool-agnostic — they describe\nworkflows in terms of categories rather than specific products.\n\n## Connectors for this plugin\n\n| Category        | Placeholder         | Options                         |\n| --------------- | ------------------- | ------------------------------- |\n| Chat            | `~~chat`            | Slack, Microsoft Teams, Discord |\n| Project tracker | `~~project tracker` | Linear, Asana, Jira             |\n```\n\n### ${CLAUDE_PLUGIN_ROOT} Variable\n\nUse `${CLAUDE_PLUGIN_ROOT}` for all intra-plugin path references in hooks and MCP configs. Never hardcode absolute paths.\n\n## Guided Workflow\n\nWhen you ask the user something, use AskUserQuestion. Don't assume \"industry standard\" defaults are correct. Note: AskUserQuestion always includes a Skip button and a free-text input box for custom answers, so do not include `None` or `Other` as options.\n\n### Phase 1: Discovery\n\n**Goal**: Understand what the user wants to build and why.\n\nAsk (only what is unclear — skip questions if the user's initial request already answers them):\n\n- What should this plugin do? What problem does it solve?\n- Who will use it and in what context?\n- Does it integrate with any external tools or services?\n- Is there a similar plugin or workflow to reference?\n\nSummarize understanding and confirm before proceeding.\n\n**Output**: Clear statement of plugin purpose and scope.\n\n### Phase 2: Component Planning\n\n**Goal**: Determine which component types the plugin needs.\n\nBased on the discovery answers, determine:\n\n- **Skills** — Does it need specialized knowledge that Claude should load on-demand, or user-initiated actions? (domain expertise, reference schemas, workflow guides, deploy\u002Fconfigure\u002Fanalyze\u002Freview actions)\n- **MCP Servers** — Does it need external service integration? (databases, APIs, SaaS tools)\n- **Agents (uncommon)** — Are there autonomous multi-step tasks? (validation, generation, analysis)\n- **Hooks (rare)** — Should something happen automatically on certain events? (enforce policies, load context, validate operations)\n\nPresent a component plan table, including component types you decided not to create:\n\n```\n| Component | Count | Purpose |\n|-----------|-------|---------|\n| Skills    | 3     | Domain knowledge for X, \u002Fdo-thing, \u002Fcheck-thing |\n| Agents    | 0     | Not needed |\n| Hooks     | 1     | Validate writes |\n| MCP       | 1     | Connect to service Y |\n```\n\nGet user confirmation or adjustments before proceeding.\n\n**Output**: Confirmed list of components to create.\n\n### Phase 3: Design & Clarifying Questions\n\n**Goal**: Specify each component in detail. Resolve all ambiguities before implementation.\n\nFor each component type in the plan, ask targeted design questions. Present questions grouped by component type. Wait for answers before proceeding.\n\n**Skills:**\n\n- What user queries should trigger this skill?\n- What knowledge domains does it cover?\n- Should it include reference files for detailed content?\n- If the skill represents a user-initiated action: what arguments does it accept, and what tools does it need? (Read, Write, Bash, Grep, etc.)\n\n**Agents:**\n\n- Should each agent trigger proactively or only when requested?\n- What tools does it need?\n- What should the output format be?\n\n**Hooks:**\n\n- Which events? (PreToolUse, PostToolUse, Stop, SessionStart, etc.)\n- What behavior — validate, block, modify, add context?\n- Prompt-based (LLM-driven) or command-based (deterministic script)?\n\n**MCP Servers:**\n\n- What server type? (stdio for local, SSE for hosted with OAuth, HTTP for REST APIs)\n- What authentication method?\n- What tools should be exposed?\n\nIf the user says \"whatever you think is best,\" provide specific recommendations and get explicit confirmation.\n\n**Output**: Detailed specification for every component.\n\n### Phase 4: Implementation\n\n**Goal**: Create all plugin files following best practices.\n\n**Order of operations:**\n\n1. Create the plugin directory structure\n2. Create `plugin.json` manifest\n3. Create each component (see `references\u002Fcomponent-schemas.md` for exact formats)\n4. Create `README.md` documenting the plugin\n\n**Implementation guidelines:**\n\n- **Skills** use progressive disclosure: lean SKILL.md body (under 3,000 words), detailed content in `references\u002F`. Frontmatter description must be third-person with specific trigger phrases. Skill bodies are instructions FOR Claude, not messages to the user — write them as directives about what to do.\n- **Agents** need a description with `\u003Cexample>` blocks showing triggering conditions, plus a system prompt in the markdown body.\n- **Hooks** config goes in `hooks\u002Fhooks.json`. Use `${CLAUDE_PLUGIN_ROOT}` for script paths. Prefer prompt-based hooks for complex logic.\n- **MCP configs** go in `.mcp.json` at plugin root. Use `${CLAUDE_PLUGIN_ROOT}` for local server paths. Document required env vars in README.\n\n### Phase 5: Review & Package\n\n**Goal**: Deliver the finished plugin.\n\n1. Summarize what was created — list each component and its purpose\n2. Ask if the user wants any adjustments\n3. Run `claude plugin validate \u003Cpath-to-plugin-json>` to check the plugin structure. If this command is unavailable (e.g., when running inside Cowork), verify the structure manually:\n   - `.claude-plugin\u002Fplugin.json` exists and contains valid JSON with at least a `name` field\n   - The `name` field is kebab-case (lowercase letters, numbers, and hyphens only)\n   - Any component directories referenced by the plugin (`commands\u002F`, `skills\u002F`, `agents\u002F`, `hooks\u002F`) actually exist and contain files in the expected formats — `.md` for commands\u002Fskills\u002Fagents, `.json` for hooks\n   - Each skill subdirectory contains a `SKILL.md`\n   - Report what passed and what didn't, the same way the CLI validator would\n\n   Fix any errors before proceeding.\n4. Package as a `.plugin` file:\n\n```bash\ncd \u002Fpath\u002Fto\u002Fplugin-dir && zip -r \u002Ftmp\u002Fplugin-name.plugin . -x \"*.DS_Store\" && cp \u002Ftmp\u002Fplugin-name.plugin \u002Fpath\u002Fto\u002Foutputs\u002Fplugin-name.plugin\n```\n\n> **Important**: Always create the zip in `\u002Ftmp\u002F` first, then copy to the outputs folder. Writing directly to the outputs folder may fail due to permissions.\n\n> **Naming**: Use the plugin name from `plugin.json` for the `.plugin` file (e.g., if name is `code-reviewer`, output `code-reviewer.plugin`).\n\nThe `.plugin` file will appear in the chat as a rich preview where the user can browse the files and accept the plugin by pressing a button.\n\n## Best Practices\n\n- **Start small**: Begin with the minimum viable set of components. A plugin with one well-crafted skill is more useful than one with five half-baked components.\n- **Progressive disclosure for skills**: Core knowledge in SKILL.md, detailed reference material in `references\u002F`, working examples in `examples\u002F`.\n- **Clear trigger phrases**: Skill descriptions should include specific phrases users would say. Agent descriptions should include `\u003Cexample>` blocks.\n- **Skills are for Claude**: Write skill body content as instructions for Claude to follow, not documentation for the user to read.\n- **Imperative writing style**: Use verb-first instructions in skills (\"Parse the config file,\" not \"You should parse the config file\").\n- **Portability**: Always use `${CLAUDE_PLUGIN_ROOT}` for intra-plugin paths, never hardcoded paths.\n- **Security**: Use environment variables for credentials, HTTPS for remote servers, least-privilege tool access.\n\n## Additional Resources\n\n- **`references\u002Fcomponent-schemas.md`** — Detailed format specifications for every component type (skills, agents, hooks, MCP, legacy commands, CONNECTORS.md)\n- **`references\u002Fexample-plugins.md`** — Three complete example plugin structures at different complexity levels\n",{"name":5,"description":49,"compatibility":50},"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 to the outputs directory for delivering the final .plugin file.\n","Requires Cowork desktop app environment with access to the outputs directory for delivering .plugin files.","main","e605d8ddbfb688da57dfaaceebd93f12a64ef1d3","cowork-plugin-management\u002Fskills\u002Fcreate-cowork-plugin",3944,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins","https:\u002F\u002Fgithub.com\u002Fanthropics","https:\u002F\u002Fanthropic.com","2026-11-14 06:21:52",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add anthropics\u002Fknowledge-work-plugins --skill create-cowork-plugin",{"tool":65,"command":66},"bunx","bunx skills add anthropics\u002Fknowledge-work-plugins --skill create-cowork-plugin",{"tool":68,"command":69},"pnpm","pnpm dlx skills add anthropics\u002Fknowledge-work-plugins --skill create-cowork-plugin","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fcowork-plugin-management\u002Fskills\u002Fcreate-cowork-plugin\u002FSKILL.md",true,[73,79],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fcomponent-schemas.md","REFERENCE","参考文档",11674,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fcowork-plugin-management\u002Fskills\u002Fcreate-cowork-plugin\u002Freferences\u002Fcomponent-schemas.md",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fexample-plugins.md",8272,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fcowork-plugin-management\u002Fskills\u002Fcreate-cowork-plugin\u002Freferences\u002Fexample-plugins.md",[84,109,134,156,184,210],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":44},"01M718Y97HCGW12Q53PSJDY03W","ticket-deflector","Reads a forwarded customer email or ticket, pulls order and refund status from a payments connector (PayPal, Square, or Stripe) or Shopify, account history from the CRM, and open tickets from a support desk (Zoho Desk), drafts a tone-matched reply in the owner's writing voice, and can issue a refund through the payments connector with explicit owner approval. With Shopify connected it also runs a proactive order-triage mode that surfaces orders needing attention — unfulfilled past the promised window, payment problems, pending refunds, stuck shipments — and drafts the next action for each before the customer has to ask. Use when the user says \"draft a response,\" \"answer this customer,\" \"where's my order,\" \"I want a refund,\" \"check my orders,\" or \"anything about to blow up.\"","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Fticket-deflector\u002FSKILL.md",[],[91,92,42,93,94,95,96,36,97,98,99,100,101,102,103,104,105,106,107,108],"ticket","ticket deflector","up","payments","open","writing","workflow","ask","Connector","text","mail","window","next","customer","support","crm","past","read",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":44},"01M718Y55HFAN5705ME5VEDZ9K","tax-season-organizer","Prepares tax-season materials for the owner's accountant, not tax advice. US federal tax; a non-US business gets its closed-books packet instead. Two modes: (1) quarterly estimated tax from YTD net income in the ledger (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books); (2) year-end 1099 prep, scanning the ledger, PayPal, and Stripe for contractors paid over USD 600 into a 1099-NEC list with missing W-9 flags.\nAny tax request routes first to \u002Ftax-prep, which confirms the books are closed and reconciled before running this skill. Use this skill directly only when the owner says the period's books are already closed: \"books are closed, now do the 1099s,\" \"run the quarterly estimate off the closed numbers,\" or \"just the contractor W-9 list.\"","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Ftax-season-organizer\u002FSKILL.md",[],[116,117,118,119,120,121,122,123,124,125,36,126,127,128,129,130,108,131,132,133],"tax season organizer","tax","us federal","which","netsuite","paid","end","usd","only","now","books","xero","scanning","run","request","flags","list","stripe",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":44},"01M718Y13VVPHDD9NTDBVFJ2AZ","tax-prep","Prepares tax materials as a two-link chain — month-end-prep confirms the books are closed and reconciled first, then tax-season-organizer calculates the quarterly estimated payment or builds the year-end 1099-NEC list and accountant packet from those closed numbers. Requires a ledger (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books); uses Gusto, PayPal, and Stripe when connected, else CSV upload. US federal tax math; a non-US business gets the closed-books packet. Prep material for a CPA, never tax advice, nothing filed. Trigger on \"quarterly taxes,\" \"estimated tax payment,\" \"how much should I set aside,\" \"1099s,\" \"1099-NEC,\" \"W-9s,\" \"year-end tax prep,\" \"get my books ready for my accountant,\" any phrasing that suggests a tax deadline is coming, or a question about net profit or YTD income that sounds like worry about a tax bill. An owner who says the period's books are already closed routes to tax-season-organizer directly.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Ftax-prep\u002FSKILL.md",[],[141,117,142,143,118,144,145,120,146,147,148,149,150,31,151,122,152,153,154,155],"tax prep","prep","SET","as","ready","never","zoho books","get","chain","profit","trigger","material","question","paypal","business",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":167,"publishedAt":44},"01M718XWTWQZ01GYSG9T8RW8TW","speed-to-lead","Makes sure no inbound lead goes unanswered. Watches web forms, the shared inbox, and the CRM for new inquiries, qualifies each one against the owner's criteria, drafts a reply in the owner's voice with real meeting times for the owner to approve and send, routes anything hot to a human right away, and logs the whole thing to the CRM. Never sends on its own. Built to run on a schedule so overnight inquiries are drafted and sorted by morning, and works from forwarded or pasted inquiries when no connector is available. Use this whenever the owner is worried about inbound leads or response time — including phrasings like \"leads are going cold,\" \"did anyone answer that inquiry,\" \"I keep missing form submissions,\" \"nothing falls through the cracks,\" \"handle my inbound,\" \"respond to this lead,\" or \"we lose people because nobody gets back fast enough.\" Reach for it for a single unanswered inquiry as readily as for a standing setup.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Fspeed-to-lead\u002FSKILL.md",[162],{"categoryNo":163,"categoryName":164,"taxonomyType":165,"taxonomyTypeDesc":166},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[168,169,170,171,172,173,146,174,175,176,177,40,178,179,36,180,181,99,182,183],"speed to lead","lead","speed","shared","back","cold","time","inbox","send","respond","web forms","people","schedule","logs","sure","human",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":193,"publishedAt":44},"01M718XQYMN1KY3TPS33967FK0","social-content-engine","Runs the owner's content operation as a standing thing rather than a one-off: keeps a rolling posting calendar, learns the owner's voice, generates on-brand Canva graphics, writes captions that sound like them, repurposes one asset into every channel format, and stages posts for approval instead of publishing on its own. Pulls product photos and prices from Shopify when connected; with no connectors, drafts the calendar and asset briefs for manual posting. Use this whenever the owner talks about posting, content, or social — including \"I need to post more,\" \"we've gone quiet on Instagram,\" \"what should we post this month,\" \"make the content,\" \"give me a month of posts,\" \"write this in my voice,\" \"repurpose this,\" or \"set up our content calendar.\" Reach for it for a single post as readily as for a full quarter. One handoff: a finished, approved campaign brief goes to canva-creator; this skill owns the standing operation.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Fsocial-content-engine\u002FSKILL.md",[190],{"categoryNo":191,"categoryName":192,"taxonomyType":165,"taxonomyTypeDesc":166},"01JBSEEDCAT000000000000036","内容创作者",[194,195,196,197,198,199,143,200,201,202,203,93,204,36,205,206,207,108,208,209],"social","social content engine","engine","content engine","social content","content","brief","posts","Captions","prices","campaign","me","product","calendar","write","drafts",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":216,"publishedAt":44},"01M718XMPJVH0EVRVP998BVZPC","smb-router","The front door to the Small Business plugin. Listens to what the owner needs right now — vague or specific — and routes them to the best skill or slash command for the moment. Also serves as a guide: explains what's available, suggests what to try next, and adapts recommendations based on stored business context. Trigger whenever the owner asks \"what can you do,\" \"help me with my business,\" \"what should I focus on,\" \"I don't know where to start,\" or any open-ended business request that doesn't clearly match a single skill.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Fsmb-router\u002FSKILL.md",[],[217,218,219,144,220,31,151,221,95,222,125,155,223,224,225,226,26,205,227,103],"router","smb","smb router","do","front","single","you","vague","can","with","focus"]