Dependency Verification
Block or warn when an agent tries to install packages that do not exist on PyPI, npm, or crates.io before they hit your project.
Overview
Dependency verification is an agent skill most often used in Ship (also Build integrations) that confirms PyPI, npm, and crates.io package names exist before install commands proceed.
Install
npx skills add https://github.com/athola/claude-night-market --skill dependency-verificationWhat is this skill?
- Verifies PyPI, npm, and crates.io with HTTP 200/404 classification per package name
- Three-state hook: exists (pass), nonexistent (block in strict mode), unverified (warn only, never block on network failu
- Known-popular package short-circuit skips network calls for common installs like requests
- 1.5s per-package timeout; IMBUE_PKG_REGISTRY_CHECK=0 for offline typosquat-only mode
- VOW_SHADOW_MODE controls block vs warn for likely hallucinations
- 3 public registry ecosystems: PyPI, npm, crates.io
- 1.5 second per-package network lookup timeout
- 3 decision states: exists, nonexistent, unverified
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; trending (+100% hot-view momentum).
What problem does it solve?
Your agent keeps suggesting pip or npm packages that sound plausible but do not exist on any registry, risking typosquats and wasted build time.
Who is it for?
Teams running agent guard hooks on package managers who want explicit 404 handling without blocking on transient network errors.
Skip if: Projects that only use private registries with no public endpoint mapping, unless you extend the guard beyond the three documented ecosystems.
When should I use this skill?
Before or during agent-issued package install commands across PyPI, npm, or crates.io when registry truth matters.
What do I get? / Deliverables
Install targets are classified against live or offline signals so hallucinated names are blocked or warned before they enter your dependency graph.
- Per-install pass, warn, or block classification
- Configurable strict vs shadow behavior via environment flags
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Supply-chain guardrails belong on the ship shelf because they gate install commands right before dependencies land in a repo or environment. Security subphase covers hallucinated package names, typosquats, and unverified registry lookups during automated installs.
Where it fits
Agent adds a Python SDK—hook confirms the PyPI name returns 200 before mutating requirements.
Pre-merge CI runs the guard in block mode so 404 package names never land on main.
You tune shadow mode and 1.5s timeouts after rate limits without failing installs on flaky Wi‑Fi.
How it compares
Use as a pre-install checker on registry HTTP semantics, not as a full SBOM or CVE vulnerability scanner.
Common Questions / FAQ
Who is dependency-verification for?
Solo and indie builders using Claude Code or similar agents with automated pip, npm, or cargo installs who need a lightweight anti-hallucination gate.
When should I use dependency-verification?
During Build when adding integrations and dependencies, and during Ship security review whenever agents execute install commands; also in Operate when iterating on hook strictness (VOW_SHADOW_MODE) before production enforcement.
Is dependency-verification safe to install?
Review the Security Audits panel on this Prism page for upstream audit results; the skill performs outbound registry HTTP checks when network mode is enabled.
SKILL.md
READMESKILL.md - Dependency Verification
# Registry Checks Per-ecosystem endpoints for confirming a package exists, and the rules the guard hook applies. ## Endpoints | Ecosystem | URL | Exists | Absent | |-----------|-----|--------|--------| | PyPI | `https://pypi.org/pypi/{name}/json` | HTTP 200 | HTTP 404 | | npm | `https://registry.npmjs.org/{name}` | HTTP 200 | HTTP 404 | | crates.io | `https://crates.io/api/v1/crates/{name}` | HTTP 200 | HTTP 404 | A manual check from the shell: ```bash # PyPI: prints the status code; 200 exists, 404 does not. curl -s -o /dev/null -w '%{http_code}\n' https://pypi.org/pypi/requests/json ``` ## Decision Rules The hook classifies each install target into one of three states: - **exists** (registry returns 200): pass. - **nonexistent** (registry returns 404): likely hallucination. Block when `VOW_SHADOW_MODE=0`, warn otherwise. - **unverified** (timeout, rate limit, offline, non-404 error): warn only, never block. The guard does not fail closed on a network problem. Known-popular packages short-circuit before any network call, so a common install such as `pip install requests` never makes a request to the registry. Only names absent from the bundled popular set are looked up. ## Timeout and Offline Behavior The network lookup uses a 1.5 second per-package timeout. Set `IMBUE_PKG_REGISTRY_CHECK=0` to skip network lookups entirely and rely on the offline typosquat signal (edit distance against the known-popular set). This is the right setting in sandboxed or air-gapped environments where the registry is unreachable. ## Typosquat Distance A name not in the known-popular set but within Levenshtein distance 1 or 2 of a popular package is flagged as a typosquat suspect. The distance threshold balances catching real typos (`reqeusts`, `numpi`) against false positives on legitimately short names. The known-popular set is the most-impersonated packages per ecosystem and is meant to be extended as new impersonation targets emerge. --- name: dependency-verification description: Verifies a package exists before install, defending against hallucination and slopsquatting. Use when adding, recommending, or installing a package. alwaysApply: false category: workflow-methodology tags: - dependencies - supply-chain - hallucination - slopsquatting - verification dependencies: [] tools: [] usage_patterns: - pre-install-verification - supply-chain-defense - dependency-review complexity: basic model_hint: standard estimated_tokens: 1400 modules: - modules/registry-checks.md role: library --- > A package name the model produced is a claim, not a fact. The > registry is the fact. Verify before you install. # Dependency Verification ## Overview Code-generating language models recommend packages that do not exist at a measured rate of 5.2% (commercial models) to 21.7% (open models) across 576,000 samples (Spracklen et al. 2024, arXiv 2406.10279). Worse, 58% of hallucinated names recur across reruns, so an attacker can predict them, register the empty name, and ship malware. This is "slopsquatting." A proof-of-concept package (`huggingface-cli`) drew over 30,000 downloads after being registered against a commonly hallucinated name. Package hallucination is also inversely correlated with coding-benchmark score, so a better model does not make this go away. The defense is cheap: confirm the name exists in its registry before installing or recommending it. This skill defines that check and is enforced by the `guard_package_hallucination.py` PreToolUse hook. ## When to Use Apply before any of these: - Running `pip install`, `uv add`, `npm install`, `pnpm add`, `yarn add`, `cargo add`, `poetry add`, or `pdm add`. - Writing a dependency into `pyproject.toml`, `requirements.txt`, `package.json`, or `Cargo.toml`. - Recommending a package to the user in prose. ## The Two Signals A package fails verification on either signal: 1. **Nonexistent**: the name is absent from its registry. This is a likely hallucination. Do not install