| name | dependabot-pr-review |
| description | Use for Dependabot PRs, dependency bumps, Gradle or Maven dependency updates, GitHub Actions updates, dependency changelog/licence/release-note review, JVM/classfile checks, and validation recommendations. |
Dependabot PR Review
Use this skill when reviewing dependency or workflow version updates. Keep the review evidence-based, scoped to the changed dependency, and explicit about what must be checked before merge.
Cross-load related skills
- Use
integration-test-verification for integration-test matrix selection, compact failure triage, Kotest registration, or any full integration log hand-off.
- Use
compatibility-strategy for Java 8, Bukkit/Paper/Spigot, NMS/reflection, PacketEvents, fake-player, or API compatibility concerns.
- Use
release-readiness-review for licence, shaded dependency, release-note, publishing, or asset-impact questions.
Review workflow
- Identify the update manager, dependency scope, touched files, and whether the dependency is production, compile-only, test-only, integration-test-only, or GitHub Actions.
- Read the PR diff and the upstream release notes, changelog, migration guide, and security notes for every updated version range.
- Check licence changes and whether the dependency ships in the release jar, shaded jar, or integration-test jar.
- Check JVM bytecode, classfile version, toolchain, and Gradle module metadata against main Java 8 support and the integration-test Java bands.
- Check Bukkit/Paper/Spigot compatibility when the dependency is server-facing, API-adjacent, PacketEvents-adjacent, or affects plugin loading.
- Check shading, relocation, service files, transitive dependency, and duplicate class risks, especially for anything bundled into the plugin jar.
- For GitHub Actions bumps, check Node/runtime changes, runner image requirements, permission model changes, and deprecated input/output behaviour.
- Inspect CI status and rerun the narrowest relevant validation where appropriate; prefer static checks for documentation-only or metadata-only bumps.
- Root and user-facing agents must not open
build/integration-test-logs/*.log directly. If compact summaries are insufficient, delegate full integration log inspection to a subagent.
Validation expectations
- Do not skip, weaken, disable, or version-gate tests to make a dependency update pass.
- Match validation to risk: build metadata can often use wrapper/config checks; runtime libraries may need unit or integration tests; server-facing changes may need selected Paper matrix runs.
- Prefer checking the produced dependency graph or shaded jar contents when packaging impact is plausible.
Verdicts
merge: low-risk update, relevant notes reviewed, CI/validation is green, and no follow-up is needed.merge after checks: likely safe, but wait for named CI jobs, dependency graph checks, or narrow validation.hold: compatibility, licence, packaging, JVM, server API, or validation concerns need investigation or code changes.close/ignore: update is incompatible, not useful for this branch, duplicates another update, or should be deferred by policy.
Review output template
### Dependency review
- Scope: production / compile-only / test-only / integration-test-only / GitHub Actions
- Release notes checked:
- Licence/packaging impact:
- JVM and server compatibility:
- Shading/duplicate class risk:
- Validation:
- Verdict: merge / merge after checks / hold / close/ignore
