| name | mav-bp-dependency-management |
| description | Dependency management conventions for all projects. Covers lock files, version pinning, vulnerability scanning, license compliance, update strategy, and minimal dependency principle. Applied when adding, updating, or reviewing dependencies. |
| user-invocable | false |
| disable-model-invocation | true |
Dependency Management Standards
Maverick's hard rules for keeping dependencies intentional, pinned, secure, and maintained.
Maverick's Rules
- Lock files are committed and reviewed — inspect lock diffs for unexpected transitive additions; never manually edit a lock file (regenerate from the manifest).
- CI and production install from the lock, never resolve fresh —
npm ci, yarn install --immutable, pnpm install --frozen-lockfile, uv sync --locked, cargo install --locked, bundle install --frozen, or the ecosystem equivalent.
- Vulnerability scanning is mandatory in CI — runs on every PR plus a scheduled cadence against the default branch. Critical/high findings block merges; medium is fixed within the current iteration; false positives are suppressed only with a documented justification.
- License allow-list — acceptable by default: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, 0BSD, Unlicense. Copyleft (GPL/LGPL, and especially AGPL for SaaS) and unknown/no-license dependencies are blocked pending investigation. Audit transitive licenses too.
- Minimal dependency principle — no packages for trivial utilities, single-use wrappers, or stdlib-covered functionality. Do add packages for crypto/auth/security-sensitive logic — never roll your own.
- Never
* or latest version specifiers. Exact pins for security-critical dependencies (auth, crypto); when in doubt, pin tighter.
- Major version bumps get dedicated PRs — one major at a time, never buried in feature PRs. Security patches fast-track after CI.
- Abandoned packages (no releases/response in 12+ months) — migrate to a maintained alternative, fork into the organisation, or inline the functionality.
- Never
--force or --legacy-peer-deps — fix the underlying version conflict.
Project Implementation Lookup
Check for docs/maverick/skills/dependency-management/SKILL.md. If present, read it — it wins on specifics (library, config, conventions). If missing, proceed with these standards and note the gap in your summary.
Detecting Dependency Issues in Code Review
| Pattern | Issue | Fix |
|---|
| Lock file not committed | Non-deterministic builds | Commit the lock file, use frozen install in CI |
| Lock file manually edited | Corrupted dependency resolution | Regenerate from manifest |
| New dependency for trivial functionality | Unnecessary surface area | Inline the logic or use standard library |
| Dependency with no license or copyleft license | Legal risk | Replace with a permissively licensed alternative |
| Major version bump buried in a large PR | Breaking changes may be missed | Isolate major bumps into dedicated PRs |
* or latest in version specifiers | Unpredictable builds | Pin to a specific range |
| No vulnerability scanning in CI | Known CVEs may ship | Add npm audit / pip-audit / equivalent to pipeline |
| Dependency with no recent releases (12+ months) | Abandoned package risk | Evaluate alternatives or plan a fork |
| Large transitive dependency addition | Unexpected supply chain expansion | Investigate and consider lighter alternatives |
--force or --legacy-peer-deps in install commands | Masking resolution conflicts | Fix the underlying version conflict |
