Skip to content
Templates/Maintenance
MaintenanceMedium risk

Dependency Update Loop

Update dependencies in small, verified batches and stop when the build and tests pass.

What this Loop Engineering template does

Update dependencies to current safe versions in small batches, verifying the build and tests after each batch, without breaking the app.

Update in small, reviewable batches. Read the changelog for any non-patch bump. Do not mix unrelated upgrades.

When to use it

Routine dependency bumps
Security patch updates
Keeping lockfiles current

When not to use it

Major version upgrades with breaking changes
Unpinned, untested production deploys

Validation checks

validation
Install succeeds with the updated lockfile
Build passes
Test suite passes
No new high-severity audit warnings are introduced

Boundaries & stop rule

!Do not apply major version bumps without a human decision
!Do not edit application code beyond what the upgrade requires
!Do not ignore failing tests to land an update
!Do not remove the lockfile
Stop rule — Stop after each green batch for review, or after 3 failed attempts on the same package. If an upgrade breaks the build, revert that package, summarize the breakage and changelog notes, and recommend a human decision.

Copy the loop prompt

claude-goal.txt
/goal Update dependencies to current safe versions in small batches, verifying the build and tests after each batch, without breaking the app.
 
Work toward this goal until all validation checks pass or the stop rule is reached.
 
Loop cycle:
1. Discovery — Read the latest signal for this template before acting: CI output, issue detail, review comment, dataset report, or content brief.
2. Handoff — Hand the work to one agent in an isolated branch, worktree, or clearly scoped session. Keep final approval with a human.
3. Verification — Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.
4. Persistence — Save a short run note with the signal reviewed, actions taken, validation result, and next recommended step.
5. Scheduling — Run manually until the loop is reliable; only then consider a scheduled or event-triggered run.
 
Context:
Update in small, reviewable batches. Read the changelog for any non-patch bump. Do not mix unrelated upgrades.
 
Validation:
Install succeeds with the updated lockfile
Build passes
Test suite passes
No new high-severity audit warnings are introduced
 
Independent checker:
Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.
 
Boundaries:
Do not apply major version bumps without a human decision
Do not edit application code beyond what the upgrade requires
Do not ignore failing tests to land an update
Do not remove the lockfile
 
Stop rule:
Stop after each green batch for review, or after 3 failed attempts on the same package.
Maximum iterations: 5
 
Budget:
Stop before exceeding the agreed per-run token budget.
 
Human approval:
Required before merge, deploy, delete, purchase, or external communication.
 
Fallback:
If an upgrade breaks the build, revert that package, summarize the breakage and changelog notes, and recommend a human decision.
 
Do not delete tests, bypass checks, or modify unrelated files just to satisfy the validation condition. If blocked, stop and summarize the blocker, attempted fixes, and recommended next action.

Failure modes to watch

Mixing many upgrades so a failure is hard to bisect
Forcing a major bump that breaks the API
Editing app code to mask an incompatibility
Deleting or skipping tests

Loop Engineering FAQ

A small batch keeps failures easy to bisect and revert. One big update that breaks something can be hard to trace back to the offending package.