workflow-update

workflow-update — 检查与更新插件

先判安装形态，再查版本。 插件有两条分发渠道，版本真值不是同一个：宿主托管安装（Claude Code marketplace）认公开仓的 plugin.json，手动安装（Codex / 官网脚本）认官网 version.json。两条渠道的发布节奏可以脱节，拿另一条渠道的版本号判自己，会得出「已是最新」甚至反向降级的错误结论。

1. 判断安装形态

看本技能所在路径，按下面的顺序判，先命中先算：

0. 源码态 —— 向上两级既是插件根、又带 .git 或 tests/（你在开发这个插件本身，不是在用它）→ 提示无需更新，结束。源码态归 git 管，不归本技能；这一条必须先判，否则插件仓库自己的工作副本会被下面的清单特征误判成宿主托管。

A. 宿主托管安装 —— 技能路径在 ~/.claude/plugins/cache 或其他客户端的插件缓存下 → 走第 2 节。 没有缓存路径特征、但向上两级是插件根（存在 plugin.json 或 .claude-plugin/plugin.json），且不在 B 列出的手动安装目录里，同样按 A 处理。

B. 手动安装 —— 技能目录直接落在 ~/.codex/skills、.agents/skills 或 ~/.claude/skills 下 → 走第 3 节。B 的路径特征优先于 A 的清单特征：项目里恰好放着一份 plugin.json，不改变这是手动安装的事实。

2. 宿主托管：交给宿主更新

这条路不读 version.json。 那份清单只服务手动安装渠道，可能滞后于 marketplace 发布；宿主托管的版本真值是 marketplace 公开仓里的 plugin.json，由宿主自己拉取比对。用官网清单判宿主托管安装，最常见的结果是误报「已是最新」，用户永远升不上去。

本技能不自改插件目录——宿主管理的目录由宿主维护，绕过它手改会造成状态不一致。改为提示用户走宿主自己的机制：

• Claude Code：先刷新 marketplace，再更新插件。

claude plugin marketplace update workflow-plugin
claude plugin update workflow@workflow-plugin --scope user

也可以用 /plugin 界面，或等 marketplace autoUpdate 自己生效。更新后必须重启会话才加载新版本——不提醒的话用户会以为没升成功。

• 其他 Agent Plugins 客户端：用各自的安装器重装（例如 npx plugins add 那条路径）。

收尾读 claude plugin list（或宿主对应的列表命令）确认版本已变，向用户报告新旧版本号。

3. 手动安装：比对官网版本

读本技能目录下的 VERSION 文件（安装包内由构建器生成，纯文本一行版本号）。

• 没有 VERSION 文件 = 你运行的是源码态（开发仓里直接用），提示无需更新，结束。

抓取：

https://workflow.games/plugin/version.json?cb=<当前 epoch 秒>

必须带 cb 参数（当前时间戳）绕 CDN 缓存，否则可能拿到旧版本误判「已最新」。返回含 version、notes（更新说明）与 files（文件清单地址）。

按语义化版本逐段比大小，不做字符串相等判断（0.10.0 > 0.9.0，字符串比较会判反）：

• 线上 == 本地 → 报告「已是最新（<版本>）」，结束。
• 线上 < 本地 → 本地更新（多半是源码态或线上发布滞后）。报告两个版本号并结束，绝不"更新"——照旧逻辑跑会把新版覆盖成旧版，是降级不是升级。
• 线上 > 本地 → 才进入第 4 节。

4. 自更新流程（仅手动安装）

1. 抓取 version.json 的 files 指向的文件清单（同样加 cb 参数）。
2. 逐文件下载到临时目录（不直接写目标）。
3. 逐一校验 sha256：任何一个不符 → 立即中止并报告，不落盘任何文件。
4. 全部通过后：把现有 workflow-* 技能目录改名加 .bak-<旧版本> 后缀备份，再把新文件就位。
5. 读新 VERSION 确认版本已变，向用户转述 version.json 的 notes。