| name | dependabot-pnpm |
| description | Resolve Dependabot security alerts in pnpm projects. Use when asked to fix, resolve, or work through Dependabot alerts, security vulnerabilities, or dependency security issues. Handles fetching alerts via gh api, analyzing dependency chains, applying fixes (direct updates or pnpm overrides), and maintaining a decision log. Works autonomously through batches of alerts, asking for input only when necessary. |
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:
-
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
-
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/
-
Ask user to confirm locations before creating any files. Present your recommendation and wait for approval.
-
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
-
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:
pnpm why <package-name>
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
pnpm typecheck
pnpm lint
pnpm test
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>
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:
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