Reviewing Dependency Changes
- 49 installs
- 129 repo stars
- Updated August 4, 2026
- bitwarden/ai-plugins
reviewing-dependency-changes is a Claude skill that reviews dependency-manifest and lock-file edits in a PR diff for approval-process compliance, version-bump risk, and lock-file hygiene.
About
This skill reviews the dependency changes inside a pull request diff. A code reviewer uses it when a manifest file like package.json, Cargo.toml, or go.mod changes, to check whether new dependencies followed the AppSec approval process, whether major version bumps were evaluated, and whether lock files stayed in sync. It explicitly defers deep security and license analysis to the separate reviewing-dependencies skill.
- Flags net-new dependencies in a PR diff that lack an AppSec approval signal
- Checks major version bumps, lock-file hygiene, and dependency-removal completeness
- Handles Renovate/Dependabot bot PRs with tailored review guidance
Reviewing Dependency Changes by the numbers
- 49 all-time installs (skills.sh)
- Ranked #580 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
reviewing-dependency-changes capabilities & compatibility
- Capabilities
- code review · dependency review
- Works with
- github · jira
- Use cases
- code review
- Pricing
- Free
What reviewing-dependency-changes says it does
Use this skill when a PR diff contains changes to dependency manifest files (package.json, .csproj, Cargo.toml, go.mod, requirements.txt, etc.) or when reviewing Renovate/Dependabot bot PRs.
Lock files ensure reproducible builds. Inconsistencies between manifests and lock files are a build reliability and security concern.
Major bump without migration discussion
npx skills add https://github.com/bitwarden/ai-plugins --skill reviewing-dependency-changesAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 49 |
|---|---|
| repo stars | ★ 129 |
| Last updated | August 4, 2026 |
| Repository | bitwarden/ai-plugins ↗ |
What it does
Review dependency manifest and lock-file changes in a PR diff for approval-process compliance and version-bump risk.
Who is it for?
Reviewers checking PRs that touch package.json, .csproj, Cargo.toml, go.mod, or bot dependency updates.
Skip if: Deep security or license analysis of a dependency, which is handled by the reviewing-dependencies skill.
When should I use this skill?
A PR diff contains changes to dependency manifest files or is a Renovate/Dependabot bot PR.
What you get
Each dependency change is flagged with a severity finding tied to approval, version, lock-file, or removal completeness.
- Severity-tagged findings on dependency changes
- Approval-signal check
- Lock-file hygiene check
By the numbers
- 5 review areas (new deps, major bumps, lock files, bot PRs, removal)
- 6 manifest file families detected
Files
Reviewing Dependency Changes
Manifest File Detection
Flag this skill when any of these files appear in the diff:
package.json,package-lock.json*.csproj,Directory.Packages.props,packages.lock.jsonCargo.toml,Cargo.lockgo.mod,go.sumrequirements.txt,pyproject.toml,poetry.lockGemfile,Gemfile.lock
Area 1: New Dependencies
When a PR adds a dependency that was not previously in the codebase, Bitwarden's Dependency Review and Approval process requires AppSec review and approval before integration. This applies to all new dependencies — production, dev, and test.
The submitter must provide the package name/version, ecosystem, justification, scope, affected products, and what it replaces. A security engineer creates a VULN task in Jira and evaluates the dependency across security (known CVEs, exploitability), license compatibility (permissive licenses like MIT/Apache-2.0 are acceptable; copyleft licenses like GPL/AGPL are flagged), maintenance health (active maintainers, recent releases, security policy), supply chain risk (typosquatting, ownership changes, obfuscated install scripts), and transitive dependencies before rendering an approval decision.
What to Check
1. Is this a net-new dependency (not already present in the codebase)? 2. Does the PR description contain an approval signal indicating the process was followed?
Approval Signals
Evidence that the dependency approval process was followed:
- PR description references a VULN task (e.g.,
VULN-1234) - PR description explicitly mentions AppSec approval or the dependency review process
Severity
- No approval signal found → ⚠️ IMPORTANT: New dependency
<package>added. Bitwarden requires AppSec approval before introducing new dependencies. The submitter should reach out to the AppSec team to initiate the dependency review and approval process. - Unclear whether approval was obtained → ❓ QUESTION: Was AppSec approval obtained for the new
<package>dependency?
What NOT to Flag
- Dependencies that already exist in the codebase (version updates are not new dependencies)
- Dependencies added by Renovate/Dependabot as transitive dependency updates (these are part of Stage 5 monitoring for existing approved dependencies)
Area 2: Major Version Bumps
A major version bump (e.g., v2 → v3) may introduce breaking changes that affect Bitwarden's codebase.
What to Check
1. Is this a SemVer major version change? 2. Does the PR description discuss breaking changes or migration steps?
Severity
- Major bump without migration discussion → ❓ QUESTION: This bumps
<package>from vXto vY(major). Were breaking changes evaluated? - Version downgrade → ⚠️ IMPORTANT:
<package>is being downgraded from vXto vY. This is unusual and may reintroduce resolved vulnerabilities.
Area 3: Lock File Hygiene
Lock files ensure reproducible builds. Inconsistencies between manifests and lock files are a build reliability and security concern.
What to Check
| Scenario | Finding |
|---|---|
| Manifest changed, lock file not updated | ⚠️ IMPORTANT: Lock file not updated to reflect manifest changes |
| Lock file changed, no manifest change | ❓ QUESTION: Lock file changed without a corresponding manifest change — was this intentional (e.g., npm audit fix)? |
| Lock file deleted | ⚠️ IMPORTANT: Lock file removal breaks reproducible builds |
What NOT to Flag
- Large lock file diffs from a small manifest change — this is normal behavior. Lock files can change significantly from a single dependency addition or version bump.
- Lock file-only changes that accompany a clear manifest change in the same PR.
Area 4: Automated Dependency PRs
Renovate and Dependabot PRs are part of Bitwarden's Stage 5 (Monitoring) process. These automated updates to existing approved dependencies require different review treatment.
How to Detect
- PR author:
renovate[bot],dependabot[bot], or similar bot accounts - PR title pattern: "Update ...", "Bump ...", "chore(deps): ..."
Review Guidance
| Scenario | Action |
|---|---|
| Minor/patch update to existing dependency | No approval-process finding needed. Focus on lock file hygiene and CI status. |
| Major version bump from bot | Flag per Area 2 — major bumps warrant human review regardless of source. |
| Bot PR introduces a net-new dependency | Flag per Area 1 — new dependencies require the approval process regardless of source. |
Area 5: Dependency Removal
When a dependency is removed from a manifest, verify the removal is complete.
What to Check
1. Are there remaining code references to the removed package?
- JavaScript/TypeScript:
import ... from '<package>',require('<package>') - C#/.NET:
using <namespace>, references in other.csprojfiles - Rust:
use <crate>::,extern crate <crate> - Python:
import <package>,from <package> import
2. Are there references in build or infrastructure files?
Dockerfile,docker-compose.yml- CI workflow files (
.github/workflows/*.yml) - Build scripts,
Makefile, task runners
Severity
- Dead imports or references remain → ♻️ DEBT:
<package>removed from manifest but still referenced in code.
Related skills
Improve Codebase ArchitectureSafely deepen clusters of shallow modules into cohesive, testable units while respecting their external dependencies.566k196k
Caveman ReviewGet ultra-compressed, one-line code review comments that cut noise while keeping every actionable fix.270k94.7kCodebase DesignShared vocabulary for designing deep modules: improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable.266k196kCavecrewDelegate coding tasks to specialized subagents that return compressed output, keeping the main context window usable for much longer sessions.220k94.7kCode ReviewReviews a branch or PR diff on two axes at once: conformance to coding standards plus a code-smell baseline, and whether it actually implements the original spec.201k196k
Requesting Code ReviewDispatch a consistent, high-signal code reviewer subagent that catches plan deviations and quality issues before merging or continuing development.183k264kFAQ
Does it detect bot PRs?
Yes, it detects Renovate and Dependabot PRs by author and title pattern and applies different review treatment for automated updates.
What does it check for a new dependency?
Whether it is net-new and whether the PR description carries an approval signal such as a VULN task reference or AppSec approval mention.