⚡

创建协作插件技能Skill create-cowork-plugin

该技能提供逐步指导，帮助用户在Claude协作环境中通过对话创建自定义插件，覆盖从需求发现到打包交付的全过程。关键词：插件开发、低代码、协作工具、Claude插件、技能创建、工作流指导。

低代码开发 0 次安装 0 次浏览 更新于 3/18/2026

名称：创建协作插件 描述：> 引导用户通过对话在协作会话中从零开始创建新的插件。当用户想要创建插件、构建插件、制作新插件、开发插件、搭建插件框架、从零开始启动插件或设计插件时使用此技能。此技能需要协作模式，并访问输出目录以交付最终的.plugin文件。兼容性：需要协作桌面应用环境，并访问输出目录以交付.plugin文件。

创建协作插件

通过引导式对话从头构建新插件。引导用户完成发现、规划、设计、实现和打包过程——最终交付一个可安装的.plugin文件。

概述

插件是一个独立的目录，通过命令、技能、代理、钩子和MCP服务器集成扩展Claude的能力。此技能编码了完整的插件架构和用于对话式创建插件的五阶段工作流。

过程：

  1. 发现 — 了解用户想要构建什么
  2. 组件规划 — 确定需要哪些组件类型
  3. 设计与澄清问题 — 详细指定每个组件
  4. 实现 — 创建所有插件文件
  5. 审查与打包 — 交付.plugin文件

非技术输出：保持所有面向用户的对话使用通俗语言。除非用户询问，否则不要暴露实现细节，如文件路径、目录结构或架构字段。一切以插件将做什么为框架。

插件架构

目录结构

每个插件遵循此布局：

插件名称/
├── .claude-plugin/
│   └── plugin.json           # 必需：插件清单
├── commands/                 # 斜杠命令（.md文件）
├── agents/                   # 子代理定义（.md文件）
├── skills/                   # 技能（带SKILL.md的子目录）
│   └── 技能名称/
│       ├── SKILL.md
│       └── references/
├── .mcp.json                 # MCP服务器定义
└── README.md                 # 插件文档

规则：

  • .claude-plugin/plugin.json 始终必需
  • 组件目录（commands/、agents/、skills/）位于插件根目录，不在.claude-plugin/内
  • 仅为插件实际使用的组件创建目录
  • 对所有目录和文件名使用短横线命名法（kebab-case）

plugin.json 清单

位于.claude-plugin/plugin.json。最小必需字段是name。

{
  "name": "plugin-name",
  "version": "0.1.0",
  "description": "插件目的的简要说明",
  "author": {
    "name": "作者名称"
  }
}

名称规则：短横线命名法，小写带连字符，无空格或特殊字符。 版本：语义版本格式（主版本.次版本.修订版本）。从0.1.0开始。

可选字段：homepage、repository、license、keywords。

可指定自定义组件路径（补充，不替换自动发现）：

{
  "commands": "./custom-commands",
  "agents": ["./agents", "./specialized-agents"],
  "hooks": "./config/hooks.json",
  "mcpServers": "./.mcp.json"
}

组件架构

每种组件类型的详细架构在references/component-schemas.md中。摘要：

组件 位置 格式
命令 commands/*.md Markdown + YAML 前导部分
技能 skills/*/SKILL.md Markdown + YAML 前导部分
MCP 服务器 .mcp.json JSON
代理（在协作中不常用） agents/*.md Markdown + YAML 前导部分
钩子（在协作中很少使用） hooks/hooks.json JSON

此架构与Claude Code的插件系统共享，但您正在为Claude协作（一个用于知识工作的桌面应用）创建插件。协作用户通常发现命令和技能最有用。

使用~~占位符的可定制插件

默认情况下不要使用或询问此模式。 仅当用户明确表示希望组织外部人员使用插件时引入~~占位符。如果用户似乎想要在外部分发插件，可以提及此选项，但不要主动通过AskUserQuestion询问。

当插件打算与公司外部的其他人共享时，可能有一些部分需要适应个体用户。您可能需要通过类别而非特定产品引用外部工具（例如，“项目跟踪器”而非“Jira”）。当需要共享时，使用通用语言，并用两个波浪字符标记这些需要自定义的部分，如在~~项目跟踪器中创建问题。如果使用任何工具类别，在插件根目录编写CONNECTORS.md文件以解释：

# 连接器

## 工具引用如何工作

插件文件使用~~类别作为用户在该类别中连接的任意工具的占位符。插件是工具无关的——它们根据类别而非特定产品描述工作流。

## 此插件的连接器

| 类别 | 占位符 | 选项 |
|----------|-------------|-----------------|---------------|
| 聊天 | ~~聊天 | Slack、Microsoft Teams、Discord |
| 项目跟踪器 | ~~项目跟踪器 | Linear、Asana、Jira |

${CLAUDE_PLUGIN_ROOT} 变量

在钩子和MCP配置中的所有插件内路径引用中使用${CLAUDE_PLUGIN_ROOT}。切勿硬编码绝对路径。

引导式工作流

当您询问用户某事时，使用AskUserQuestion。不要假设“行业标准”默认值是正确的。注意：AskUserQuestion始终包括跳过按钮和用于自定义答案的自由文本输入框，因此不要包括None或Other作为选项。

阶段1：发现

目标：理解用户想要构建什么以及为什么。

询问（仅限不清楚的部分——如果用户的初始请求已回答，则跳过问题）：

  • 此插件应该做什么？它解决什么问题？
  • 谁将使用它，在什么背景下？
  • 它是否集成任何外部工具或服务？
  • 是否有类似的插件或工作流可参考？

在继续之前总结理解并确认。

输出：插件目的和范围的清晰陈述。

阶段2：组件规划

目标：确定插件需要的组件类型。

基于发现答案，确定：

  • 技能 — 是否需要Claude按需加载的专门知识？（领域专业知识、参考架构、工作流指南）
  • 命令 — 是否有用户发起的操作？（部署、配置、分析、审查）
  • MCP 服务器 — 是否需要外部服务集成？（数据库、API、SaaS工具）
  • 代理（不常见） — 是否有自主多步任务？（验证、生成、分析）
  • 钩子（罕见） — 某些事件是否应自动发生？（强制执行策略、加载上下文、验证操作）

呈现组件计划表，包括您决定不创建的组件类型：

| 组件 | 数量 | 目的 |
|-----------|-------|---------|
| 技能    | 1     | X的领域知识 |
| 命令  | 2     | /做某事、/检查某事 |
| 代理    | 0     | 不需要 |
| 钩子     | 1     | 验证写入 |
| MCP       | 1     | 连接到服务Y |

在继续之前获取用户确认或调整。

输出：确认的组件创建列表。

阶段3：设计与澄清问题

目标：详细指定每个组件。在实现之前解决所有模糊性。

对于计划中的每种组件类型，询问针对性的设计问题。按组件类型分组呈现问题。等待答案后再继续。

技能：

  • 哪些用户查询应触发此技能？
  • 它覆盖哪些知识领域？
  • 是否应包括详细内容的参考文件？

命令：

  • 每个命令接受哪些参数？
  • 每个命令需要哪些工具？（读取、写入、Bash、Grep等）
  • 每个命令是交互式还是自动化的？

代理：

  • 每个代理应主动触发还是仅在请求时触发？
  • 它需要哪些工具？
  • 输出格式应该是什么？

钩子：

  • 哪些事件？（PreToolUse、PostToolUse、Stop、SessionStart等）
  • 什么行为——验证、阻止、修改、添加上下文？
  • 基于提示（LLM驱动）还是基于命令（确定性脚本）？

MCP 服务器：

  • 什么服务器类型？（stdio用于本地，SSE用于带OAuth的托管，HTTP用于REST API）
  • 什么认证方法？
  • 应暴露哪些工具？

如果用户说“你认为最好的”，提供具体建议并获取明确确认。

输出：每个组件的详细规范。

阶段4：实现

目标：遵循最佳实践创建所有插件文件。

操作顺序：

  1. 创建插件目录结构
  2. 创建plugin.json清单
  3. 创建每个组件（参见references/component-schemas.md获取确切格式）
  4. 创建README.md文档化插件

实现指南：

  • 命令 是对Claude的指令，不是给用户的消息。将它们写为关于要做什么的指令。
  • 技能 使用渐进式披露：精简的SKILL.md主体（低于3,000字），详细内容在references/中。前导部分描述必须是第三人称，带特定触发短语。
  • 代理 需要描述，带<example>块显示触发条件，以及markdown主体中的系统提示。
  • 钩子 配置在hooks/hooks.json中。对脚本路径使用${CLAUDE_PLUGIN_ROOT}。优先使用基于提示的钩子进行复杂逻辑。
  • MCP 配置 在插件根目录的.mcp.json中。对本地服务器路径使用${CLAUDE_PLUGIN_ROOT}。在README中记录所需环境变量。

阶段5：审查与打包

目标：交付完成的插件。

  1. 总结创建的内容——列出每个组件及其目的
  2. 询问用户是否需要进行任何调整
  3. 运行claude plugin validate <path-to-plugin-json>；修复任何错误和警告
  4. 打包为.plugin文件：
cd /path/to/plugin-dir && zip -r /tmp/plugin-name.plugin . -x "*.DS_Store" && cp /tmp/plugin-name.plugin /path/to/outputs/plugin-name.plugin

重要：始终先在/tmp/中创建zip，然后复制到输出文件夹。直接写入输出文件夹可能因权限失败。

命名：使用plugin.json中的插件名称作为.plugin文件（例如，如果名称是code-reviewer，输出code-reviewer.plugin）。

.plugin文件将作为丰富预览出现在聊天中，用户可以浏览文件并通过按按钮接受插件。

最佳实践

  • 从小开始：以最小可行组件集开始。一个精心制作技能的插件比五个半成品组件更有用。
  • 技能的渐进式披露：核心知识在SKILL.md中，详细参考材料在references/中，工作示例在examples/中。
  • 清晰触发短语：技能描述应包括用户会说的特定短语。代理描述应包括<example>块。
  • 命令面向Claude：将命令内容写为Claude遵循的指令，而不是用户阅读的文档。
  • 指令性写作风格：在技能中使用动词优先的指令（“解析配置文件”，而非“您应解析配置文件”）。
  • 可移植性：始终对插件内路径使用${CLAUDE_PLUGIN_ROOT}，切勿硬编码路径。
  • 安全性：对凭据使用环境变量，远程服务器使用HTTPS，最小权限工具访问。

附加资源

  • references/component-schemas.md — 每种组件类型的详细格式规范（命令、技能、代理、钩子、MCP、CONNECTORS.md）
  • references/example-plugins.md — 三个不同复杂度的完整示例插件结构