关于 absolute-upgrade
absolute-upgrade 是面向开发者的依赖升级技能,支持 npm、Python 和 Go 项目。它按风险分批升级,并通过项目测试与构建验证结果。
主要功能
- 01扫描多个生态中的过期依赖
- 02按版本变更风险排序
- 03逐个处理主版本升级
- 04重生成锁文件并运行测试和构建
- 05回退受阻批次并报告错误
适用场景
- 01处理常规依赖升级积压
- 02替换已弃用的软件包
- 03规划主版本迁移
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ maddhruv/ absolute --skill absolute-upgrade安装后在 Claude Code 中输入/absolute-upgrade确认已加载。
附带文件README.mdreferences/health-engine.md
详细介绍
首次响应请以 ⬆️ emoji 开头。
Absolute Upgrade
安全地更新依赖 — 按风险等级分批进行,并确保每批完成后测试通过。
这不是盲目运行 npm update:过时和存在漏洞的依赖会按影响范围分组
(补丁/次要版本 → 安全批次;主要版本/破坏性变更 → 设门槛、一次一个,先读变更日志),逐步应用,并根据项目自身的测试套件进行验证。
运行 references/health-engine.md 中的共享引擎 — 请阅读该文件,了解
DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT 循环和安全约定。本文件
仅涵盖依赖升级的特定内容。
适用场景
- 常规的“更新依赖” / “升级我们的依赖”。
- 指定升级:“将 React 升级到 19”、“弃用已过时的 X 包”。
- 清理
npm outdated/ Dependabot 待处理列表,避免创建 40 个独立 PR。
不适用于:添加新依赖(这是 work/功能决策),或专门审计
漏洞 → 使用 /absolute audit(它负责对 CVE 进行分诊;upgrade
负责升级版本)。
扫描内容
按生态系统列出过时依赖,并显示当前版本 → 目标版本 → 最新版本及升级幅度:
| 生态系统 | 检测过时依赖 | 锁文件 / 清单 |
|---|---|---|
| npm | npm outdated --json | package-lock.json |
| pnpm | pnpm outdated --format json | pnpm-lock.yaml |
| yarn | yarn outdated --json | yarn.lock |
| Python (pip) | pip list --outdated --format=json | requirements*.txt |
| Python (poetry/uv) | poetry show --outdated / uv pip list --outdated | pyproject.toml + 锁文件 |
| Go | go list -u -m -json all | go.mod / go.sum |
还会标记:已知弃用的依赖、同一包的重复/多个版本,以及直接依赖与传递依赖(只有直接依赖是升级目标;传递依赖随其更新)。
风险排序(TRIAGE)
按 SemVer 升级幅度将升级计划分批,优先处理风险最低的变更:
| 批次 | 升级幅度 | 默认处理方式 |
|---|---|---|
| 1 | 补丁版本(x.y.Z) | 一起批量处理,立即修复 |
| 2 | 次要版本(x.Y.z) | 按包系列批量处理,立即修复 |
| 3 | 主要版本(X.y.z)/ pre-1.0 次要版本 | 一次一个,设门槛 — 先阅读变更日志/迁移指南,列出破坏性变更 |
对于每次主要版本升级:查找破坏性变更(CHANGELOG、发行说明,以及包提供的 codemod),盘点会涉及变更后 API 的调用点,并在应用前说明迁移方案。由某个依赖升级引发的对等依赖冲突,应在同一批次中解决。
修复与验证
- 应用一个批次,重新生成锁文件,运行项目的完整测试和构建(安装成功不代表升级成功)。
- 主要版本:在同一批次中应用版本升级并完成所需的代码迁移,否则构建会失败。若包提供 codemod,请使用。
- 如果某个批次无法在合理时间内通过测试 → 回滚该批次,将其报告为受阻并附上错误信息,同时保留通过的批次。绝不要使用
--force/--legacy-peer-deps掩盖实际冲突。
注意事项
- 只升级锁文件。 只升级清单而不重新生成并提交 锁文件,会引入未经测试的传递依赖版本。务必重新生成。
- 将主要版本升级混入补丁升级。 一项破坏性升级就会导致整个批次失败,也会让人难以判断是哪项变更导致问题。主要版本升级必须单独处理。
- 安装通过 ≠ 项目通过。
npm install成功无法证明任何事情 — 请运行测试。 - 通过固定版本规避失败。 如果升级导致问题,就修复或暂缓;不要悄悄固定 依赖树来绕开问题。
配套命令
/absolute audit— 如果目标是修复漏洞,请从这里开始;它会在版本升级时转到此处。/absolute deflake— 不稳定的测试可能会掩盖升级是否真正通过。/absolute work— 如果升级需要实际的功能级迁移工作,请移交处理。