Skill Forge: The npm Package for Safely Installing Claude Skills

Skill Forge (@rhize/skill-forge) is an npm command-line tool that quarantines, profiles, and safety-scans agent skills — Claude Code skills and equivalent formats — before they're allowed into your working skill set. It wraps the normal install command with a gate: quarantine, profile, safety scan, overlap analysis, report, then an explicit promote/hold/reject decision.

What is Skill Forge?

Skill Forge is a supply-chain security gate for installing agent skills, published as @rhize/skill-forge on npm at v0.6.0. It doesn't replace the install command you already use — it wraps it, staging every candidate in an isolated sandbox and running it through a fixed pipeline before anything reaches a live skill directory.

We built Skill Forge because we kept installing skills we hadn't read. A one-line npx skills@latest add owner/name drops a stranger's instructions, scripts, and tool bindings straight into a working agent's context and file system — it's easy to run that command a dozen times a week without ever opening the files it downloaded. That's the same trust model as curl | bash from a link in a Discord message, except the payload is aimed at an agent with shell access. Skill Forge puts a checkpoint between "found a skill" and "an agent is running it," and it's one piece of the broader Rhize plugins for Claude Code ecosystem we've been building.

The supply-chain problem with agent skills

Agent skills are distributed the way npm packages were a decade ago: a public registry, a one-line install command, and no vetting step in between. According to the Skill Forge README, skills.sh alone lists 600k+ skills, and installing any one of them is a single command away from touching your file system and tool bindings.

That scale is the point and the problem. A registry that size makes it easy to find a skill for almost anything, and just as easy to install one nobody has reviewed. Unlike an npm dependency, a skill isn't sandboxed by a language runtime — it's read directly into an agent's context, and any scripts or tool bindings it declares run with whatever permissions that agent already has. Skill Forge treats every candidate as untrusted by default, the posture you'd want for any code arriving from an anonymous public registry.

How does the quarantine pipeline work?

Every skill Skill Forge touches goes through the same six-stage pipeline: quarantine, profile, safety scan, overlap analysis, report, then an explicit promote, hold, or reject decision. Nothing reaches your live skill set until you (or an automated --yes policy) make that last call.

1. Report. A terminal report (or --json output) summarizes the profile, safety findings, and overlap result in one place.
2. Promote / hold / reject. You decide interactively, or -y/--yes honors the gate verdict automatically: a block safety verdict is rejected and the process exits nonzero, anything else (pass/warn) is promoted.

Skill Forge also ships a client for skills.sh's /api/v1/skills/audit endpoint, aggregating partner verdicts from Socket, Snyk, Gen Agent Trust Hub, Runlayer, and ZeroLeaks — implemented in the codebase, but add/scan don't call it yet in this build.

What are the three ways to install a skill?

Skill Forge's <source> argument accepts any of three forms, and all three route through the identical quarantine → profile → safety scan → overlap analysis → report → promote/hold/reject pipeline — the gate doesn't care where a skill came from.

Because every source lands in the same sandbox and runs the same ruleset, a skill you wrote yourself gets exactly the same scrutiny as one pulled from a stranger's repo — no shortcut for "trusted" sources is baked into the tool.

What changed with MCP-server gating in v0.6?

As of v0.5, add and scan can gate an MCP server candidate instead of a skill, using the same six-stage pipeline. Version 0.6 added a static capability profile to that report — tool, resource, and prompt counts, plus a confidence rating, without ever running the candidate server.

You opt in explicitly with --artifact mcp; Skill Forge never guesses between a skill and an MCP server, so an npm package name like @scope/name only resolves as an MCP source with that flag — without it, the same string parses as a skills.sh slug. MCP sources come in the same three shapes as skills, except an npm-sourced MCP candidate is fetched with npm pack --ignore-scripts and only ever tarball-extracted — never npm install, never lifecycle scripts — with every tarball member path checked before extraction so an absolute path or a .. segment refuses instead of writing outside the sandbox.

Safety scanning for MCP candidates adds rules on top of the skill ruleset: inline credential values in config or env, unpinned npx -y launch commands (a moving tag like @latest counts as unpinned), --dangerously-*/--no-sandbox flags, and filesystem-root launch arguments.

The v0.6 capability profile is free — it's profiling, not Pro — and strictly static: parsed from the candidate's package.json, any shipped manifest, and MCP SDK source-text patterns like server.tool(...). Anything undeterminable from source text is reported as such rather than discovered by executing the server. A promoted MCP candidate writes exactly one server entry into a target config file's mcpServers map; declared env values are never copied — every var is written empty, with the names you need to fill in printed to the terminal — and the existing target file is backed up first.

Key commands

init is optional but recommended before a first add: no configuration is required either way, since Skill Forge defaults to <cwd>/.claude/skills as its promotion target and ~/.skill-forge/quarantine as its sandbox, and it will offer to run init for you the first time add, scan, list, or status runs with no config present in an interactive terminal.

A useful pattern for CI or scripted checks is npx @rhize/skill-forge scan owner/name --json, which runs the whole gate, prints the result as structured JSON, and exits nonzero on a block verdict — nothing is installed on disk when it's done, since scan never promotes and always cleans up.

How is Skill Forge different from npx skills add?

npx skills@latest add is the raw install mechanism: it fetches a skill and drops it into your working directory, with no inspection step at all. Skill Forge doesn't replace that mechanism — it wraps it, using the same underlying install paths (skills.sh, git, local copy) but staging the result in an isolated quarantine sandbox and running it through the full safety and overlap pipeline before anything touches your live skill set. The practical difference is a checkpoint: with the raw install command, "downloaded" and "trusted" are the same moment; with Skill Forge, they're separated by a report you actually read.

If you never configure a skills root, add/scan still run — profiling and the safety scan work independent of a configured root. Overlap analysis is the one stage that gets skipped (non-fatal, a message to stderr) if skillsRoots[0] doesn't resolve to a directory of existing skills.

Ingestion handoff and the rhize-meta plugin

Skill Forge deliberately stops short of deciding what to extract from a skill worth adopting — which patterns to keep, whether to absorb into an existing skill or fork a new one — because that's a judgment call for a coding agent, not the gate. The --ingest flag hands a promoted skill (or, as of v0.6, a promoted MCP server) off to a coding agent: first config.handoffCommand if init set one, then the first known agent binary on PATH (claude, codex, cursor-agent, windsurf, opencode, gemini), and otherwise it just prints the prompt and skill paths for you to hand off yourself.

Claude Code users get a deeper version of that handoff through the companion rhize-meta plugin, which wraps Skill Forge's queue and ingestion workflow directly inside Claude Code rather than shelling out to a bundled prompt file.

Free vs. Pro and licensing

Skill Forge is open-core with a split license as of v0.2.0. The free tier — quarantine install, profiling, the safety gate, the terminal/JSON report, the promote/hold/reject decision, and the init setup wizard — is licensed MIT. The Pro modules — overlap analysis, the provenance ledger, and the pending-ingestion queue with --ingest handoff — are licensed under the Rhize Commercial License; the source for those modules is available to read and audit, but production use requires a license key.

The important caveat: everything is free until 1.0. This is a 0.x beta, and the Pro tier's runtime license check is intentionally disabled for the whole 0.x line — overlap analysis, the provenance ledger, and --ingest all run for everyone, licensed or not. Without a valid license key (via SKILL_FORGE_LICENSE or config.json's licenseKey, verified offline), add prints a one-line notice above the report noting the feature is free during the beta and will require a license at 1.0.

When should you use it?

Reach for Skill Forge any time you're about to install a skill — or an MCP server — that you haven't personally written and reviewed line by line, especially from a public registry like skills.sh or an unfamiliar git repository. It's also worth running against skills you did write: the safety scan and profiling steps are cheap, and overlap analysis will tell you if you've quietly duplicated something already in your set. Teams standardizing on Claude Code, Codex CLI, or any of the other 73 agents in Skill Forge's detection matrix can wire skill-forge scan <source> --json into CI to block a HIGH/CRITICAL safety verdict before a skill or MCP server ever lands in a shared repo.