ChatGPT 技能装进 WorkBuddy

这个插件解决什么问题

ChatGPT 侧导出的技能包、插件捆绑包或 Custom GPT 配置，和 WorkBuddy 的产物模型并不对齐：前者可能是 .zip、.codex-plugin 清单或一段粘贴的 GPT 配置，后者则要求严格的 SKILL.md frontmatter、共享目录结构或专家包格式。直接复制粘贴要么加载失败，要么触发自带 validator 的契约检查报错，更隐蔽的风险是导出包里的 scripts/ 可能包含未审计的命令执行或网络调用。这个技能把"搬运 + 适配 + 安全审计"压缩成一条有明确路由的工作流，让导入产物既能跑、又不会背着未知行为进入本地环境。

核心工作流：先判别形态，再动手转换

第 0 步是强制路由，不是可选项。 即便用户明说"转成 skill"，也要先回答三个判据问题：

• Q1 包结构（确定性）：单个 SKILL.md 走 skill；plugin.json + 多 skills 捆绑走套件；Custom GPT 进入语义判据。
• Q2 核心价值（语义判据）：用户主要是"和这个角色对话"还是"把某类事办了"。前者是专家，且结论必须写明理由、经用户确认后才能执行。
• Q3 是否依赖外部 API：存在 Actions / OpenAPI spec 的源物必须走套件，因为单个 skill 无法原生承载 MCP server 这类集成。

判别完成后按路由转换：路由 A 保留源包正文不动，仅扩展 frontmatter（name、description、version、agent_created 等字段按规则映射），随后把整目录复制到用户技能目录并跑冒烟测试。路线 B 处理多 skill 捆绑时，共享包整目录保留、每个 skill 单独安装，并把正文里的 ../../scripts/ 引用改写为安装后的相对路径；含 OpenAPI 的源物则需要生成真正的 MCP server，属于高工作量路径，必须先与用户确认范围。路由 C 把 Custom GPT 的人设、工作流程、知识文件映射为专家包结构，走完整的生成、校验、注册流程，多角色分工场景升级为 Team 型专家。

安全审计贯穿所有路由。 在任何文件修改之前，先对源物做纯静态分析，扫描 scripts/ 中的命令执行、网络请求、文件写删与敏感路径访问，区分"自动执行"（定 P0/P1）与"仅作文档示例"（不报），任何 P0 风险必须先警告用户取得确认。

适用边界

• 纯静态，不代跑未知代码。 审计阶段绝不执行被审脚本；唯一的例外是路由 A.3 的本地确定性冒烟，且传参时 Windows 路径必须写成 C:/Users/... 形式，Git Bash 风格会导致 python 找不到文件。
• validator 与正文互锁。 源包自带的 validate_* 脚本常会校验 name 正则与伦理护栏短语，所以正文必须保持原样，改坏任何一处都会让契约检查失败。
• 降格与升格都合理。 无 Actions 的 Custom GPT 可以降级为单 skill 更轻量，强人设 skill 也可以升格为专家。两者都成立时列出选项让用户拍板，不要自行二选一。