Automation & Ops dependency-managementuvpyproject-tomlgithub-actionsdockercooldown-policypython-versioninglockfile

Dependency Refresh Playbook

A disciplined, safety-first playbook for running the monthly dependency and version refresh across Python lockfiles, Actions, uv CLI, base images, and infra images in agent-service-toolkit.

FollowSkills review · FSRS-1.0
Recommended
59/ 100 5-point scale 3.0 / 5
This review was completed under FSRS 1.0. Dimension scores are not converted; it is queued for re-review under FSRS 2.0.
1 2 3 4 5 6
1Utility10 / 20 · 2.5/5

The project's own dependency-upgrade workflow (requires reading the full playbook before touching any pin, no improvising) — for this project's maintainer.

2Reliability13 / 20 · 3.3/5
3Safety18 / 25 · 3.6/5
4Evidence5 / 15 · 1.7/5
5Usability7 / 10 · 3.5/5
6Maintenance6 / 10 · 3.0/5
Evidence confidence:Low Reviewed Jul 17, 2026
Review evidence [1]
See the full review method →

What does this skill do, and when should you use it?

dependency-refresh is a self-contained operational skill inside the agent-service-toolkit repository, providing a complete playbook for dependency refreshes. It goes beyond bumping Python packages in pyproject.toml/uv.lock: it also covers Docker base images, GitHub Actions pins, the uv CLI version (synced in four places), the supported Python range, and the postgres/mongo/LangFuse infra images used by compose and smoke tests. Two cooldown layers are built in: a global 14-day resolver cooldown enforced by uv's exclude-newer, and a three-month major cooldown for key dependencies. Each refresh produces exactly one PR whose body doubles as the state record for the next round. A references directory captures version-coupling constraints and the live end-to-end verification recipe.

Step 0 searches for the most recent refresh PR to recover the deferred-majors table and verification caveats; it then surveys all candidates against the PyPI API plus non-Python surfaces (Actions pins, uv CLI, base images, infra tags). Each candidate is triaged against both cooldowns; safe bumps are applied by editing pins in pyproject.toml; uv lock --upgrade re-resolves and pins are reconciled to the lock. Verification runs uv sync --frozen, ruff check, ruff format --check, pyrefly check, and pytest, followed by the live e2e recipe (fake-model HTTP ladder, Streamlit browser smoke) and relevant scripts/smoke_test.sh targets when checkpointers, AG-UI, or LangFuse moved. The round ends with one PR using the fixed branch name, title, and a body template with 'What moved', 'Deferred majors & cooldowns', and 'Verification' sections.

  1. A solo maintainer of a LangGraph/FastAPI/Streamlit project who wants regular, non-risky dependency upgrades
  2. A maintainer responding to a Dependabot security advisory who needs the sanctioned cooldown override for an immediate fix
  3. Teams hitting resolver conflicts when coupled packages like langchain and langgraph must move in lockstep
  4. Operators who must wait before adopting postgres/mongo image majors that can change on-disk formats
  5. AI maintenance-agent workflows that need every refresh traceable in a PR (what moved, what was deferred, verification results)
  6. Projects needing to keep the Python support range, CI matrix, ruff target-version, and Docker base images mutually consistent

What are this skill's strengths and limitations?

Pros
  • Fully self-contained playbook covering state recovery through PR submission
  • Two cooldown layers (uv-enforced 14-day + process-enforced 3-month major cooldown) sharply reduce the risk of adopting broken or compromised fresh releases
  • PR-as-state-record convention makes every round traceable, with the deferred-majors table carried forward automatically
  • references/coupling-constraints.md encodes real-world gotchas (langchain⇄langgraph lockstep, checkpointer majors, uv quirks)
  • A clearly defined, single sanctioned security override with a commented temporary setting removed next round
Limitations
  • Deeply tied to agent-service-toolkit's file layout (uv.lock, compose.yaml, scripts/smoke_test.sh); substantial rework needed for other repos
  • Process rules (3-month cooldown, PR template) rely on the model following them, with no mechanical enforcement
  • Smoke tests require a Docker daemon, and the LangFuse target is explicitly heavyweight (full self-host stack)
  • Running state lives in past PR descriptions rather than files, so recovery depends on PR search succeeding

How do you install this skill?

This skill is one of 4 bundled in JoshuaC215/agent-service-toolkit, at .claude/skills/dependency-refresh/. Place the skill folder (SKILL.md plus references/coupling-constraints.md and references/live-e2e.md) into your project's .claude/skills/ directory for Claude Code. The repository README documents installation of the whole collection; standalone installation steps for just this skill are not documented in the source.

How do you use this skill?

In a repo with the skill installed, ask Claude to "update dependencies", "bump versions", or "do a dependency refresh", or wait for the scheduled monthly run. The skill executes its steps automatically: recover the last PR's state, survey, triage, apply safe bumps, re-lock, run static checks, run live verification, and produce the formatted refresh PR. Note the playbook is written for agent-service-toolkit's specific structure — references contain project-specific coupling constraints, so porting to another repo requires adaptation.

How does this skill compare with similar options?

Compared with simply running uv lock --upgrade or auto-merging Dependabot PRs, this skill adds cooldown policies, key-dependency major deferral, cross-surface syncing (Actions/uv CLI/images), and a traceable PR-based state record — at the cost of being heavier, slower, and coupled to one repository's structure.

FAQ

When can a freshly released package enter the lock?
By default, not until it is at least 14 days old (uv's exclude-newer global cooldown). Majors of key dependencies (postgres, mongo, streamlit, fastapi, pydantic, langgraph/langchain and langgraph-checkpoint-*) additionally wait at least 3 months after X.0.0 and land in a dedicated PR. The only exception is a release fixing a vulnerability affecting this repo, which can land immediately via a commented temporary per-package override.
Can I use this skill as-is on my own repository?
Not fully. The workflow shape and cooldown policies are general, but the version-location table, coupling constraints, smoke-test targets, and PR conventions are written for agent-service-toolkit's structure — porting requires rewriting the references and file paths.
What permissions and environment does a refresh run need?
Shell execution, network access (PyPI API, GitHub PR search), filesystem read/write on the repo, the repo's pinned uv CLI version, and ruff, pyrefly, and pytest; touching checkpointers, AG-UI, or LangFuse additionally requires a Docker daemon.
What if the previous refresh PR can't be found?
Step 0 defines a three-level fallback: search PR titles for "dependency refresh", then search by head-branch prefix claude/dependency-refresh, finally git log on main for commits touching uv.lock and look up their PRs.

More skills from this repository

All from JoshuaC215/agent-service-toolkit

Related skills