Mav bp dependency management
Skill thermiteau/maverick/skills/mav-bp-dependency-management
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.From its SKILL.md
npx -y skills add thermiteau/maverick --skill mav-bp-dependency-managementAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.6 KB, as published. Nobody here has run it
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
*orlatestversion 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
--forceor--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 |