dependabot-review
Dependabot PR Review
Triage, classify, and merge open Dependabot PRs with risk-based assessment.
Auto-Invoke Triggers
This skill activates when:
- Keywords: "dependabot", "dependabot PRs", "dependency updates", "merge dependabot", "review dependabot", "dependency PRs", "bump PRs", "update dependencies"
- 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 SKIPPEDfail— any check FAILUREpending— any check IN_PROGRESS or QUEUEDnone— 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(ornonefor lockfile-only changes) - Mergeable:
MERGEABLE - AND one of:
- Semver:
patch(any dependency) - Semver:
minorAND 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_actionsAND semver:minororpatch
- Semver:
Known-safe patterns (safe at minor):
@types/*— TypeScript type definitionseslint-*,prettier,@typescript-eslint/*— linters/formatters@testing-library/*,@playwright/test,vitest— test toolingactions/*,docker/*,hashicorp/*— CI actions (minor only)
REVIEW RECOMMENDED
- CI:
passAND mergeable:MERGEABLE - AND one of:
- Semver:
minorAND direct production dependency - Grouped PR with no major bumps
- Package on framework watchlist (even at minor)
- Semver:
Framework watchlist (always flag for review at minor+):
next,react,react-dom,svelte,vue,angularspring-boot,kotlin,gradlesupabase-js,@supabase/*mapbox-gl,framer-motion
REQUIRES HUMAN REVIEW
- Any
majorsemver 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):
- Ask for target branch: "What branch should these PRs target? (e.g., main, develop)"
- Skip if
--basewas provided
- Skip if
- Retarget if needed: For each PR where
baseRefNamediffers from the target:gh pr edit <number> --base <target-branch> - Approve and merge each safe PR:
If squash fails (repo doesn't allow squash):gh pr review <number> --approve --body "Auto-approved: safe dependency update" gh pr merge <number> --squash
If merge commits also fail:gh pr merge <number> --mergegh 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:
-
Missing secrets: Dependabot PRs run with read-only
GITHUB_TOKENand 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. -
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. -
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
- Triage is read-only by default — no merges happen unless the user explicitly requests it or uses
--merge-safe - Always ask for target branch before merging — never assume main or develop
- Grouped PRs: Parse the update table in the PR body to identify individual packages and their semver bumps
- Security PRs: Always surface these prominently regardless of semver level
@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
More from joaquimscosta/arkhe-claude-plugins
skill-validator
Validate skills against Anthropic best practices for frontmatter, structure, content, file organization, hooks, MCP, and security (62 rules in 8 categories). Use when creating new skills, updating existing skills, before publishing skills, reviewing skill quality, or when user mentions "validate skill", "check skill", "skill best practices", "skill review", or "lint skill".
30domain-driven-design
Expert guidance for Domain-Driven Design architecture and implementation. Use when designing complex business systems, defining bounded contexts, structuring domain models, choosing between modular monolith vs microservices, implementing aggregates/entities/value objects, or when users mention "DDD", "domain-driven design", "bounded context", "aggregate", "domain model", "ubiquitous language", "event storming", "context mapping", "domain events", "anemic domain model", strategic design, tactical patterns, or domain modeling. Helps make architectural decisions, identify subdomains, design aggregates, and avoid common DDD pitfalls.
26code-explanation
Explains complex code through clear narratives, visual diagrams, and step-by-step breakdowns. Use when user asks to explain code, understand algorithms, analyze design patterns, wants code walkthroughs, or mentions "explain this code", "how does this work", "code breakdown", or "understand this function".
22generating-changelog
Analyzes git commit history and generates professional changelogs with semantic versioning, conventional commit support, and multiple output formats (Keep a Changelog, Conventional, GitHub). Use when editing CHANGELOG.md, CHANGELOG.txt, or HISTORY.md files, preparing release notes, creating releases, bumping versions, updating changelog, documenting changes, writing release notes, tracking changes, version bump, tag release, or when user mentions "changelog", "release notes", "version history", "release", "semantic versioning", or "conventional commits".
21workflow-orchestration
>
19generating-stitch-screens
>
19