用途：帮助团队系统化地升级项目依赖，而不是盲目执行 npm update。核心原则是按风险分批，而非图省事：先补丁和开发依赖，再次版本，主版本逐个单独提交，因为主版本才是真正破坏兼容性的地方。
主要能力：盘点过期依赖（Node 用 npm outdated / pnpm outdated / yarn outdated，Python 用 pip list --outdated 或 uv pip list --outdated，Rust 用 cargo outdated，Ruby 用 bundle outdated，Go 用 go list -m -u all），并收集安全公告与运行时、构建工具、测试运行器版本；对每个包分类（直接/开发/传递依赖，补丁/次版本/主版本，低/中/高风险，影响范围，是否有破坏性变更）；制定分批计划：批次1开发依赖补丁与次版本，批次2运行时补丁，批次3运行时次版本，批次4起每个主版本单独一次提交，语言运行时最后升级。执行每批时从干净工作区开始，升级、重建锁定文件、运行真实构建与完整测试套件、lint 并对有运行界面的应用做冒烟测试。失败时先调查，小修复随本提交完成，大问题单独处理。卡住的主版本先读迁移指南、评估影响范围，决定立即升级还是推迟，并记录后续任务。最后生成汇总报告，列出已完成批次、推迟项、有意保留项与安全公告处置情况。
使用方式：在 /gsd start dep-upgrade 工作流、临时“升级依赖”请求、安全公告响应、框架主版本更新或月度维护时触发。每批使用单独的精确提交信息，如 deps: bump <scope> — <what changed in one line>，并注明验证结果。
限制与注意事项：不要盲目 npm update、不要把多个主版本放进一个提交、不要在批次之间跳过验证、不要忽略 CHANGELOG、不要用 --force 强行合并失败批次、不要忽视 --legacy-peer-deps 警告。是否适用于具体生态或版本，资料未提供更多细节。