在 Cowork 桌面应用中定制 Claude Code…

当你需要把某个 Claude Code 插件模板适配到具体组织的工具、流程和约定时，用这套流程定位插件、判断定制模式、收集组织信息、逐项修改并打包成可安装的 .plugin 文件。

适用场景

解决思路

1. 定位插件目录：运行 `find mnt/.local-plugins mnt/.plugins -type d -name "*<plugin-name>*"` 找到插件目录，然后阅读其文件了解结构；若找不到目录，说明用户可能在远程容器中运行，应中止并告知："Customizing plugins is currently only available in the desktop app's Cowork mode."
2. 判断定制模式：运行 `grep -rn '~~\w' /path/to/plugin --include='*.md' --include='*.json'` 检查是否存在以 `~~` 开头的占位符。若存在占位符，默认走「通用插件设置」（除非用户明确要求定制某一部分）；若无占位符且用户要求定制特定部分，走「范围化定制」，只阅读并修改相关部分，不要扫描整个插件或展示无关项；若无占位符且用户想广泛修改，走「通用定制」，先阅读插件文件了解当前配置，再询问用户想改什么。
3. 处理遗留的 `commands/` 目录：把 `commands/*.md` 文件当作 `skills/*/SKILL.md` 一样对待，因为 Cowork UI 现在把它们统一呈现为 "Skills"。
4. 遵守命名约束：绝不更改被定制插件或技能的名称，不要重命名目录、文件或插件/技能名称字段。
5. 使用非技术化输出：所有面向用户的输出（待办事项、问题、总结）都用平实、非技术语言；绝不要向用户提及 `~~` 前缀、占位符或定制点，而要用插件能力和组织工具来描述。
6. 阶段 0（仅范围化和通用定制）：检查用户是否在请求中附带了自由文本上下文（例如 "customize the standup skill — we do async standups in #eng-updates every morning"）。若有，记录下来用于阶段 3 预填答案，跳过用户已回答的问题；若没有，用 AskUserQuestion 提一个开放式问题，问题要针对用户想定制的内容（例如 "What changes do you have in mind for the brief skill?" 或 "What would you like to change about how this plugin works?"），保持简短具体，并把回答作为后续阶段的额外上下文。
7. 阶段 1：使用公司内部知识 MCP 收集与定制范围相关的信息（参见 `references/search-strategies.md` 中按类别的查询模式）。要收集的内容：组织使用的工具名称和服务、组织流程与工作流、团队约定（命名、状态、估算尺度）、配置值（工作区 ID、项目名称、团队标识）。搜索来源：聊天/Slack MCP（工具提及、集成、工作流讨论）、文档 MCP（入职文档、工具指南、设置说明）、邮件 MCP（许可证通知、管理员邮件、设置邀请）。记录所有发现供阶段 3 使用。
8. 阶段 2：创建待办事项列表，并适当限定范围。范围化定制：只包含与用户所问特定部分相关的项。通用插件设置：运行 `grep -rn '~~\w' /path/to/plugin --include='*.md' --include='*.json'` 找出所有占位符定制点，按主题分组。通用定制：阅读插件文件、理解当前配置，并根据用户请求确定需要更改的内容。使用面向用户的描述，聚焦插件用途，例如用 "Learn how standup prep works at Company" 而不是 "Replace placeholders in skills/standup-prep/SKILL.md"。
9. 阶段 3：逐项完成待办。若用户的自由文本输入（阶段 0）或知识 MCP（阶段 1）给出了明确答案，直接应用而无需确认；否则使用 AskUserQuestion。不要假设 "行业标准" 默认值正确——若用户输入和知识 MCP 都没有给出具体答案，就询问。注意 AskUserQuestion 总是包含 Skip 按钮和自由文本输入框，因此不要把 `None` 或 `Other` 作为选项。变更类型包括：占位符替换（如 `~~Jira` → `Asana`、`~~your-org-channel` → `#engineering`）、内容更新（修改说明、技能、工作流或引用以匹配组织）、URL 模式更新（如 `tickets.example.com/your-team/123` → `app.asana.com/0/PROJECT_ID/TASK_ID`）、配置值（工作区 ID、项目名称、团队标识）。若用户不知道或跳过，保持原值不变（通用设置中则保留 `~~` 前缀占位符）。
10. 阶段 4：为定制过程中识别或更改的工具连接 MCP（参见 `references/mcp-servers.md` 获取完整工作流、类别到关键词映射和配置文件格式）。对每个工具：用 `search_mcp_registry(keywords=[...])` 按类别关键词搜索注册表，或直接搜索已知工具名；若未连接，用 `suggest_connectors(directoryUuids=["chosen-uuid"])` 让用户完成认证；更新插件的 MCP 配置文件（检查 `plugin.json` 是否有自定义位置，否则用根目录的 `.mcp.json`）。收集所有 MCP 结果，在总结输出中一起呈现，不要在此阶段逐个展示。
11. 打包插件：所有定制应用后，把插件打包为 `.plugin` 文件。先压缩插件目录（排除 `setup/`，因为不再需要）：`cd /path/to/plugin && zip -r /tmp/plugin-name.plugin . -x "setup/*" && cp /tmp/plugin-name.plugin /path/to/outputs/plugin-name.plugin`。然后把文件以 `.plugin` 扩展名呈现给用户，以便直接安装（会显示为富预览，用户可查看插件文件并点击按钮接受定制）。始终先在 `/tmp/` 创建 zip 再复制到输出文件夹，直接写入输出文件夹可能因权限失败并留下临时文件。使用原插件目录名作为 `.plugin` 文件名（如目录为 `coder`，输出应为 `coder.plugin`），不要重命名插件或其文件。
12. 输出总结：按来源分组展示学到什么，并始终包含 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 及连接说明。若阶段 1 没有可用的知识 MCP 且用户至少手动回答了一个问题，在结尾加注："By the way, connecting sources like Slack or Microsoft Teams would let me find answers automatically next time you customize a plugin."

适用边界 · 注意事项

• 需要 Cowork 桌面应用环境并能访问挂载的插件目录（mnt/.local-plugins、mnt/.plugins）；若在远程容器中运行则不可用。
• 不要更改插件或技能的名称，不要重命名目录、文件或插件/技能名称字段。
• 不要向用户提及 `~~` 前缀、占位符或定制点，也不要假设行业标准默认值正确。