When to use this skill
When the user asks about an npm package — current version, dependencies, license, maintainers, or release timeline. This is the same read-only JSON API that npm install reads from. No auth. No key. For npm download counts over time, use the separate npm downloads API — this one only gives per-package metadata.
Your best first call
curl "https://registry.npmjs.org/express/5.2.1"
No auth. No key. Use /{package}/{version} when you know the version — it returns only that version's metadata, a bounded response even for packages with hundreds of published versions. Use /{package} (the packument) when you need dist-tags, the full time timeline, or the maintainers/author list. For popular packages, the packument can be hundreds of kilobytes; prefer the versioned endpoint whenever you can.
The versioned response key fields:
name, version — identity
dependencies — runtime dependency map (Express 5.2.1 depends on router, body-parser, cookie, send, qs, and others)
engines — Node version requirement ("node": ">= 18" for Express 5.x)
dist.tarball — download URL for the tarball
dist.integrity — Subresource Integrity hash for verifying the tarball
funding — sponsorship link
The packument (/express) adds dist-tags (which version is "latest", "next", etc. — Express has both latest pointing to v5.2.1 and latest-4 pointing to v4.22.1), time (ISO timestamps for every published version, going back to the package's creation), maintainers (current publish-access accounts), and author (original creator — often different from current maintainers).
Fallbacks (when the best call isn't enough)
- Search for packages by keyword →
/-/v1/search?text=express&size=5 returns ranked results with download counts, dependents, and quality scores. Use when the user doesn't know a package name and wants to discover packages.
- Download stats over time → The npm downloads API (
api.npmjs.org/downloads/...) covers download trends. Reach for it when the user asks "how popular is X?" rather than "what does X depend on?".
Pitfalls
- The packument for popular packages is huge. Express has 287+ versions and its packument is hundreds of kilobytes. Call
/{package}/{version} when you only need one version.
author and maintainers are different things. author is the original creator (often no longer involved). maintainers are the current publish-access accounts. Trust maintainers for "who is responsible right now."
- The
time object contains ghost entries. Unpublished versions are removed from versions but their timestamps may linger in time, creating entries you cannot resolve to actual version metadata.
- Search qualifiers go inside the
text parameter. text=maintainer:wesleytodd filters by maintainer, text=scope:@types filters by scope — these are not separate query parameters.
One-line summary for the user
I can look up any npm package's metadata — versions, dependencies, license, maintainers, release timestamps — from the npm registry in a single unauthenticated GET.
SKILL.md source (frontmatter + body)
---
name: look-up-npm-package-metadata
description: When the user asks about an npm package — current version, dependencies, license, maintainers, release timeline, or "what does express depend on" — reach for the npm Registry API. Unauthenticated, one GET per package or version.
---
## When to use this skill
When the user asks about an npm package — current version, dependencies, license, maintainers, or release timeline. This is the same read-only JSON API that `npm install` reads from. No auth. No key. For npm download counts over time, use the separate npm downloads API — this one only gives per-package metadata.
## Your best first call
```bash
curl "https://registry.npmjs.org/express/5.2.1"
```
No auth. No key. Use `/{package}/{version}` when you know the version — it returns only that version's metadata, a bounded response even for packages with hundreds of published versions. Use `/{package}` (the packument) when you need `dist-tags`, the full `time` timeline, or the `maintainers`/`author` list. For popular packages, the packument can be hundreds of kilobytes; prefer the versioned endpoint whenever you can.
The versioned response key fields:
- `name`, `version` — identity
- `dependencies` — runtime dependency map (Express 5.2.1 depends on `router`, `body-parser`, `cookie`, `send`, `qs`, and others)
- `engines` — Node version requirement (`"node": ">= 18"` for Express 5.x)
- `dist.tarball` — download URL for the tarball
- `dist.integrity` — Subresource Integrity hash for verifying the tarball
- `funding` — sponsorship link
The packument (`/express`) adds `dist-tags` (which version is "latest", "next", etc. — Express has both `latest` pointing to v5.2.1 and `latest-4` pointing to v4.22.1), `time` (ISO timestamps for every published version, going back to the package's creation), `maintainers` (current publish-access accounts), and `author` (original creator — often different from current maintainers).
## Fallbacks (when the best call isn't enough)
- **Search for packages by keyword** → `/-/v1/search?text=express&size=5` returns ranked results with download counts, dependents, and quality scores. Use when the user doesn't know a package name and wants to discover packages.
- **Download stats over time** → The npm downloads API (`api.npmjs.org/downloads/...`) covers download trends. Reach for it when the user asks "how popular is X?" rather than "what does X depend on?".
## Pitfalls
- **The packument for popular packages is huge.** Express has 287+ versions and its packument is hundreds of kilobytes. Call `/{package}/{version}` when you only need one version.
- **`author` and `maintainers` are different things.** `author` is the original creator (often no longer involved). `maintainers` are the current publish-access accounts. Trust `maintainers` for "who is responsible right now."
- **The `time` object contains ghost entries.** Unpublished versions are removed from `versions` but their timestamps may linger in `time`, creating entries you cannot resolve to actual version metadata.
- **Search qualifiers go inside the `text` parameter.** `text=maintainer:wesleytodd` filters by maintainer, `text=scope:@types` filters by scope — these are not separate query parameters.
## One-line summary for the user
I can look up any npm package's metadata — versions, dependencies, license, maintainers, release timestamps — from the npm registry in a single unauthenticated GET.