⚡

协同插件定制器Skill cowork-plugin-customizer

协同插件定制器是一个用于自定义Claude Code插件的工具，帮助组织根据其特定工具和工作流程调整插件配置，包括设置、配置和调整插件设置。关键词：插件定制、Claude Code、工作流程自动化、工具集成、组织配置、插件配置、定制插件。

DevOps 0 次安装 0 次浏览 更新于 3/18/2026

name: cowork-plugin-customizer description: > 为特定组织的工具和工作流程自定义Claude Code插件。 使用时机：定制插件、设置插件、配置插件、调整插件、调整插件设置、 定制插件连接器、定制插件技能、定制插件命令、调整插件、修改插件配置。 compatibility: 需要Cowork桌面应用环境，并访问挂载的插件目录（mnt/.local-plugins, mnt/.plugins）。

协同插件定制

为特定组织定制插件——无论是首次设置通用插件模板，还是调整和优化已配置的插件。

查找插件：要找到插件的源文件，运行 find mnt/.local-plugins mnt/.plugins -type d -name "*<plugin-name>*" 来定位插件目录，然后在更改前读取其文件以理解结构。如果找不到插件目录，用户可能正在远程容器中运行此对话。中止并告知：“定制插件目前仅在桌面应用的Cowork模式下可用。”

确定定制模式

定位插件后，检查以 ~~ 前缀的占位符：grep -rn '~~\\w' /path/to/plugin --include='*.md' --include='*.json'

默认规则：如果存在 ~~ 占位符，默认进行 通用插件设置，除非用户明确要求定制插件的特定部分。

1. 通用插件设置——插件包含以 ~~ 前缀的占位符。这些是模板中的定制点，需要替换为实际值（例如，~~Jira → Asana，~~your-team-channel → #engineering）。

2. 范围定制——不存在 ~~ 占位符，且用户要求定制插件的特定部分（例如，“定制连接器”、“更新站会命令”、“更改票务工具”）。读取插件文件以找到相关部分，并仅关注这些。不要扫描整个插件或展示无关的定制项目。

3. 通用定制——不存在 ~~ 占位符，且用户希望广泛修改插件。读取插件的文件以理解当前配置，然后询问用户希望更改什么。

重要：切勿更改正在定制的插件或技能的名称。不要重命名目录、文件或插件/技能名称字段。

非技术输出：所有面向用户的输出（待办事项列表项、问题、摘要）必须用平实、非技术的语言编写。永远不要向用户提及 ~~ 前缀、占位符或定制点。以插件功能和组织的工具来框架所有内容。

定制工作流程

阶段0：收集用户意图（仅范围定制和通用定制）

对于 范围定制 和 通用定制（非通用插件设置），检查用户是否在请求旁提供了自由形式的上下文（例如，“定制站会命令——我们在 #eng-updates 频道每天上午进行异步站会”）。

  • 如果用户提供了上下文：记录它，并在阶段3中使用它预填答案——跳过在此已回答的问题。

  • 如果用户没有提供上下文：在进行前使用AskUserQuestion提出一个开放式问题。针对他们要求定制的内容调整问题——例如，“您对简要命令有什么更改想法？”或“您希望如何更改这个插件的工作方式？”保持简短和具体。

    使用他们的回应（如果有）作为额外上下文贯穿剩余阶段。

阶段1：从知识MCPs收集上下文

使用公司内部知识MCPs收集与定制范围相关的信息。详见 references/search-strategies.md 按类别查询模式。

收集内容（限于相关范围）：

  • 组织使用的工具名称和服务
  • 组织流程和工作流程
  • 团队约定（命名、状态、估算规模）
  • 配置值（工作区ID、项目名称、团队标识符）

搜索来源：

  1. 聊天/Slack MCPs——工具提及、集成、工作流程讨论
  2. 文档 MCPs——入门文档、工具指南、设置说明
  3. 电子邮件 MCPs——许可证通知、管理邮件、设置邀请

记录所有发现以供阶段3使用。

阶段2：创建待办事项列表

构建待更改项目的待办事项列表，适当限定范围：

  • 对于范围定制：仅包括与用户要求的特定部分相关的项目。
  • 对于通用插件设置：运行 grep -rn '~~\\w' /path/to/plugin --include='*.md' --include='*.json' 以找到所有占位符定制点。按主题分组。
  • 对于通用定制：读取插件文件，理解当前配置，并根据用户的请求，识别需要更改的内容。

使用用户友好的描述，专注于插件的目的：

  • 好：“了解公司在站会准备方面的工作方式”
  • 差：“替换 commands/standup-prep.md 中的占位符”

阶段3：完成待办事项

使用阶段0和阶段1的上下文处理每个项目。

如果用户的自由形式输入（阶段0）或知识MCPs（阶段1）提供了明确答案：直接应用，无需确认。

否则：使用AskUserQuestion。不要假设“行业标准”默认值是正确的——如果用户的输入或知识MCPs都没有提供具体答案，请询问。注意：AskUserQuestion总是包括跳过按钮和自定义答案的自由文本输入框，所以不要包含 None 或 Other 作为选项。

更改类型：

  1. 占位符替换（通用设置）：~~Jira → Asana，~~your-org-channel → #engineering
  2. 内容更新：修改说明、命令、工作流程或引用以匹配组织
  3. URL模式更新：tickets.example.com/your-team/123 → app.asana.com/0/PROJECT_ID/TASK_ID
  4. 配置值：工作区ID、项目名称、团队标识符

如果用户不知道或跳过，保持值不变（或对于通用设置，保持 ~~ 前缀的占位符）。

阶段4：搜索有用的MCPs

定制项目解决后，为任何识别或更改的工具连接MCPs。详见 references/mcp-servers.md 完整工作流程、类别到关键词映射和配置文件格式。

对于定制期间识别的每个工具：

  1. 搜索注册表：使用来自 references/mcp-servers.md 的类别关键词的 search_mcp_registry(keywords=[...])，或如果已知特定工具名称，则搜索
  2. 如果未连接：suggest_connectors(directoryUuids=["chosen-uuid"]) — 用户完成认证
  3. 更新插件的MCP配置文件（检查 plugin.json 是否有自定义位置，否则在根目录的 .mcp.json）

收集所有MCP结果，并在摘要输出中一起展示（见下文）——不要在此阶段逐个展示MCPs。

打包插件

所有定制应用后，将插件打包为 .plugin 文件供用户使用：

  1. 压缩插件目录（排除 setup/，因为它不再需要）：
    cd /path/to/plugin && zip -r /tmp/plugin-name.plugin . -x "setup/*" && cp /tmp/plugin-name.plugin /path/to/outputs/plugin-name.plugin
  2. 向用户展示文件，使用 .plugin 扩展名，以便他们可以直接安装。（展示 .plugin 文件将以富预览形式显示给用户，他们可以查看插件文件，并通过按按钮接受定制。）

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

命名：使用原始插件目录名作为 .plugin 文件（例如，如果插件目录是 coder，输出文件应为 coder.plugin）。在定制过程中不要重命名插件或其文件——仅替换占位符值和更新内容。

摘要输出

定制后，向用户展示按来源分组的所学内容摘要。总是包括MCPs部分，显示设置期间连接的MCPs和用户仍应连接的MCPs：

## 从搜索Slack
- 您使用Asana进行项目管理
- 冲刺周期为2周

## 从搜索文档
- 故事点使用T恤尺寸

## 从您的答案
- 票务状态为：积压、进行中、审核中、完成

然后展示设置期间连接的MCPs和任何用户仍应连接的MCPs，并附上连接说明。

如果阶段1中没有可用的知识MCPs，并且用户不得不手动回答至少一个问题，请在末尾添加备注：

顺便提一下，连接像Slack或Microsoft Teams这样的源将让我在下次您定制插件时自动找到答案。

附加资源

  • references/mcp-servers.md — MCP发现工作流程、类别到关键词映射、配置文件位置
  • references/search-strategies.md — 用于查找工具名称和组织值的知识MCP查询模式
  • examples/customized-mcp.json — 示例完全配置的 .mcp.json