| name | imagi-update-check |
| description | 检查 imagi CLI 是否有新版本。新会话开始时应优先调用一次;如有更新,征得用户同意后执行全局升级并拉取最新知识库。无更新时静默,不打扰用户。 |
imagi Update Check
每次新会话开始,先跑一次更新检查。没更新就静默跳过。
1. 判定项目是否需要检查
test -f .ai/manifest.json && echo OK || echo SKIP
- 输出
OK:本项目是已 init 的 imagi 目标项目,继续下一步
- 输出
SKIP:没接入 imagi,直接结束,不要检查也不要提更新的事
2. 查版本(用独立脚本,不要用 npm view)
node .claude/hooks/check-updates.mjs 2>/dev/null
为什么不用 npm view:Claude Code 的 bash 跑 npm view 经常卡住(代理问题),但 fetch 直连 GitLab API 不卡。这个脚本已经做了 fetch + 写缓存。
输出(stdout 一行 JSON):
- 成功:
{"local":"1.2.2","latest":"1.2.3","hasUpdate":true,"checkedAt":"..."}
- 一致:
{"local":"1.2.2","latest":"1.2.2","hasUpdate":false,...}
- 失败:
{"error":"timeout"} 或脚本退出码 1
3. 对比(基于脚本输出)
解析上一步 JSON:
hasUpdate === false:静默结束(什么都不说,继续正常对话)
error 字段存在或退出码非 0:静默结束,不向用户报错
hasUpdate === true:进第 5 步(step 4 跳过,已并在脚本里)
4.(已并入第 2 步)
5. 告知用户并等确认
用简短一句话告知用户:
imagi 有新版本:vX.Y.Z → vX.Y.Z+1。要现在升级并拉取最新知识库吗?(y/n)
等用户回复。用户不同意或忽略 → 不执行,继续原对话。
6. 用户同意后按顺序执行
步骤 A:全局升级 CLI
HTTP_PROXY= HTTPS_PROXY= npm i -g @frontend/imagi-cli@latest
两个前缀 / 参数的说明:
HTTP_PROXY= HTTPS_PROXY=:Claude Code bash 环境有代理变量(clash),代理对公司内网 g.echo.tech 会卡死。前缀临时置空让 npm 直连内网,3-10 秒完成。去掉会卡 90 秒超时失败。
- 不加
--registry=...:用户 ~/.npmrc 里已经有 @frontend:registry=https://g.echo.tech/... scope 配置,npm 会自动路由 @frontend/imagi-cli 到内网、公共依赖(glob / chalk 等)到默认 registry。加了 --registry 反而会强制所有依赖都去内网 registry 结果 404。
步骤 B:拉取最新知识库
imagi sync
保持默认交互模式,不要加 --auto。sync 会打印变更分类:
SKIP / AUTO 类:已自动应用
AI_REVIEW 类:需要审阅,把命令行输出原样给用户看,让用户决定下一步
步骤 C:确认结果
imagi doctor
如输出有 error/warn,告知用户具体是什么问题 + 建议的修复命令。
步骤 D:升级后自检
调用 imagi-verify skill 做一次自检。按 sync 的 diff 范围挑 group 跑,不全量。verify 会派 imagi-verifier subagent 执行,返回 PASS/FAIL 报告。
- 全通过 → 一句话告知用户升级成功
- 有 FAIL → 报告问题 + 建议修复
7. 异常处理
npm i -g 失败(权限 / 网络 / registry)→ 告知用户失败原因 + 建议手动在终端跑命令(加 sudo 或换代理)
imagi sync 失败 → 告知用户 + 指出 imagi doctor 排查
- 不要在失败时静默吞错
8. 频率
每个新 session 检查一次。同一 session 内不重复检查(避免打扰)。