Fix a Snyk vulnerability PR by regenerating the pnpm lockfile, checking changelogs for breaking changes, and posting findings as a PR comment. Use when asked to fix a vulnerability PR or handle a Snyk dependency upgrade.
Process a Snyk (or similar) dependency upgrade PR: rename the PR, regenerate the lockfile, analyze changelogs for breaking changes, and post a summary comment.
The user must provide a PR URL or number as $ARGUMENTS. If not provided, ask for it.
Extract the PR number from the argument and fetch the PR diff to understand what changed:
# Get PR metadata
gh pr view <PR_NUMBER> --json number,title,body,headRefName,baseRefName
# Get the diff to see which dependencies changed
gh pr diff <PR_NUMBER>
Parse the diff to identify:
package.json files were modifiedpnpm-lock.yaml) is included or missingReport the list of dependency changes to the user before proceeding.
Replace the Snyk-generated title with a descriptive one following conventional commit format:
gh pr edit <PR_NUMBER> --title "fix: upgrade <package1> <oldVersion>→<newVersion> and <package2> <oldVersion>→<newVersion>"
Also update the PR description to append test trigger keywords so all test suites run on the next push:
# Get current body, append test keywords
CURRENT_BODY=$(gh pr view <PR_NUMBER> --json body -q '.body')
gh pr edit <PR_NUMBER> --body "${CURRENT_BODY}
test-frontend test-backend test-cli"
Rules for the title:
fix: prefix (these are vulnerability fixes)fix: upgrade 5 dependencies (security)# Fetch and checkout the PR branch
gh pr checkout <PR_NUMBER>
# Install dependencies to regenerate the lockfile
pnpm install
# Check if the lockfile was modified
git status pnpm-lock.yaml
If pnpm-lock.yaml was modified, stage and commit it:
git add pnpm-lock.yaml
git commit -m "chore: regenerate pnpm-lock.yaml
Co-Authored-By: Claude Opus 4.6 <[email protected]>"
Then push the changes:
git push
For each upgraded dependency identified in Step 1:
Fetch the changelog or release notes — try these sources in order:
a. GitHub releases page: https://github.com/<owner>/<repo>/releases
b. CHANGELOG.md in the repo: https://raw.githubusercontent.com/<owner>/<repo>/main/CHANGELOG.md
c. npm page: https://www.npmjs.com/package/<package-name>
d. Web search as a last resort: "<package-name> changelog <old-version> <new-version>"
Identify the package's GitHub repo from the PR body (Snyk usually includes repo links) or from npm registry metadata:
npm view <package-name> repository.url
Review changes between the old and new versions. Focus on:
Search our codebase for usage of each upgraded package to assess impact:
# Check how we import/use the package
Use Grep to search for imports and usage patterns of each package across the codebase.
Assess risk for each dependency:
Post a comment on the PR summarizing your analysis using gh pr comment:
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
## Vulnerability Fix Analysis
### Lockfile
[✅ Regenerated and pushed / ℹ️ Already up to date]
### Dependency Changes
| Package | Old Version | New Version | Risk | Notes |
|---------|------------|-------------|------|-------|
| package-name | x.y.z | a.b.c | 🟢 No risk / 🟡 Low / 🟠 Medium / 🔴 High | Brief explanation |
### Breaking Changes Analysis
[For each dependency with notable changes, provide a brief summary]
#### `package-name` (x.y.z → a.b.c)
- **Changelog**: [link to changelog/releases]
- **Breaking changes**: [None / List of breaking changes]
- **Our usage**: [How we use this package, with file paths]
- **Impact**: [Assessment of whether breaking changes affect us]
### Recommendation
[Overall assessment: safe to merge, needs code changes, needs manual testing, etc.]
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
Adapt the comment content based on your actual findings. Be concise but thorough. If there are breaking changes that affect our code, clearly list what needs to change.
After posting the comment, switch back to the original branch:
git checkout main
pnpm install fails, report the error — it likely means the version bump introduced an incompatibility@types/*), check if the type changes affect our code