From agent-skills
Structured triage procedure for automated dependency-bump PRs (Dependabot, Renovate, or similar). Covers batching strategy, AI-reviewer false-positive handling, registry verification, and safe merge sequencing. Use when the user says "triage my dependency PRs", "Dependabot PRs are piling up", "Renovate opened 20 PRs", "should I merge these dep bumps", "AI reviewer flagged this version as nonexistent", "npm audit is giving me noise", "safe to merge minor dependency updates", "how do I handle major version bumps", "batch dependency updates", or "dependency PR queue".
How this skill is triggered — by the user, by Claude, or both
Slash command
/agent-skills:deps-pr-triageThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Automated dependency bots generate volume. Merging blindly causes breakage; ignoring indefinitely creates real security debt. The procedure below drains the queue systematically — without merging anything you haven't verified and without being paralyzed by AI reviewer false positives.
Automated dependency bots generate volume. Merging blindly causes breakage; ignoring indefinitely creates real security debt. The procedure below drains the queue systematically — without merging anything you haven't verified and without being paralyzed by AI reviewer false positives.
Classify every open dependency PR into one of three tracks before touching any of them:
| Track | Criteria | Merge posture |
|---|---|---|
| Patch | Semver patch bump (x.y.Z) | Merge after CI green; no manual review needed |
| Minor | Semver minor bump (x.Y.0) | Merge after CI green; skim changelog for breaking notes |
| Major | Semver major bump (X.0.0) | Hold for a dedicated upgrade session; never merge in a batch |
Group all patches into one merge wave, all minors into a second wave, and never mix majors into either.
If an AI code reviewer comments that "this version doesn't exist" or "I cannot find version X.Y.Z in the registry":
Treat this as a near-certain false positive. AI reviewers have a training data cutoff. Packages release constantly. A reviewer trained months ago will flag versions that exist today.
Verify the tag directly against the registry before acting:
# npm / Node.js ecosystem
npm view PACKAGE-NAME@VERSION version
# Returns the version string if it exists; error if it does not
# Alternative: check npmjs.com directly
curl -s https://registry.npmjs.org/PACKAGE-NAME/VERSION | jq '.version // "NOT FOUND"'
# Python / PyPI
curl -s https://pypi.org/pypi/PACKAGE-NAME/VERSION/json | jq '.info.version // "NOT FOUND"'
# Ruby / RubyGems
curl -s https://rubygems.org/api/v2/rubygems/PACKAGE-NAME/versions/VERSION.json | jq '.version // "NOT FOUND"'
If the registry confirms the version exists: dismiss the reviewer's comment as a false positive. Merge if CI is green. Do not open a follow-up issue for a false positive — it creates noise.
If the registry cannot find the version: the bump PR itself is malformed. Do not merge. Flag the dependency bot configuration or the PR source for investigation.
npm audit --omit=dev in npm 10 is unreliable — devDependency vulnerabilities can still surface even with that flag, producing noise in CI.
Use a lockfile-based filter instead:
# Get the full audit JSON
npm audit --json > /tmp/audit-full.json
# Filter to production-only packages using the lockfile dev flag
node - <<'EOF'
const audit = JSON.parse(require('fs').readFileSync('/tmp/audit-full.json', 'utf8'));
const lock = JSON.parse(require('fs').readFileSync('package-lock.json', 'utf8'));
const devPkgs = new Set(
Object.entries(lock.packages || {})
.filter(([, meta]) => meta.dev)
.map(([name]) => name.replace(/^node_modules\//, ''))
);
const prodVulns = Object.entries(audit.vulnerabilities || {})
.filter(([name]) => !devPkgs.has(name));
if (prodVulns.length === 0) {
console.log('No production vulnerabilities found.');
} else {
prodVulns.forEach(([name, v]) => console.log(`${name}: ${v.severity} — ${v.via?.[0]?.title ?? 'see npm audit'}`));
}
EOF
Only act on vulnerabilities the script surfaces. DevDependency vulnerabilities are a code quality concern, not a production security concern.
Merge one wave at a time, waiting for CI to complete between waves:
Major bumps break builds at an unpredictable frequency and should never be merged in a batch wave:
@types/*) track engine majors and break APIs.Schedule a dedicated upgrade session per major dependency. Treat it as a feature, not a maintenance task.
| Failure | What happens | Fix |
|---|---|---|
| Acting on AI reviewer version claim | Version exists; you reject a valid bump or file a bogus issue | Always verify via registry API before acting |
Using npm audit --omit=dev for prod security decisions | DevDep vulns still appear; CI fails on non-issues | Use the lockfile-based filter in step 3 |
| Batch-merging through an automated gate | Stacked PRs can lose content if the gate advances without them (see sequential-merge-discipline skill) | Merge sequentially; verify tip between merges |
| Merging a major in a patch wave | Build breaks on a Friday | Sort by semver track in step 1; never merge majors in waves |
| Skipping changelog review on a minor | Minor contained a breaking note in the release | Skim the changelog for "BREAKING", "deprecated", or "removed" before merging minor bumps |
--omit=dev)npx claudepluginhub sathiaai/claude-kickoff-playbook --plugin agent-skillsProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.