pywf-oss-upgrade-deps
Upgrade, hold, or replace the dependencies of a pywf open-source Python library: find outdated and unmaintained packages, research changelogs and compatibility, update the constraints and lock file, a
SKILL.md.claude/skills/pywf-oss-upgrade-deps/SKILL.md
GitHubBring the dependencies up to date, with every change justified and verified.
Read ../pywf-oss-base/SKILL.md, then:
- ../pywf-oss-base/references/04-python-versions.md
- ../pywf-oss-base/references/05-uv-dependencies.md
- ../pywf-oss-base/references/13-sphinx.md (section 2.2 and section 4: the cross-reference check and the visual check)
- ../pywf-oss-base/references/15-furo.md (only for a theme upgrade)
- ../pywf-oss-base/references/24-dependency-upgrades.md
Steps
- Inventory. Run
uv tree --outdated --depth 1, check each direct dependency's last release date, and show a table: package, extra, locked version, latest version, last release date. - Research. Judge each candidate as in
24-dependency-upgrades.mdsection 2 (including when to delegate to a subagent). Present each verdict (upgrade / hold / replace) with the exact constraint string. - Decide. The user picks which verdicts to apply. On "just upgrade everything", apply every upgrade verdict, and still report the holds and replacements.
- Apply, as in
24-dependency-upgrades.mdsection 3. - Prove it. Run every regression check in
24-dependency-upgrades.mdsection 4, and report each as pass or fail. A failure sends that package back to step 2: hold it, or fix the code. - Commit after the user's yes, so the changelog sees the upgrade in git history.
Boundaries
- Upgrade the coupled packages listed in
24-dependency-upgrades.mdsection 2 together. - Never raise
requires-pythonas a side effect of an upgrade. It is the user's decision; ask it as a separate question.
Next step: pywf-oss-changelog, then pywf-oss-release.