gstack-upgrade

其他 社区 v1.1.0
解读按原文结构重写,命令、链接、术语均保留;右侧可核对作者原始 SKILL.md

设计思路

gstack-upgrade 是 gstack 自身的「自我升级」skill——支持两种触发:preamble 检测到新版自动跑(inline upgrade flow),用户主动 /gstack-upgrade 跑(standalone)。还要处理「全局装一份 + 项目里 vendored 一份」这种双轨布局,team mode 时要自动清理项目里残留的 vendored 副本,保证团队共享同一全局版本。

Inline upgrade flow(被 preamble 触发)

Step 1-3:检测 UPGRADE_AVAILABLE <old> <new>,按用户配置(auto-upgrade 或 4 选项 AskUserQuestion)决定走 / 跳过 / 推迟。

Step 4-5:跑实际升级(git pull / curl 安装脚本 / 复制 release tarball),写「just-upgraded-from」标记,清掉 last-update-check / update-snoozed 缓存让下一次 preamble 不再误报。

Step 6:Show What's New$INSTALL_DIR/CHANGELOG.md,找 old → new 之间的全部条目,按主题汇成 5-7 条 bullet。focus on user-facing changes——内部 refactor 除非很关键否则跳过。

gstack v{new} — upgraded from v{old}!

What's new:
- [bullet 1]
- [bullet 2]
- ...

Happy shipping!

Step 7:Continue——升级完成,回到用户原本调用的 skill。

Standalone usage(/gstack-upgrade 直调)

  1. gstack-update-check --force 强制刷新(绕过 cache)。
  2. 看是否 UPGRADE_AVAILABLE
    • 有 → 走 Steps 2-6
    • 无 → 检查项目里有没有 stale vendored 副本:
      • 没 vendored 副本:「You're already on the latest version (v{version}).」
      • 有 vendored 副本 + team mode = true:移除 vendored 副本,告诉用户提交 .gitignore 的变化
      • 有 vendored 副本 + team mode ≠ true:对比 PRIMARY_VERLOCAL_VER,差异时同步 local;一致时确认两份都最新

适合谁

  • 用 gstack 工具链的所有人
  • 团队负责人——确保大家都跑同版本
  • 多项目切换、有 vendored 历史的工程师

不适合

  • 不是 gstack 用户
  • 离线 / 内网环境无法访问 release 源

配套

gstack(生态入口)、document-release(发布前文档体检)、ship(发布主流程)。

流狐档案 作者与许可取自来源;运行、权限和网络为流狐检测或估算
流狐分类
通用
作者声明 Agent
未找到明确声明;不据此推断已兼容或已测试
静态检查
92 / 100 · 启发式扫描,不代表运行安全
作者 / 版本 / 许可
@garrytan · v1.1.0 · 未声明 license
流狐 Token 估算
低消耗
流狐接入估算
需简单配置
是否需要外部 API Key
未发现要求
检测到的系统要求
macOS · Linux · Windows
底层运行要求
Bun
检测到的文件与系统行为
  • 只读
  • 允许写入 / 修改
  • Shell 执行
检测到的网络行为
允许外网请求
安装命令数
无(仅作为资料)

档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。

需要注意: 未限定 allowed-tools,默认拥有全部工具权限。

输出预览 gstack-upgrade.preview
作者没有在当前 SKILL.md 中定义固定输出样例。

讨论

基于 GitHub Discussions。登录 GitHub 即可参与讨论、点赞、订阅更新。