Skill4.9k repo starsupdated 5d ago

dependabot

This Claude Code skill retrieves all open Dependabot security alerts for a repository and generates a resolution plan by grouping them by manifest file type (bun.lock, pnpm-lock.yaml, package-lock.json, yarn.lock, or Cargo.lock), then recommends the appropriate package manager override mechanism (overrides in package.json for npm/bun, pnpm overrides in workspace root, resolutions for Yarn, or cargo update/patch for Rust). Use this when your repository has multiple package managers or lockfiles and needs a coordinated approach to resolving dependency vulnerabilities across different ecosystems.

View source Repository: macro

Install in Claude Code

Copy

git clone --depth 1 https://github.com/macro-inc/macro /tmp/dependabot && cp -r /tmp/dependabot/.claude/skills/dependabot ~/.claude/skills/dependabot

Then start a new Claude Code session; the skill loads automatically.

Definition

skill.md

# Dependabot Alert Resolution

## Step 1: Fetch all open alerts

```bash
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
gh api "repos/${REPO}/dependabot/alerts" \
  --jq '.[] | select(.state == "open") | {
    number,
    dependency: .dependency.package.name,
    ecosystem: .dependency.package.ecosystem,
    manifest: .dependency.manifest_path,
    vulnerable_range: .security_vulnerability.vulnerable_version_range,
    patched_version: .security_vulnerability.first_patched_version.identifier,
    severity: .security_vulnerability.severity,
    summary: .security_advisory.summary
  }'
```

## Step 2: Group alerts by manifest/lockfile

Group the alerts by their `manifest` field (e.g. `bun.lock`, `Cargo.lock`, `packages/loro-mirror/pnpm-lock.yaml`). This determines which override mechanism to use.

## Step 3: Determine override strategy per manifest

For each manifest/lockfile, determine the correct override mechanism:

| Lockfile | Override mechanism |
|----------|-------------------|
| `bun.lock` / `bun.lockb` | `"overrides"` in the nearest `package.json` |
| `pnpm-lock.yaml` | `"pnpm": { "overrides": { ... } }` in the workspace root `package.json` |
| `package-lock.json` | `"overrides"` in the nearest `package.json` |
| `yarn.lock` | `"resolutions"` in the nearest `package.json` |
| `Cargo.lock` | `cargo update -p <package>` or workspace `[patch.crates-io]` in `Cargo.toml` |

Read each target `package.json` or `Cargo.toml` to check for existing overrides before adding new ones.

## Step 4: Present the plan

Present a table of all alerts grouped by manifest, showing:
- Alert numbers
- Package name
- Current version (from lockfile)
- Patched version
- Severity
- Override mechanism to use

Ask the user to confirm before making changes.

## Step 5: Apply fixes

For each group:

### npm/bun/pnpm overrides
- Add override entries to the appropriate `package.json`
- Reinstall: `bun install` / `pnpm install` / `npm install`
- Verify: check the lockfile or `<pm> ls` for the patched version

### Cargo
- Try `cargo update -p <package>` first
- If that doesn't reach the patched version, also try `cargo update -p <parent-package>` (the package that depends on the vulnerable one, found via `cargo tree -i <package>`)
- Verify with `cargo tree -i <package>` and checking `Cargo.lock`

## Step 6: Verify

After all changes, confirm patched versions are in place and no new audit issues were introduced.

## Notes

- Some alerts may be false positives (e.g. `undici-types` triggering `undici` alerts). Flag these to the user.
- Prefer minimal version bumps (e.g. `>=6.14.0` not `^8.0.0`) to reduce breakage risk.
- If a `cargo update` only bumps to a version below the patch, escalate the parent dependency.