dependabot-pnpm

Installation
SKILL.md

Dependabot pnpm Resolver

Autonomously resolve Dependabot security alerts in pnpm projects by analyzing dependency chains, applying appropriate fixes, and documenting decisions.

Workflow Overview

1. Check setup     → First run? Configure the repo
2. Fetch alerts    → Get open alerts via gh api
3. Plan            → Group by fix, prioritize by severity
4. Baseline        → Run install, build, typecheck, lint, test
5. Execute fixes   → Apply fixes, validate each with install
6. Final validate  → Confirm baseline still passes
7. Log & report    → Document decisions, report issues

First-Run Setup

On first use in a repo, check if setup exists by looking for a dependabot workflow include in CLAUDE.md or AGENTS.md.

If no setup exists:

  1. Analyze the repo structure:

    • Package manager (confirm pnpm)
    • Monorepo/workspace? (check for pnpm-workspace.yaml, turborepo.json)
    • Dependency tools? (manypkg, syncpack, sherif, nx)
    • Existing documentation structure
  2. Recommend setup and log locations:

    IMPORTANT: Never use hidden directories (.claude/, .agents/, .github/, etc.) or tool-specific directories. These are for tool configuration, not project documentation.

    Look for existing visible documentation and agent instruction directories:

    • Such as docs/workflows/, docs/agents/, docs/decisions/, docs/adr/, docs/, agents/, logs/
    • Default to docs/ if no suitable locations can be found

    Recommended placement:

    • Setup file: docs/dependabot-setup.md
    • Session logs: docs/dependabot-log/

    If repo has more specific docs structures (e.g., docs/workflows/, logs/), adapt accordingly:

    • Setup file: docs/workflows/dependabot-setup.md
    • Session logs: logs/dependabot/
  3. Ask user to confirm locations before creating any files. Present your recommendation and wait for approval.

  4. Create setup file using assets/setup-template.md:

    • Document repo configuration (monorepo, workspace root, dependency tools)
    • List validation commands available in package.json
    • Note dependency tool constraints
    • Record the chosen log directory location
  5. Add include to CLAUDE.md or AGENTS.md:

    @./<path-to-setup-file>
    

Main Workflow

1. Fetch Alerts

gh api '/repos/{owner}/{repo}/dependabot/alerts?state=open' --jq '.[] | {number, state, severity: .security_advisory.severity, package: .security_vulnerability.package.name, vulnerable_versions: .security_vulnerability.vulnerable_version_range, patched_versions: .security_vulnerability.first_patched_version.identifier}'

For each alert, also fetch the full details:

gh api '/repos/{owner}/{repo}/dependabot/alerts/{alert_number}'

2. Plan the Batch

Group alerts by resolution strategy:

Priority Strategy Criteria
1 Direct update Direct dep, patch/minor available
2 Override Transitive dep, fix available
3 Flag for user Major version required
4 Recommend dismiss No fix available

Grouping: Multiple alerts for the same package = single fix. Document all alert numbers together.

Batch size: If >10 alerts, confirm approach with user before proceeding.

3. Analyze Each Alert

For each alert, determine the dependency chain:

# Single-package repo
pnpm why <package-name>

# Monorepo/workspace - use -r to check all packages
pnpm -r why <package-name>

Document in session log:

  • Alert number(s)
  • Vulnerability description
  • Dependency chain (full path from root)
  • Dev vs production dependency
  • Actual risk assessment (is vulnerable code path used?)

See references/pnpm-dependencies.md for dependency analysis commands.

4. Establish Baseline

Before making changes, verify the repo builds:

pnpm install
pnpm build        # or equivalent from package.json
pnpm typecheck    # if available
pnpm lint         # if available
pnpm test         # if available

If baseline fails, stop and report. Do not proceed with Dependabot fixes on a broken build.

5. Apply Fixes

See references/resolution-strategies.md for detailed strategies.

For direct dependencies:

pnpm update <package>
# or for specific version:
pnpm add <package>@<version>

For transitive dependencies, add override to root package.json:

{
  "pnpm": {
    "overrides": {
      "<package>": ">=<patched-version>"
    }
  }
}

Then run:

pnpm install

Per-fix validation: After each fix, confirm pnpm install succeeds.

6. Final Validation

After all fixes applied:

pnpm install
pnpm build
pnpm typecheck
pnpm lint
pnpm test

If any fail, investigate which fix caused the issue.

7. Document Session

Create a dated session log in the configured directory using assets/session-template.md.

Example: docs/dependabot-log/2026-02-11.md

Include:

  • Summary table of all alerts processed
  • Detailed analysis and decisions for each
  • Session notes (baseline status, issues encountered)

User Interaction Guidelines

Work autonomously - complete as much as possible without interruption.

Always ask for confirmation:

  • First-run setup: Present recommended file locations and wait for user approval before creating files

Ask at START only if:

  • Large number of alerts (>10) - confirm batch approach
  • Repo uses npm/yarn instead of pnpm - different override syntax

Report at END:

  • Alerts successfully resolved
  • All unresolved alerts with their GitHub URLs - regardless of reason (no fix available, major version required, broke the build, needs investigation, etc.)
  • For each unresolved alert, explain why it couldn't be resolved and offer to investigate further if directed

Always provide clickable URLs for any alert that wasn't fully resolved. Get the repo info from gh repo view --json owner,name and construct real URLs:

# Example for alert #27 in username/repo:
https://github.com/username/repo/security/dependabot/27

IMPORTANT: Never output template placeholders like {owner} or {repo} - always use the actual repository owner and name.

Never auto-dismiss. Only the user should dismiss alerts via the GitHub UI.

Monorepo Considerations

In pnpm workspaces:

  • Overrides in root package.json apply to all workspace packages
  • Check dependency chains in all workspaces: pnpm -r why <package>
  • One override can fix the same vulnerability across multiple packages

If using dependency tools (manypkg, syncpack, sherif):

  • These may enforce version consistency rules
  • Check their config before adding overrides
  • Run their validation after changes

Resources

Related skills
Installs
1
Repository
jvgomg/skills
GitHub Stars
3
First Seen
Mar 21, 2026