PRPM solves distribution for 7,500+ packages. This is an idea (plus an offer of reusable prior art) for the trust layer on top of it.
When someone runs prpm install collections/nextjs-pro and gets 20 packages, there is currently no way to answer "what can these packages actually do?" without reading every file. The capability surface — shell commands, network endpoints, file paths touched — is implicit in the markdown.
Some data: we recently scanned ~17,000 Claude Code skills on public GitHub (methodology + aggregate numbers). 38.8% contain shell commands; only 4% declare anything in allowed-tools. This repo's own .claude/skills is typical of the ecosystem: of its 38 skills, 22 contain shell commands and 22 reference external URLs, while 1 (osgrep) declares allowed-tools. Nothing wrong with any of them — the point is that the manifest doesn't carry this information, so neither the installer nor the registry can show it.
Two places this could plug into PRPM:
- Registry side: parse the capability surface at publish time and show it on the package page, the way npm shows dependencies — "this skill runs
git and docker, talks to api.example.com, reads .env".
- Install side:
prpm install records the approved surface in a lockfile, and an update that changes the surface (new shell verb, new endpoint, new sensitive path) gets flagged before it lands — package-lock semantics, but for behavior rather than bytes.
Prior art we're happy to share: skil-lock (Apache-2.0) does exactly this parse → lock → diff cycle for .claude/skills and .codex/skills in CI. The SKILL.md parser, capability schema, and lockfile format (SPEC.md) are reusable, and I'd happily help adapt them to PRPM's package formats — the cross-editor converters you already have would make PRPM the first registry able to show this across every ecosystem.
If this isn't the direction you want for the registry, feel free to close — no hard feelings.
PRPM solves distribution for 7,500+ packages. This is an idea (plus an offer of reusable prior art) for the trust layer on top of it.
When someone runs
prpm install collections/nextjs-proand gets 20 packages, there is currently no way to answer "what can these packages actually do?" without reading every file. The capability surface — shell commands, network endpoints, file paths touched — is implicit in the markdown.Some data: we recently scanned ~17,000 Claude Code skills on public GitHub (methodology + aggregate numbers). 38.8% contain shell commands; only 4% declare anything in
allowed-tools. This repo's own.claude/skillsis typical of the ecosystem: of its 38 skills, 22 contain shell commands and 22 reference external URLs, while 1 (osgrep) declaresallowed-tools. Nothing wrong with any of them — the point is that the manifest doesn't carry this information, so neither the installer nor the registry can show it.Two places this could plug into PRPM:
gitanddocker, talks toapi.example.com, reads.env".prpm installrecords the approved surface in a lockfile, and an update that changes the surface (new shell verb, new endpoint, new sensitive path) gets flagged before it lands — package-lock semantics, but for behavior rather than bytes.Prior art we're happy to share: skil-lock (Apache-2.0) does exactly this parse → lock → diff cycle for
.claude/skillsand.codex/skillsin CI. The SKILL.md parser, capability schema, and lockfile format (SPEC.md) are reusable, and I'd happily help adapt them to PRPM's package formats — the cross-editor converters you already have would make PRPM the first registry able to show this across every ecosystem.If this isn't the direction you want for the registry, feel free to close — no hard feelings.