Codebase Autopilot

Dependency Triage

A weekly triage that reviews your open dependency PRs on real evidence and merges only what you've authorized.

Moderate setupLong cycleOpen loopVisible first run

Setup in Loopany

How a run flows

Before first run

Confirm merge authority

On schedule

Every Mon

Step 1 · Snapshot

List open dep PRs

Step 2 · Judge

Weigh real evidence

Isolated git worktree · off main

Step 3 · Test

Run tests in isolation

Step 4 · Merge

Merge only what’s authorized

Board

Dependency PRs

Metric

Open dependency PRs

open loop — repeats on the next tick, picking up where it left off

Prerequisites

gh with access to your dependency PRsrequired
The triage reads Dependabot/Renovate PRs and each one's CI through gh.
Verifier setup for code changesoptional
A repo-specific harness so every fix is proven against the real app before a PR. Set it up with the verifier-setup skill

How this loop works — schedule, exit, notifications

Suggested schedule: Weekly · Mon
Loop type: Open loop — an ongoing monitor with no finish line.
Exit condition: Runs indefinitely (no finish line).
Notifications: On by default — you're alerted on each run's outcome (completion or failure). Silence with notify: never.
Ease of starting: Some setup and context are needed before the first useful run.
When you see value: If you have open dependency PRs, the first triage clears the provably-safe ones.

Last month, Dependency Triage picked up 31 alerts and updates. Eight were safe enough to handle in one review, 5 came to me, and we closed the other 18 with a reason attached.

One run's triage report: the safe batch, the five that need a person, and every close with the reason it was closed

First question: can our code even reach it? A CVE can sit in a dependency without touching a path we ship. Most of the scary alerts fell away at the real import surface, and the loop kept the evidence.

Patch updates only make the review batch after we've read the actual diff and release notes, checked the advisory, and seen CI pass on that PR head. Major changes wait. So do breaking or security-sensitive ones.

Whenever we ignore an alert, the reason goes into the ledger. Next week's run doesn't start the old argument again. Out of 31 items, I only had to decide on 5. The other 26 already had an answer attached.

The prompt this runs

Set up a weekly dependency-triage loop for this project. Before creating it, verify gh can see this repo's Dependabot or Renovate PRs and run one listing as a smoke test, then confirm with me whether the loop may merge low-risk patch and minor updates or must stay review-and-report-only. Every Monday morning my local time, snapshot the open dependency PRs and process each exactly once: judge it on its actual diff, release notes, advisories, and CI results at the exact head - version labels are inputs, not proof of safety - and run the tests in a fresh git worktree off the main branch and located outside the loop folder - the loop folder is a synced content home, not a workspace - so neither my working checkout nor the sync is polluted. Merge only what I authorized; give anything major, breaking, or security-sensitive a clear recommendation instead, and flag high or critical advisories affecting it. Track each PR as a markdown card with front matter `type: merged`, `type: deferred`, or `type: blocked`, and report the open-dependency-PR count as a metric. Set up the loop's dashboard at creation: a kanban of the PR cards plus a chart of that count over time.

This is the exact intent appended to the bootstrap when you create the loop — your coding agent reads it, then proposes cadence and config and confirms with you before creating anything.