Dependabot Review

Dependabot PR Review

Triage, classify, and merge open Dependabot PRs with risk-based assessment.

Auto-Invoke Triggers

This skill activates when:

1. Keywords: "dependabot", "dependabot PRs", "dependency updates", "merge dependabot", "review dependabot", "dependency PRs", "bump PRs", "update dependencies" 2. Command: /dependabot-review

---

Arguments

• (no args) — Triage mode: list all open Dependabot PRs with risk classification
• --merge-safe — Merge all PRs classified as SAFE TO MERGE (asks for target branch first)
• --pr <number> — Deep-dive analysis of a single Dependabot PR
• --base <branch> — Target branch for retargeting PRs before merge (skips the prompt)

---

Prerequisites

• GitHub CLI (gh) authenticated with repo access
• Repository must have open Dependabot PRs

Verify:

gh auth status

---

Workflow

Step 1: Fetch Open Dependabot PRs

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

If --pr <number> was provided, fetch that single PR instead:

gh pr view <number> \
  --json number,title,body,labels,headRefName,baseRefName,mergeable,isDraft,createdAt,statusCheckRollup,additions,deletions

If no Dependabot PRs are found, report "No open Dependabot PRs found" and stop.

Step 2: Enrich Each PR

For each PR, gather additional data:

Files changed (for lockfile-only detection):

gh pr diff <number> --name-only

CI status: Extract from statusCheckRollup in the JSON. Classify as:

• pass — all checks SUCCESS or SKIPPED
• fail — any check FAILURE
• pending — any check IN_PROGRESS or QUEUED
• none — no checks ran

Step 3: Classify Each PR

Apply the risk matrix to each PR:

Parse version info from PR title:

Dependabot titles follow: build(deps): bump <package> from <old> to <new> in <path>

For grouped updates: build(deps): bump the <group> group across N directory with M updates

Determine semver delta:

• Compare major versions: different → major
• Compare minor versions: different → minor
• Otherwise → patch
• Grouped PRs: check PR body for the update table; if any update is major → treat entire PR as major

Apply classification rules:

SAFE TO MERGE

All of these must be true:

• CI: pass (or none for lockfile-only changes)
• Mergeable: MERGEABLE
• AND one of:
• Semver: patch (any dependency)
• Semver: minor AND package matches known-safe pattern
• Files changed: lockfile only (*-lock.*, *.lock, pnpm-lock.yaml, package-lock.json, yarn.lock, Cargo.lock, gradle.lockfile)
• Ecosystem: github_actions AND semver: minor or patch

Known-safe patterns (safe at minor):

• @types/* — TypeScript type definitions
• eslint-*, prettier, @typescript-eslint/* — linters/formatters
• @testing-library/*, @playwright/test, vitest — test tooling
• actions/*, docker/*, hashicorp/* — CI actions (minor only)

REVIEW RECOMMENDED

• CI: pass AND mergeable: MERGEABLE
• AND one of:
• Semver: minor AND direct production dependency
• Grouped PR with no major bumps
• Package on framework watchlist (even at minor)

Framework watchlist (always flag for review at minor+):

• next, react, react-dom, svelte, vue, angular
• spring-boot, kotlin, gradle
• supabase-js, @supabase/*
• mapbox-gl, framer-motion

REQUIRES HUMAN REVIEW

• Any major semver bump
• Grouped PR containing any major bump

Security Override

Security-labeled PRs stay in their normal risk tier (a security patch is still SAFE, a security minor is still REVIEW, etc.) but are always flagged with an urgency callout at the top of the report. Security + major = HUMAN REVIEW.

BLOCKED

• CI: fail → note possible root causes (Dependabot lacks repo secrets, pre-existing failures)
• Mergeable: CONFLICTING → suggest @dependabot rebase
• Mergeable: UNKNOWN → suggest waiting for GitHub to compute

Step 4: Present Triage Report

Format the report as:

## Dependabot PR Triage — {owner}/{repo}
{N} open PRs found

### SAFE TO MERGE ({count})
| PR | Package | From → To | Type | Scope | CI | Files |
|----|---------|-----------|------|-------|----|-------|
| #142 | eslint | 8.56 → 8.57 | patch | dev | pass | lockfile |

### REVIEW RECOMMENDED ({count})
| PR | Package | From → To | Type | Reason | CI |
|----|---------|-----------|------|--------|----|
| #140 | next | 14.1 → 14.2 | minor | framework watchlist | pass |

### REQUIRES HUMAN REVIEW ({count})
| PR | Package | From → To | Type | Reason |
|----|---------|-----------|------|--------|
| #131 | spring-boot | 3.2 → 4.0 | major | major version bump |

### BLOCKED ({count})
| PR | Package | Issue | Suggested Action |
|----|---------|-------|-----------------|
| #129 | gradle | CI fail | Check Dependabot secrets / pre-existing lint errors |
| #127 | pnpm group | conflict | `@dependabot rebase` |

After the report, ask the user what they want to do using natural conversation.

Step 5: Execute Actions

If user chooses to merge safe PRs (or `--merge-safe` flag):

1. Ask for target branch: "What branch should these PRs target? (e.g., main, develop)"

• Skip if --base was provided

2. Retarget if needed: For each PR where baseRefName differs from the target:

   gh pr edit <number> --base <target-branch>

3. Approve and merge each safe PR:

   gh pr review <number> --approve --body "Auto-approved: safe dependency update"
   gh pr merge <number> --squash

If squash fails (repo doesn't allow squash):

   gh pr merge <number> --merge

If merge commits also fail:

   gh pr merge <number> --rebase

If user chooses to rebase conflicted PRs:

gh pr comment <number> --body "@dependabot rebase"

If user chooses single PR deep-dive (`--pr <number>`):

Present:

• Package name, old version → new version
• Semver classification and risk tier
• Release notes excerpt (from PR body)
• Files changed list
• CI check details (which passed, which failed)
• Recommendation with reasoning

Step 6: Summary

After all actions, present:

## Summary
- Merged: {N} PRs ({list numbers})
- Rebased: {N} PRs ({list numbers})
- Skipped: {N} PRs ({reasons})
- Remaining: {N} PRs requiring human review

---

CI Failure Diagnostics

When a Dependabot PR has failing CI, check these common causes before blaming the dependency update:

1. Missing secrets: Dependabot PRs run with read-only GITHUB_TOKEN and cannot access repo Actions secrets. Only Dependabot-specific secrets (Settings > Security > Dependabot secrets) are available. Look for errors like "Missing required environment variable" or auth failures.

2. Lockfile-only changes: If the PR only changes lockfiles (pnpm-lock.yaml, package-lock.json, etc.), it cannot cause lint, type-check, or build failures. Flag these as pre-existing issues.

3. Pre-existing failures: Check if the same CI checks fail on the base branch. If so, the failure is not caused by the dependency update.

---

Important Notes

1. Triage is read-only by default — no merges happen unless the user explicitly requests it or uses --merge-safe 2. Always ask for target branch before merging — never assume main or develop 3. Grouped PRs: Parse the update table in the PR body to identify individual packages and their semver bumps 4. Security PRs: Always surface these prominently regardless of semver level 5. `@dependabot rebase`: The preferred fix for lockfile conflicts — Dependabot regenerates the lockfile against the current base

---

Progressive Disclosure

For more details, see:

• WORKFLOW.md — Detailed 5-phase methodology
• EXAMPLES.md — Real-world triage scenarios
• TROUBLESHOOTING.md — Common issues and solutions

Version

1.0.0

Dependabot Review: Examples

Real-world scenarios showing the skill in action.

For quick start instructions, see SKILL.md. For detailed workflow, see WORKFLOW.md.

---

Example 1: Standard Triage with Mixed PRs

Scenario

A Next.js + Spring Boot monorepo has 5 open Dependabot PRs after a week away.

Command

/dependabot-review

Execution

Discovery: Fetches 5 PRs, enriches with file diffs and CI status.

Classification & Report:

## Dependabot PR Triage — deznode/nosilha
5 open PRs found

### SAFE TO MERGE (2)
| PR | Package | From -> To | Type | Scope | CI | Files |
|----|---------|-----------|------|-------|----|-------|
| #129 | undici | 7.22.0 -> 7.24.3 | patch | indirect | fail* | lockfile |
| #125 | actions group (13) | various | minor | actions | none | workflows |

*CI failure is pre-existing — lockfile-only changes cannot cause lint failures

### REVIEW RECOMMENDED (1)
| PR | Package | From -> To | Type | Reason | CI |
|----|---------|-----------|------|--------|----|
| #126 | npm group (39) | various | mixed | includes shiki 3->4 (major), framework minors | none |

### REQUIRES HUMAN REVIEW (1)
| PR | Package | From -> To | Type | Reason |
|----|---------|-----------|------|--------|
| #102 | hashicorp/google | 6.39.0 -> 7.23.0 | major | Terraform provider major version |

### BLOCKED (1)
| PR | Package | Issue | Action |
|----|---------|-------|--------|
| #127 | gradle group (10) | conflict | `@dependabot rebase` |

User chooses: "Merge the 2 safe ones to develop"

Actions:

What branch should these PRs target? develop

Retargeting #129 from main -> develop... done
Retargeting #125 from main -> develop... done
Merging #129 (undici 7.22->7.24.3)... merged
Merging #125 (actions group)... merged

## Summary
- Merged: 2 PRs (#129, #125)
- Remaining: 3 PRs (1 review, 1 human review, 1 blocked)

---

Example 2: Security Update Expedited

Scenario

A critical security vulnerability is reported in a transitive dependency.

Command

/dependabot-review

Report

## Dependabot PR Triage — myorg/myapp
3 open PRs found

### SAFE TO MERGE (2)
| PR | Package | From -> To | Type | Scope | CI |
|----|---------|-----------|------|-------|----|
| #45 | lodash | 4.17.20 -> 4.17.21 | patch | direct:prod | pass |
| #44 | @types/node | 20.11 -> 20.12 | minor | dev | pass |

> **SECURITY**: #45 (lodash) has the `security` label — prototype pollution fix (CVE-2024-XXXX)

### REVIEW RECOMMENDED (1)
| PR | Package | From -> To | Type | Reason | CI |
|----|---------|-----------|------|--------|----|
| #43 | express | 4.18 -> 4.19 | minor | framework | pass |

Key Takeaway

Security PRs are always surfaced prominently with a callout, even when they fall into the SAFE tier. The skill highlights the CVE context from the PR body.

---

Example 3: Grouped PR with Major Bump

Scenario

Dependabot groups npm dependencies. One package in the group has a major bump.

Command

/dependabot-review --pr 126

Deep-Dive Output

## PR #126: bump the dependencies group (39 updates)

### Package Breakdown
| Package | From | To | Semver | Risk |
|---------|------|----|--------|------|
| @next/third-parties | 16.0.3 | 16.1.6 | minor | framework |
| shiki | 3.20.0 | 4.0.2 | MAJOR | breaking |
| react | 19.2.0 | 19.2.4 | patch | safe |
| framer-motion | 12.23.26 | 12.36.0 | minor | framework |
| zod | 4.2.1 | 4.3.6 | minor | safe |
| ... (34 more) | | | | |

### Risk Assessment: REQUIRES HUMAN REVIEW
- Contains 1 major bump: shiki 3 -> 4
- Contains 5 framework minors: next, react, framer-motion, supabase-js, mapbox-gl
- 39 total updates — large blast radius

### Recommendation
Do NOT auto-merge. The shiki 3->4 major bump likely has breaking API changes.

Options:
1. **Wait for Dependabot to split**: Close this PR, configure Dependabot to separate major updates
2. **Merge and fix**: Merge to a feature branch, resolve any shiki breaking changes
3. **Comment `@dependabot recreate`**: Force Dependabot to regenerate without the major bump (may not work for grouped updates)

### Files Changed
- apps/web/package.json (39 additions, 39 deletions)

### CI Status
No checks ran (grouped PRs often lack CI due to base branch conflicts)

---

Example 4: CI Failure from Missing Secrets

Scenario

A Dependabot PR fails CI, but the dependency change is trivial.

Command

/dependabot-review

Report (BLOCKED section)

### BLOCKED (1)
| PR | Package | Issue | Action |
|----|---------|-------|--------|
| #88 | undici | 7.22 -> 7.24 | CI fail |

#### CI Failure Diagnosis for #88:
- Files changed: `pnpm-lock.yaml` (lockfile only)
- Failed checks: "Lint & Type Check", "Bundle Size Analysis"
- Error: `Missing required environment variable: NEXT_PUBLIC_MAPBOX_ACCESS_TOKEN`

**Diagnosis**: Dependabot PRs cannot access repository Actions secrets.
The lockfile-only change cannot cause lint or build failures.
These failures are pre-existing on the base branch.

**Recommendation**: Safe to merge despite CI failures. Use `--merge-safe` or
merge manually with `gh pr merge 88 --squash --admin`.

Key Takeaway

The skill distinguishes between CI failures caused by the dependency update vs pre-existing issues or Dependabot secret limitations.

---

Common Patterns

1. Lockfile-only PRs: Almost always safe — the actual dependency versions are controlled by the manifest file, and lockfile changes just pin transitive dependencies 2. Grouped PRs: Check every package in the group — one major bump contaminates the entire PR 3. GitHub Actions: Minor bumps are safe (they use major version tags); major bumps need workflow syntax review 4. Terraform providers: Major bumps are high risk — always run terraform plan before merging 5. Security PRs: Merge quickly — they exist because a vulnerability was found

Dependabot Review: Troubleshooting

Solutions to common issues when using the dependabot-review skill.

For quick start instructions, see SKILL.md. For detailed workflow, see WORKFLOW.md. For examples, see EXAMPLES.md.

---

Common Issues

Issue 1: CI Fails on All Dependabot PRs

Symptom: Every Dependabot PR shows CI failures, even trivial patches.

Cause: Dependabot PRs run with a read-only GITHUB_TOKEN and cannot access repository Actions secrets. Any workflow step that requires secrets (API keys, deploy tokens, private registry auth) will fail.

Solutions:

Solution A: Add Dependabot-specific secrets

Go to Settings > Security > Dependabot secrets and add the required env vars there. These are separate from Actions secrets.

Solution B: Skip steps for Dependabot

In your workflow, conditionally skip steps that need secrets:

- name: Deploy
  if: github.actor != 'dependabot[bot]'
  run: ...

Solution C: Merge despite failures

If the failure is clearly unrelated (lockfile-only change, missing env var error), the skill will flag it as pre-existing and the PR can be merged with --admin flag:

gh pr merge <number> --squash --admin

---

Issue 2: Merge Conflicts on Lock Files

Symptom: PR shows CONFLICTING status. Common when multiple Dependabot PRs are open simultaneously.

Cause: Multiple PRs touch the same lockfile. After merging one, the others conflict.

Solutions:

Solution A: Rebase via Dependabot

gh pr comment <number> --body "@dependabot rebase"

Dependabot will regenerate the lockfile against the current base branch within a few minutes.

Solution B: Batch merge order

Merge PRs one at a time, rebasing conflicted ones after each merge. The skill handles this automatically when using --merge-safe.

---

Issue 3: --squash Not Allowed on Repository

Symptom: gh pr merge --squash fails with "Squash merges are not allowed on this repository".

Cause: Repository settings only allow certain merge strategies.

Solution: The skill automatically falls back: 1. Try --squash 2. If fails, try --merge 3. If fails, try --rebase

If all fail, check repo settings: Settings > Pull Requests > Allow merge commits / squash / rebase.

---

Issue 4: PRs Targeting Wrong Base Branch

Symptom: Dependabot PRs target main but you want them on develop.

Cause: Dependabot defaults to the repo's default branch. The dependabot.yml config can override this with target-branch.

Solutions:

Solution A: Retarget in the skill

The skill asks for the target branch before merging and retargets automatically:

gh pr edit <number> --base develop

Solution B: Configure Dependabot

Update .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/apps/web"
    schedule:
      interval: "weekly"
    target-branch: "develop"

---

Issue 5: Grouped PR Contains Unexpected Packages

Symptom: A grouped Dependabot PR includes packages you didn't expect, or is missing packages from the group.

Cause: Known Dependabot issue with grouped updates (#10487). Group membership can be inconsistent.

Solutions:

Solution A: Recreate the PR

gh pr comment <number> --body "@dependabot recreate"

Solution B: Review individual packages

Use --pr <number> mode to see the full package breakdown and assess each update individually.

---

Issue 6: gh CLI Not Authenticated

Symptom: All commands fail with authentication errors.

Solution:

gh auth status
gh auth login

Ensure the token has repo scope for private repositories.

---

Issue 7: No Dependabot PRs Found

Symptom: Skill reports "No open Dependabot PRs found" but you expected some.

Causes:

• Dependabot is not enabled: Check Settings > Security > Code security > Dependabot
• PRs were auto-closed: Dependabot closes PRs after 30 days of inactivity
• Wrong repository: Verify you're in the correct repo with gh repo view

Verification:

gh pr list --author "app/dependabot" --state all --limit 10

This shows both open and closed Dependabot PRs to confirm whether any were created.

---

Dependabot Comment Commands Reference

These commands can be posted as PR comments to control Dependabot:

---

Getting Help

• GitHub Dependabot docs
• GitHub CLI docs
• File issues at the plugin repository

Dependabot Review: Detailed Workflow

This document provides a detailed step-by-step breakdown of the Dependabot PR triage and merge process.

For quick start instructions, see SKILL.md.

Overview

The review follows 5 phases:

1. Discovery — Fetch PRs, parse metadata, detect ecosystems 2. Classification — Apply risk matrix to each PR 3. Presentation — Structured triage report 4. Action — Merge, rebase, or skip per user choice 5. Summary — Report actions taken

---

Phase 1: Discovery

Fetching PRs

Use gh pr list --author "app/dependabot" to get all open Dependabot PRs. The key JSON fields:

Parsing Version Info

Single package PRs — title format:

build(deps): bump <package> from <old> to <new> in <path>
build(deps-dev): bump <package> from <old> to <new> in <path>

The deps-dev prefix indicates a development dependency.

Grouped PRs — title format:

build(deps): bump the <group> group across N directory with M updates

For grouped PRs, parse the markdown table in the PR body:

| Package | From | To |
| --- | --- | --- |
| [package-name](url) | `1.0.0` | `2.0.0` |

Detecting Ecosystems

Parse from headRefName:

• dependabot/npm_and_yarn/... → npm/yarn
• dependabot/gradle/... → Gradle/JVM
• dependabot/github_actions/... → GitHub Actions
• dependabot/terraform/... → Terraform
• dependabot/docker/... → Docker
• dependabot/pip/... → Python pip

Files Changed Analysis

Run gh pr diff <number> --name-only per PR. Key patterns:

• Lockfile only: pnpm-lock.yaml, package-lock.json, yarn.lock, gradle.lockfile, Cargo.lock — lowest risk
• Manifest + lockfile: package.json + lockfile — normal dependency update
• Source code: .ts, .kt, .java, .py files changed — unusual for Dependabot, flag for review
• Workflow files: .github/workflows/*.yml — GitHub Actions updates

---

Phase 2: Classification

Risk Matrix

Override Rules

These override the standard matrix:

1. Security label → PR stays in its normal tier but gets an urgency callout at the top of the report 2. CI failing → BLOCKED (never merge) 3. Merge conflict → BLOCKED (suggest rebase) 4. Lockfile-only → SAFE (regardless of semver, since the actual dependency version is controlled by the manifest) 5. Grouped PR with any major → HUMAN REVIEW (entire PR contaminated)

Known-Safe Packages

These packages are safe to merge at minor level:

• Type definitions: @types/*
• Linting: eslint, eslint-*, prettier, @typescript-eslint/*, ktlint
• Testing: @testing-library/*, @playwright/test, vitest, jest, mockito-*
• CI: actions/*, docker/*, hashicorp/setup-*, aquasecurity/trivy-action

Framework Watchlist

Always flag for review even at minor:

• Frontend: next, react, react-dom, svelte, vue, angular, framer-motion
• Backend: spring-boot, kotlin, gradle, quarkus
• Data: supabase-js, @supabase/*, prisma, drizzle-orm
• Maps: mapbox-gl, react-map-gl

---

Phase 3: Presentation

Report Structure

Present PRs grouped by tier with the most actionable information visible:

1. SAFE TO MERGE — ready to merge now, one command away 2. REVIEW RECOMMENDED — likely fine but deserves a glance 3. REQUIRES HUMAN REVIEW — major bumps, breaking changes possible 4. BLOCKED — can't merge until CI/conflicts resolved

Within each tier, sort by: 1. Security PRs first 2. Then by age (oldest first — most likely to accumulate conflicts)

CI Failure Context

When presenting BLOCKED PRs with CI failures, include diagnostic notes:

• If only lockfile changed: "CI failure is pre-existing — lockfile changes cannot cause lint/type/build failures"
• If error mentions env vars: "Dependabot PRs lack access to repo secrets — this is expected"
• If same check fails on base branch: "Same CI failure exists on base branch — not caused by this PR"

---

Phase 4: Action

Merge Flow

1. Ask user for target branch (always) 2. Retarget PRs if needed (gh pr edit --base) 3. Approve each PR (gh pr review --approve) 4. Merge with squash strategy (gh pr merge --squash) 5. Handle merge method failures gracefully (try squash → merge → rebase)

Rebase Flow

For conflicted PRs:

gh pr comment <number> --body "@dependabot rebase"

This tells Dependabot to regenerate the PR against the current base. The PR will update within a few minutes.

Skip Flow

For REVIEW RECOMMENDED and HUMAN REVIEW tiers, present the recommendation but take no action unless explicitly asked.

---

Phase 5: Summary

Report all actions taken in a structured format:

• PRs merged (with numbers and package names)
• PRs rebased (with numbers)
• PRs skipped (with reasons)
• PRs still requiring attention