# Dependency Update Loop

> Recurring maintenance pass over automated dependency-bump PRs (Dependabot, Renovate, or similar) — rebase, relock, verify, and report what's ready to merge. Meant to be handed to a time-based loop or schedule, not run once.

- **Type:** Skill
- **Install:** `agentstack add skill-officialunofficial-skills-dependency-update-loop`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [officialunofficial](https://agentstack.voostack.com/s/officialunofficial)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [officialunofficial](https://github.com/officialunofficial)
- **Source:** https://github.com/officialunofficial/skills/tree/main/skills/engineering/dependency-update-loop

## Install

```sh
agentstack add skill-officialunofficial-skills-dependency-update-loop
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Dependency update loop

Automated dependency-bump PRs rot the moment a lockfile-adjacent PR merges ahead of them, or two bumps in the same ecosystem conflict with each other. Left alone, they pile up stale and unreviewable. This is one pass over that backlog — designed to be re-run on an interval via a time-based loop, not to fix everything in one sitting.

## Step 1 — Enumerate the backlog

List open PRs from the bot(s) this repo uses (author is a recognizable bot account, or a branch prefix like `dependabot/*` / `renovate/*`). For each, capture: ecosystem, branch, base, mergeable state, and whether CI ran at all.

**Done when** you have that list, oldest first.

## Step 2 — Detect the ecosystems in play

Don't assume — check what's actually in the repo:

- Node/Bun/npm/pnpm/yarn: `package.json` + its lockfile
- Rust: `Cargo.toml` + `Cargo.lock`
- Go: `go.mod` + `go.sum`
- Python: `pyproject.toml`/`requirements*.txt` + `poetry.lock`/`uv.lock`

A monorepo may have more than one; match each PR to the ecosystem its diff touches.

## Step 3 — Refresh each PR

For every PR still open from Step 1:

1. Check out its branch, rebase (or merge) the current base into it.
2. Re-run that ecosystem's install/lock step so the lockfile reflects the rebase (e.g. reinstall after a Node rebase, `cargo update -p ` conflicts, `go mod tidy`) — a stale lockfile is the single most common reason these PRs go red for reasons unrelated to the actual bump.
3. Push the refreshed branch.
4. Run the project's real verification gate (its test suite, build, and lint — whatever `just ci`/`make ci`/an npm script/CI workflow actually runs) locally or by re-triggering CI; don't trust a stale check run from before the rebase.

**Done when** every PR from Step 1 has a fresh CI result against its current head, not a cached one.

## Step 4 — Batch same-ecosystem PRs before trusting any single one green

Two PRs in the same ecosystem can each pass individually and still conflict once both land (transitive version skew). Before recommending merge, rebase the *second* PR onto a branch that already includes the *first*'s change and re-verify — or merge the smaller/safer bump first and let Step 3 refresh the rest against the new base on the next cycle.

## Step 5 — Report, don't merge blindly

For each PR, report exactly one of:

- **Ready** — rebased, relocked, gate green against current head. Merge only if you've been given standing authorization to merge dependency PRs; otherwise leave it for a human to click.
- **Needs a human** — a major-version bump with a breaking-change note, a failing test that looks like a real incompatibility (not a stale-lockfile artifact), or a conflict Step 4 didn't resolve cleanly.
- **Unchanged since last pass** — nothing to do; don't re-report it every cycle, only note it once and skip it on subsequent runs until its state changes.

**Stop condition for the loop as a whole:** no open bot PRs remain, or a full pass produces zero state changes from the previous one.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [officialunofficial](https://github.com/officialunofficial)
- **Source:** [officialunofficial/skills](https://github.com/officialunofficial/skills)
- **License:** Apache-2.0

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-officialunofficial-skills-dependency-update-loop
- Seller: https://agentstack.voostack.com/s/officialunofficial
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.