cowork-plugin-customizer

Cowork 插件自定义

为特定组织自定义插件：可以是首次设置通用插件模板，也可以是调整和优化已配置好的插件。

查找插件：要找到插件的源文件，请运行 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. 局部自定义：不存在 ~~ 占位符，且用户要求自定义插件的某个特定部分（例如"自定义连接器"、"更新站会技能"、"更改工单工具"）。请读取插件文件，找到相关部分，并且只关注这些部分。不要扫描整个插件，也不要展示无关的自定义项。

旧版 commands/ 目录：部分插件包含 commands/ 目录。Cowork 界面现在将这些内容与技能合并为单一的"技能"概念呈现，因此在自定义时，请将 commands/*.md 文件与 skills/*/SKILL.md 文件同等对待。

3. 通用自定义：不存在 ~~ 占位符，且用户希望对插件进行全面修改。请读取插件的文件，了解其当前配置，然后询问用户希望做出哪些更改。

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

面向非技术用户的输出：所有面向用户的输出（待办事项、问题、摘要）都必须使用通俗、非技术性的语言。切勿向用户提及 ~~ 前缀、占位符或自定义点。应从插件的功能以及组织所使用的工具的角度进行表述。

自定义工作流

阶段 0：收集用户意图（仅限局部自定义和通用自定义）

对于局部自定义和通用自定义（非通用插件设置），请检查用户在提出请求时是否同时提供了自由格式的背景信息（例如"自定义站会技能，我们每天早上在 #eng-updates 进行异步站会"）。

• 如果用户提供了背景信息：记录下来，并用于预先填写阶段 3 中的答案，跳过用户已在此处回答过的问题。

• 如果用户未提供背景信息：在继续之前，使用 AskUserQuestion 提出一个开放式问题。问题应针对用户要求自定义的内容量身定制，例如"你对 brief 技能有什么修改想法？"或"你希望更改这个插件的哪些运作方式？"保持简短，并与用户的请求具体相关。

  将用户的回答（如有）作为其余各阶段的补充背景信息。

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

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

需要收集的内容（仅限相关范围）：

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

需要搜索的来源：

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

将所有发现记录下来，供阶段 3 使用。

阶段 2：创建待办列表

构建需要进行的更改的待办列表，并确保范围适当：

• 针对限定范围的定制：仅包含与用户所询问的特定章节相关的项目。
• 针对通用插件设置：运行 grep -rn '~~\w' /path/to/plugin --include='*.md' --include='*.json'，找出所有占位符定制点，并按主题分组。
• 针对一般定制：阅读插件文件，了解当前配置，并根据用户的请求确定需要更改的内容。

使用侧重于插件用途的、用户友好的描述：

• 推荐："了解 Company 的站会准备流程"
• 不推荐："替换 skills/standup-prep/SKILL.md 中的占位符"

阶段 3：完成待办项

结合阶段 0 和阶段 1 的上下文逐项处理。

如果用户的自由格式输入（阶段 0）或知识类 MCP（阶段 1）已给出明确答案：直接应用，无需确认。

否则：使用 AskUserQuestion。不要假定"行业标准"的默认值是正确的——如果用户输入和知识类 MCP 都没有提供具体答案，则应询问。注意：AskUserQuestion 始终包含"跳过"按钮和用于自定义答案的自由文本输入框，因此不要将 None 或 Other 作为选项。

更改类型：

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

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

阶段 4：搜索有用的 MCP

在定制项目处理完毕后，为已识别或已更改的工具连接相应的 MCP。完整流程、类别与关键词的对应关系以及配置文件格式，请参阅 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 结果，并在摘要输出中一并呈现（见下文）——在本阶段不要逐个展示 MCP。

打包插件

完成所有自定义设置后，将插件打包为 .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/ 中创建压缩包，然后再复制到输出文件夹。直接写入输出文件夹可能因权限问题而失败，并留下临时文件。

命名：.plugin 文件请使用原始插件目录名称（例如，如果插件目录为 coder，输出文件应为 coder.plugin）。在自定义过程中不要重命名插件或其文件，只替换占位值并更新内容。

摘要输出

自定义完成后，请向用户呈现按来源分组的学习内容摘要。务必包含 MCP 部分，说明在设置期间连接了哪些 MCP，以及用户仍需连接哪些 MCP：

## From searching Slack

- You use Asana for project management
- Sprint cycles are 2 weeks

## From searching documents

- Story points use T-shirt sizes

## From your answers

- Ticket statuses are: Backlog, In Progress, In Review, Done

然后呈现设置期间已连接的 MCP，以及用户仍需连接的 MCP，并附上连接说明。

如果第一阶段没有可用的知识类 MCP，且用户至少需要手动回答一个问题，请在末尾添加以下说明：

顺便一提，连接 Slack 或 Microsoft Teams 等来源后，下次自定义插件时我就能自动查找答案。

其他资源

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