菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | dependency-update-loop |
| description | 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. |
| disable-model-invocation | true |
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.
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.
Don't assume — check what's actually in the repo:
package.json + its lockfileCargo.toml + Cargo.lockgo.mod + go.sumpyproject.toml/requirements*.txt + poetry.lock/uv.lockA monorepo may have more than one; match each PR to the ecosystem its diff touches.
For every PR still open from Step 1:
cargo update -p <crate> conflicts, go mod tidy) — a stale lockfile is the single most common reason these PRs go red for reasons unrelated to the actual bump.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.
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.
For each PR, report exactly one of:
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.
Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.
Reference for designing agent loops — cycles of work that repeat until a stop condition is met. Covers the four loop shapes, writing completion criteria, carrying state and isolating work across cycles, and what running unattended still leaves on you.
Recurring check-in on a stack of dependent PRs — rebase children onto updated parents, surface CI state, flag anything waiting on a human-only gate, and report only what changed since last time. Meant to be handed to a time-based loop, not run once.
Pick the skill or flow that fits your situation. A router over the skills in this repo.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Shared vocabulary and principles for designing deep modules. Use when the user wants to design or refine a module's interface, hunt for deepening opportunities, decide where a seam belongs, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.