AI agent skill · by @lightdash

Fix Vulnerability

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.

Archived 2026-10-23 · Source updated 2026-10-11. Check the original repository for the latest version.

SKILL.md instructions

# Fix Vulnerability PR

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.

## Step 1: Fetch PR details

Extract the PR number from the argument and fetch the PR diff to understand what changed:

```bash
# 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:
- Which packages were upgraded (package name, old version, new version)
- Which `package.json` files were modified
- Whether the lockfile (`pnpm-lock.yaml`) is included or missing

Report the list of dependency changes to the user before proceeding.

## Step 2: Rename the PR

Replace the Snyk-generated title with a descriptive one following conventional commit format:

```bash
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:

```bash
# 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:
- Use `fix:` prefix (these are vulnerability fixes)
- List all upgraded packages with their version ranges
- If there are more than 3 packages, summarize: `fix: upgrade 5 dependencies (security)`
- Keep it under 72 characters when possible

## Step 3: Checkout the PR branch and regenerate lockfile

```bash
# Fetch and checkout the PR branch
gh pr checkout <PR_NUMBER>

# Install dependencies to regenerate the lockfile (sfw blocks known-malicious packages)
# Requires `npm i -g sfw` to be installed globally once per machine.
sfw pnpm install

# Check if the lockfile was modified
git status pnpm-lock.yaml
```

If `pnpm-lock.yaml` was modified, stage and commit it:

```bash
git add pnpm-lock.yaml
git commit -m "chore: regenerate pnpm-lock.yaml

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>"
```

Then push the changes:

```bash
git push
```

## Step 4: Analyze changelogs for breaking changes

For each upgraded dependency identified in Step 1:

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>"`

2. **Identify the package's GitHub repo** from the PR body (Snyk usually includes repo links) or from npm registry metadata:
   ```bash
   npm view <package-name> repository.url
   ```

3. **Review changes between the old and new versions**. Focus on:
   - Breaking changes or deprecations
   - API changes that could affect our code
   - Major behavioral changes
   - Security advisories and CVE details

4. **Search our codebase** for usage of each upgraded package to assess impact:
   ```bash
   # Check how we import/use the package
   ```
   Use Grep to search for imports and usage patterns of each package across the codebase.

5. **Assess risk** for each dependency:
   - **No risk**: Patch version bump, no breaking changes, minimal usage in our code
   - **Low risk**: Minor version bump, no breaking changes in APIs we use
   - **Medium risk**: Breaking changes exist but don't affect our usage patterns
   - **High risk**: Breaking changes directly affect how we use the package

## Step 5: Post PR comment with findings

Post a comment on the PR summarizing your analysis using `gh pr comment`:

```bash
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.

## Step 6: Return to original branch

After posting the comment, switch back to the original branch:

```bash
git checkout main
```

## Notes

- If `pnpm install` fails, report the error — it likely means the version bump introduced an incompatibility
- For monorepo packages (e.g., `@types/*`), check if the type changes affect our code
- Snyk PRs typically include CVE details in the PR body — reference these in your analysis
- If a dependency has many transitive dependents, note this as it increases risk surface
- Do NOT approve or merge the PR — only analyze and comment