Dependabot Review

Dependabot Gem Upgrade Review

Current repo: !gh repo view --json nameWithOwner -q .nameWithOwner 2>/dev/null || echo "(unknown — run from inside the repo)"

Review Dependabot PRs and give the developer a concise, scannable verdict: what changed upstream, what could break (and how to fix it), what each gem touches in the codebase, and whether to merge.

Trigger phrases for audit mode: "review all open dependabot PRs", "which dependabot PRs are ready to merge", "audit our dep upgrades", "go through the open dep PRs", "check dependabot", any request for a status/report on pending dependency updates. Trigger single-PR mode on any GitHub PR URL related to dependabot, gem upgrades, or "bump" in the title. If the intent is ambiguous, default to audit mode.

Choosing a mode

Pick the mode based on what the user asked for:

• Single-PR mode — the user pasted a specific Dependabot PR URL or otherwise referenced one PR. Run the single-PR workflow below.
• Audit mode — the user asked about all open Dependabot PRs (phrases like "audit our deps", "review open dependabot PRs", "which dep upgrades are safe to merge"). Run the audit workflow. Do not ask the user to paste URLs — discover them with gh.

If the intent is ambiguous (e.g., "review dependabot"), default to audit mode since it's the superset and shows what's available.

Audit workflow (multiple PRs)

Step A1: Discover open Dependabot PRs

Determine the repo from the current working directory (gh repo view --json nameWithOwner -q .nameWithOwner). Then list open Dependabot PRs:

gh pr list --author "app/dependabot" --state open \
  --json number,title,url,createdAt,headRefName,labels \
  --limit 50

The app/ prefix in the author filter is required — Dependabot authors as the bot account app/dependabot. If gh returns an empty list, tell the user "No open Dependabot PRs in <repo>." and stop.

Before diving into analysis, surface the scope to the user in one line: "Found N open Dependabot PRs. Analyzing each now…" — this sets expectations when there are many to crunch through.

Step A2: Analyze each PR

For every PR returned, run the single-PR workflow (Steps 1-3 below) to gather bump type, changelog highlights, and codebase impact. Keep each analysis tight — you'll be producing per-PR sections for a combined report, not standalone documents.

You can fetch independent PRs in parallel where the tool call structure allows it.

Step A3: Produce the consolidated report

Emit the report in this order:

1. A short preamble: "Reviewed N open Dependabot PRs in <repo>."
2. A summary table (see the "Audit summary table" section below for the shape).
3. A Details section with one subsection per PR, each following the single-PR output format (but condensed — keep per-PR detail to ~15-25 lines).
4. A closing Overall recommendation block: which PRs to merge now, which to investigate, which to hold. Group by verdict so the dev can work top-to-bottom.

Step A4: Offer to post findings as PR comments

After the consolidated report, follow the shared "Posting findings to PRs" section below. For audit mode, the opt-in prompt covers the whole batch ("yes / no / selective"), and the comment body for each PR is drawn from that PR's per-PR detail section in Step A3.

Audit summary table

The summary table is the first thing the dev reads — its job is to let them triage the whole batch in under a minute. Render it as a GitHub-flavored markdown table with these exact columns, in this order:

Sort order: primary key is verdict in the order Merge → Verify → Investigate → Hold (worklist-style — easy wins first, stop when you hit "Investigate"). Within each verdict bucket, sort by Age descending so the stalest PRs rise to the top of their bucket — PRs that have been rotting in the queue often hide the real merge friction.

Security exception: any row with the 🔒 marker jumps to the top of the entire table regardless of verdict bucket, because security urgency overrides the triage-by-ease ordering.

Verdict abbreviations (use these exact strings so the column stays narrow and scannable):

• Merge — safe, low risk
• Verify — safe pending specific checks (detail lives in the per-PR section)
• Investigate — needs human judgment
• Hold — breaking changes require code work first

Do not add extra columns (branch name, author, CI status, labels). Seven is already the comfortable ceiling for terminal width, and every extra column dilutes the signal. If something doesn't fit the table, it belongs in the per-PR detail section, not here.

Single-PR workflow

Step 1: Fetch PR Details

Parse the PR URL to extract the owner, repo, and PR number. When invoked via audit mode, these come from the gh pr list output — no parsing needed.

gh pr view <NUMBER> --repo <OWNER/REPO> --json title,body,url,files,headRefName
gh pr diff <NUMBER> --repo <OWNER/REPO>

From the diff, extract for each gem being updated:

• Gem name, old version, new version
• Bump type: patch (0.0.x), minor (0.x.0), or major (x.0.0)

If the PR updates multiple gems, analyze them together in a combined summary with one section per gem.

Step 2: Review Changelog & Breaking Changes

This is the most important step. Developers need to know what changed and whether anything will break.

Fetch the changelog between old and new versions. Try these sources:

1. GitHub changelog — use gh to fetch the raw changelog file from the gem's repo (usually CHANGELOG.md, Changes.md, or HISTORY.md at the repo root)
2. GitHub releases — check https://github.com/<gem-source-repo>/releases
3. RubyGems.org — https://rubygems.org/gems/<gem-name> links to the source

Patch/minor bumps: read the relevant version sections in full — they're short.

Major bumps: do not read the full changelog or migration guide. Large gems (Rails, Sidekiq, Devise, ActiveRecord) have thousands of lines of changelog prose that will exhaust context before you reach the codebase-impact step. Instead:

1. Fetch the raw changelog file and use grep to extract only sections matching the version range (e.g., grep -n "^## \[" CHANGELOG.md to find section line numbers, then read only that range).
2. Within the extracted range, focus on lines or subsections containing "breaking", "removed", "renamed", "dropped", "changed default", or "incompatible". Skip narrative paragraphs and new-feature prose.
3. Cross-reference with GitHub Releases for the major version tag — release notes often summarise breaking changes more concisely than the full changelog.

The goal is a targeted list of breaking changes and deprecations, not a comprehensive retelling of everything that changed.

Organize findings by importance:

1. Breaking changes — removed/renamed APIs, changed defaults, dropped Ruby/Rails version support. For each breaking change, check whether the codebase is affected and suggest a concrete fix if so.
2. Deprecations — still works now, will break later. Note what to watch for.
3. Security fixes — increases urgency to merge.
4. Notable bug fixes and new features — only mention if relevant to the codebase.

If you cannot find a changelog, say so explicitly.