All loops

Engineering

Dependency triage loop

A recurring loop that sweeps your open Dependabot PRs, merging the safe bumps, fixing failing CI, flagging the risky ones with a written assessment, and posting a digest to Slack.

Trigger
Recurring sweep over open Dependabot PRs
Goal
Clear the safe updates, fix what's broken, and rank the rest by risk
Artifact
Safe bumps merged, CI fixes pushed, risky bumps assessed, plus a Slack digest of everything it did
Handoff
You review what it merged and make the call on anything risky
Tools
Claude Code · GitHub CLI (gh) · Slack (MCP)
The loop, ready to run 
Review all open Dependabot pull requests on this repository and process each one.

1. List all open PRs authored by Dependabot:
   gh pr list --author "app/dependabot" --state open --json number,title,headRefName,statusCheckRollup

2. For each open PR, spawn an agent (Agent tool, isolation: "worktree") to handle it
   independently. Each agent should:

   a. Check out the PR branch in its worktree.
   b. Determine CI status from the PR's status checks.

   If CI is FAILING:
   - Read the failure logs: gh pr checks <number>, then gh run view <run-id> --log-failed
   - Identify the root cause of the failure.
   - Attempt a fix: update code, configuration, or tests as needed.
   - Commit the fix and push to the PR branch.
   - If you are unable to fix it, comment your findings on the PR.

   If CI is PASSING:
   - Review the full changeset: gh pr diff <number>
   - Read the dependency's changelog / release notes if available.
   - Evaluate risk:
     - Is this a major version bump? (higher risk)
     - Are there breaking changes noted in the changelog?
     - Does it touch a security-sensitive dependency?
     - Is it a patch/minor update with only bug fixes? (lower risk)
   - If the update appears SAFE (patch/minor with no breaking changes):
     merge it with gh pr merge <number> --squash
   - If the update appears RISKY (major bump, breaking changes, or uncertainty):
     comment a detailed risk assessment on the PR explaining what you found and
     why you chose not to auto-merge.

3. After all agents complete, compile a summary of every action taken and send it to
   your Slack channel (replace <your Slack channel> with the channel ID) using the
   Slack MCP tool. Include:
   - Total PRs reviewed
   - PRs merged (with dependency name and version)
   - PRs where fixes were pushed (with a description of the fix)
   - PRs left for manual review (with a risk-assessment summary)
   - Any PRs that couldn't be processed, and why

If there are no open Dependabot PRs, send a short "No open Dependabot PRs" message to
your Slack channel.

Use this when

Use this when Dependabot or Renovate keeps a steady pile of update PRs and you want the safe, boring bumps cleared and the genuinely risky ones surfaced, without reading every diff yourself.

How to run it

Run it from inside the target repo with the GitHub CLI authenticated and the Slack MCP server connected for the digest.

It fans out one worktree-isolated agent per open PR, so every update is triaged in parallel without the branches colliding.

Each agent merges safe patch and minor bumps, diagnoses and pushes fixes for failing CI, and comments a risk assessment on anything major, breaking, or uncertain.

When the sweep finishes it posts a single Slack digest of everything it did. Give it a daily cadence so the pile is handled before you start.

Why it works

Isolated worktrees let the agent act on many PRs at once without one branch’s changes leaking into another. And because it only merges safe bumps, writing up everything risky instead of acting on it, the autonomous part stays conservative and auditable: you can always see why it merged, fixed, or held.

Get the next loops

I add new loops as I run them on real work — with the full prompt, the trigger setup, and what breaks. Drop your email and I'll send the next ones.

No spam. The loops, plus the occasional note on building with AI. Unsubscribe anytime.

Powered by Buttondown