# Vet

> Run a background check on a dependency before installing it. Use when the user is considering adding a package/library and wants to know if it's safe, maintained, appropriately sized, and correctly named — or wants alternatives compared.

- Skill: `tokyubevoxelverse/vet` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tokyubevoxelverse/vet`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tokyubevoxelverse/vet/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tokyubevoxelverse (https://skillmd.com/u/tokyubevoxelverse)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tokyubevoxelverse/vet

---


# 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.

1. **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.
2. **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.
3. **License.** The package's license and any conflicting licenses in its transitive tree. Flag copyleft in the tree of a commercial project loudly.
4. **Security.** Known advisories (ecosystem audit tooling, osv.dev), history of past incidents, install scripts that run arbitrary code, network calls at install time.
5. **Identity.** Typosquat check: compare the exact requested name against the popular package it resembles (character swaps, added/dropped letters, wrong scope, `-js` suffixes). Verify the registry package actually points at the repo it claims. This check has caught real attacks; take it seriously.
6. **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.

