The 60-second pre-flight check for AI-suggested packages

Your AI coding assistant suggests npm install react-form-state-helpers. You haven't heard of it. You're tired. You hit enter anyway.

Before you do that, five things you can check in under sixty seconds. Each one is a yellow flag on its own; two or more is a red flag.

1. Does the package exist? (5 seconds)

Open https://www.npmjs.com/package/<name> in a new tab. If it 404s, the AI hallucinated it. The install will fail, you'll move on, you're fine.

The danger is the not-404 case where the package was registered recently — that's the slopsquat shape. Check the next four signals.

2. When was the first version published? (5 seconds)

On the npm page, scroll to "Version". Click it. The first version's date is the package's birthday. If it's less than 90 days old and the AI is suggesting it like a well-established library, that's suspicious. Real libraries that AI assistants confidently suggest have multiple years of release history. Slopsquats are weeks old.

3. How many weekly downloads? (5 seconds)

Right side of the npm page. Real libraries that solve a common problem have thousands of weekly downloads. A package with fewer than 50 weekly downloads is either freshly published, a slopsquat, or so niche that AI shouldn't have known about it. All three are reasons to slow down.

4. Is there a GitHub repo, and does it look real? (15 seconds)

On the npm page, click the "Repository" link. If there's no link, that's already a yellow flag.

If there is a link, check:

Does the repo have a commit history older than the npm package's first publish date? Real projects develop on GitHub first.
Are there issues filed by other people? Slopsquats have zero issues.
Is the README copy-pasted from a popular library? Common slopsquat tactic.

If the GitHub repo was created three days ago and has one commit "init", you're looking at a slopsquat.

5. Who is the publisher, and what else have they published? (20 seconds)

On the npm page, click the maintainer's username. You'll see their other packages.

A maintainer with a long history of legitimate packages is a positive signal.
A maintainer whose only package is this one, with no other history → yellow flag.
A maintainer who publishes only <name>-utils, <name>-tools, <name>-extras variations → classic slopsquat shape, registering names around a popular library.

The automation question

You're not going to do this every time. Nobody is. The point of the checklist isn't to make you do it — it's to show you what an automated tool should be checking on your behalf.

A local install proxy that does all five checks in a few milliseconds is the actual fix. The same signals (registration age, download count, GitHub linkage, maintainer history, similarity-to-popular for slopsquat detection) feed into a single score. The score either lets the install through or refuses it with a one-line message.

The tradeoff is: the human checklist is free but you won't do it; the automated check costs you a one-line install but actually runs every time.

What Veln catches without you thinking about it

Cooling window — packages younger than your configured threshold are refused at the gate. Default catches most slopsquats.
Maintainer fingerprint — when the publisher changes between versions, it surfaces.
Typosquat distance — names within edit distance of a popular package are flagged.
Lifecycle script analysis — postinstall scripts get scored for suspicious patterns (curl-pipe-bash, credential paths, exec of decoded payloads).
Threat feed cross-check — known-malicious package hashes are blocked immediately.

You still get to read package code if you want. But you're not the only check anymore.

When to do the manual check anyway

The five-step checklist is still worth doing for one specific case: when you're adding a new direct dependency to a long-lived project (a real production app, not a side project). The cost of getting that decision wrong is high; the cost of two minutes of checking is low.

For everything else — AI-suggested deps in a scaffolded prototype, transitive deps you didn't pick, postinstall hooks in libraries you've used for years — automation is the only check that runs reliably.