dependabot-pnpm
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/
- Such as
-
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:
# 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
- references/pnpm-dependencies.md - Dependency graph analysis
- references/resolution-strategies.md - Fix approaches and risk assessment
- assets/session-template.md - Session log template
- assets/setup-template.md - First-run setup template
More from jvgomg/skills
grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
10team-lead
Orchestrates large bodies of work (features, refactors, milestones, backlog tasks) using sub-agents as a team. Use this skill when the user explicitly asks you to "take responsibility", "orchestrate", "lead", or "team-lead" a set of tasks or a milestone. This is a manual-trigger skill — only activate when the user clearly invokes it.
5prd-to-tasks
Break a PRD into independently-grabbable Backlog tasks using tracer-bullet vertical slices. Use when user wants to convert a PRD to tasks, create implementation tickets, or break down a PRD into work items.
4write-a-prd
Create a PRD through user interview, codebase exploration, and module design, then store as a Backlog document. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.
4skill-creator
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
1split-expenses
>
1