dependabot-prs

Dependabot PR Review and Merge

Follow these steps:

1. Load per-repo preferences

Read ~/.claude/dependabot-prs.json (if it exists) and look up the current repo's entry:

config="$HOME/.claude/dependabot-prs.json"
repo=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
preferences=""
if [ -f "$config" ]; then
  preferences=$(jq -r --arg repo "$repo" '.[$repo] // empty' "$config")
fi

The file maps owner/repo to freeform instructions, e.g.:

{
  "ryanb/core-gem": "Only handle PRs with the javascript label."
}

If $preferences is non-empty, apply those instructions throughout the rest of the steps — for example, filtering the PR list, narrowing what to merge, or changing the merge strategy.

2. List open Dependabot PRs

Run gh pr list --author "dependabot[bot]" --state open to get all open Dependabot PRs.

If there are no open PRs, tell the user and stop.

3. Review each PR in a sub-agent

For each PR, launch a sub-agent (Agent tool, subagent_type: general-purpose and model: sonnet; run them in parallel) to review it. Each sub-agent should:

1. Get the PR details: gh pr view <number> --json title,body,url,statusCheckRollup,mergeable
2. Check if all CI checks passed (all statusCheckRollup entries have conclusion "SUCCESS")
3. Determine if this is a multi-dependency PR (e.g. a grouped Dependabot update bumping several packages at once). Check the PR title and body — grouped PRs typically list multiple packages.
4. Read the changelog/release notes in the PR body for anything surprising:
   • Breaking changes or deprecations
   • Dropped support for language/framework versions this codebase uses
   • New behaviors that could cause issues (e.g. new errors being raised)
   • Security fixes worth highlighting
5. For multi-dependency PRs, check each dependency individually against the codebase:
   • Search the codebase for direct usage of the package (imports, require calls, config references)
   • For each dependency, assess whether the version bump could introduce breaking changes based on the semver increment and release notes
   • Note which dependencies are directly used vs. transitive (less risky)
   • Report each dependency's safety status separately
6. Return a summary with: PR number and URL, title, CI status (pass/fail) and the build URL Step 4 links it to — detailsUrl for GitHub Actions checks, targetUrl for external ones like Buildkite, whether it's safe to merge, whether it's a multi-dependency PR, per-dependency safety status (for multi-dependency PRs), and any concerns