Load this skill when asked to review, analyze, assess, or verify a Dependabot PR.
Goal
Give the reviewer a clear answer to: does this version bump require any action beyond merging?
Process
1. Identify the packages being bumped
gh pr view <PR_NUMBER> --repo cloudflare/cloudflare-docs --json title,body
Parse the PR body to extract package name(s) and version range (old → new). Dependabot PRs always include this in structured form.
For grouped PRs, there will be multiple packages. Process each one.
2. Fetch the changelog / release notes for each package
Check in this order — stop at the first that works:
- GitHub releases —
gh release list --repo <upstream-repo> then gh release view <tag>
- CHANGELOG.md in the repo —
gh api repos/<upstream>/contents/CHANGELOG.md (decode base64)
- npm changelog —
npm view <package>@<new-version> changelog or the registry page
- Commit diff — if no changelog exists, diff the tag range:
gh api repos/<upstream>/compare/<old-tag>...<new-tag> --jq '.commits[].commit.message'
Focus only on the commits/entries between old and new version. Ignore unrelated history.
3. Extract what changed
From the changelog/diff, identify:
- Breaking changes — removed or renamed exports, changed function signatures, dropped Node/browser support
- Behavior changes — anything that alters output, side effects, or defaults
- New APIs — new exports, methods, or options (usually irrelevant unless we start using them)
- Bug fixes — especially if they fix incorrect output we might depend on
- Security fixes — note the CVE/GHSA ID and what it affects
Ignore: internal refactors, CI changes, test changes, type-only changes that don't affect emitted JS.
4. Determine how this repo uses the package
Run these searches against the local codebase. Do not skip this step.
# Direct import anywhere in source
grep -r "from ['\"]<package>['\"]" src/ worker/ bin/ --include="*.ts" --include="*.tsx" --include="*.mjs" --include="*.js" --include="*.astro" -l
# require() usage
grep -r "require(['\"]<package>['\"]" src/ worker/ bin/ -l
# Is it a direct or transitive dependency?
grep '"<package>"' package.json
# If transitive, who pulls it in?
node -e "const lock = require('./pnpm-lock.yaml'); ..."
# or just:
grep -A2 '"<package>"' pnpm-lock.yaml | grep -v "^--$" | head -20
If the package is not directly imported anywhere, it is transitive. Identify which direct dependency pulls it in by checking pnpm-lock.yaml.
5. Map usage to doc pages
If the package is directly imported, find which source files use the specific APIs that changed:
# For each changed method/export, search for callsites
grep -r "<method_name>\|<export_name>" src/ worker/ bin/ --include="*.ts" --include="*.tsx" --include="*.astro" -l
For Astro/MDX source files under src/content/docs/, map them to their route:
src/content/docs/workers/get-started/index.mdx → /workers/get-started/src/content/docs/pages/platform/limits.mdx → /pages/platform/limits/
If more than ~5 files use the changed API, list a representative sample (pick the most prominent product areas).
6. Assess impact
Rate the probability that this bump causes a visible change to the docs site:
| Rating | Meaning |
|---|
| None | Package not used directly; transitive only; or only internal/type changes |
| Very Low | Direct dependency, but changed APIs are not called in this repo |
| Low | Changed APIs are called, but only in build tooling (not runtime or content rendering) |
| Medium | Changed APIs affect content rendering (Astro components, MDX processing, syntax highlighting) |
| High | Changed APIs affect output seen by users — rendered HTML, search index, Worker behavior |
For security fixes: note what the vulnerability affects and whether our usage is in the vulnerable code path.
Output format
## <package-name>: <old-version> → <new-version>
**Type of update:** [security fix | bug fix | feature | breaking change]
**Dependency type:** [direct | transitive (pulled in by <package>)]
### What changed
- <bullet: specific API/behavior change>
- <bullet: ...>
### Usage in this repo
<"Not used directly — transitive only" OR list of files/callsites>
### Affected doc pages (sample)
- `/product/section/page/` — uses `<method>`
- (none)
### Impact rating: <None | Very Low | Low | Medium | High>
<1–2 sentence explanation of the rating>
If the PR bumps multiple packages, repeat the block for each. End with a one-line recommendation:
- Merge — no action needed
- Merge + verify — merge, then spot-check the listed pages
- Investigate before merging — high-impact change, needs manual testing
Special cases
Security PRs opened outside the schedule
Dependabot opens security PRs immediately, regardless of dependabot.yml schedule. This is expected. The schedule.day setting only applies to version updates.
Security PRs are also not grouped with other packages — each gets its own PR. This is also expected GitHub behavior.
Grouped PRs
For grouped PRs (non-major group), the PR body lists each package separately. Process each package independently through steps 2–6, then give a combined recommendation.
Packages with no public changelog
If a package has no changelog and the upstream repo is private or unavailable:
- Check npm for version diff:
npm diff <package>@<old> <package>@<new>
- If that also fails, note it explicitly and rate impact conservatively based on usage alone.