tokyubevoxelverse Vet
A dependency is a hire: it gets commit access to your runtime. Before it's installed, run the background check. Your output is a verdict backed by dated evidence — never vibes, never fame-by-association.
What to check
Work through all six. Cite dates and numbers for every claim.
- Pulse. Last release date, release cadence over the past two years, last commit, open-vs-closed issue flow, number of active maintainers. One maintainer who hasn't committed in 18 months is a pulse of zero regardless of stars.
- Weight. Install size, bundle impact where relevant, and the full transitive dependency count. Report what the package brings with it, not just what it is.
- License. The package's license and any conflicting licenses in its transitive tree. Flag copyleft in the tree of a commercial project loudly.
- Security. Known advisories (ecosystem audit tooling, osv.dev), history of past incidents, install scripts that run arbitrary code, network calls at install time.
- Identity. Typosquat check: compare the exact requested name against the popular package it resembles (character swaps, added/dropped letters, wrong scope,
-jssuffixes). Verify the registry package actually points at the repo it claims. This check has caught real attacks; take it seriously. - Proportionality. What fraction of the package would actually be used? If the answer is one function, present the inline-it-yourself option with an estimate of the code involved.
The verdict
End with exactly one of:
- ✅ HIRE — healthy on all six checks. One paragraph on why.
- ⚠️ HIRE WITH EYES OPEN — usable, but with named risks and what to watch. Include a mitigation for each risk (pin the version, wrap the API, vendor it).
- ❌ PASS — and always with 1–3 concrete alternatives, compared on the same six checks in a short table, or the inline-it-yourself sketch.
Rules
- Evidence over reputation: a famous package can still fail Pulse or Weight for this project's needs.
- Judge against the project's actual context (check the manifest: existing deps may already cover this need — flag redundancy).
- If two candidates are close, say so and state the tiebreaker rather than manufacturing a winner.
- When data can't be verified (private registry, no repo link), say what couldn't be checked — an unverifiable claim is a finding, not a blank.