How to Check Claude Code Skills Before You Install Them
Scan the candidate, inspect the source and make a deliberate install decision
Part of the guide Rhize Plugins for Claude Code: Which Ones Should You Install?
On this page
Before you install a Claude Code skill, check the instructions, scripts, requested tools and source. A one-line install is convenient; it is not a substitute for deciding what you want an agent to run.
Skill Forge is a CLI that stages candidates outside the live skill directory, profiles their contents and runs static risk checks. The practical sequence is scan, read the findings, inspect the source, then make an explicit install or reject decision.
What is Skill Forge?
The commands in this guide were checked against @rhize/skill-forge 0.22.0, published from commit 1f7ad9bbc695bc0452e53b156c5e9264353f6694. It adds a local review record and maintenance workflow. It does not prevent installs through other tools or certify a skill as safe.
Skills can contain more than prose: scripts, references and tool bindings may affect what an agent reads or executes. Inspect those resources and the host permissions before installation, especially when the task involves private data or external actions.
The supply-chain problem with agent skills
Marketplaces can provide useful safeguards. Vercel documents partner audits and installation risk information for skills.sh. Skill Forge adds local review of the candidate and your installed set; it should not be described as the only vetting step available.
Different sources and hosts have different controls. A staging directory separates candidate files from the live skill set, but it is not an operating-system security sandbox. The host's permissions, your review and runtime verification remain part of the boundary.
How does the quarantine pipeline work?
Candidates follow six stages: staging, profile, safety scan, overlap analysis when available, report and an explicit decision. Begin with scan when you want to inspect without installing; use add only when ready to review a promotion.
Staging. The candidate is fetched into the configured quarantine directory. Inspecting it there keeps it out of the live skill directory until promotion. Avoid treating the directory itself as proof that arbitrary code would be contained.
- Profile. Skill Forge reads the candidate's name, version, license, file structure, and any declared MCP or tool dependencies.
- Safety scan. A built-in deny-pattern ruleset runs against every candidate, fully offline: curl/wget-piped-into-shell, base64-obfuscated exec, reverse shells, recursive force-delete, credential-file access or exfiltration, dynamic eval,
shell=Truesubprocess calls, persistence via shell rc files or cron, andsudousage. A HIGH or CRITICAL finding blocks the candidate outright (verdictblock); lower severity produceswarn; a clean scan ispass. If SkillSpector (Apache-2.0) is onPATH, Skill Forge shells out to it too — with--no-llmby default, so scanned content never reaches an external LLM — and merges its findings in. SkillSpector's absence never blocks the gate.
- Overlap analysis (Pro, free during the 0.x beta). The candidate is ranked against the skills already present in your configured skills root, so you can see whether it duplicates something you already have.
- Report. A terminal report (or
--jsonoutput) summarizes the profile, safety findings, and overlap result in one place.
Promotion. Under default block-high strictness, HIGH or CRITICAL findings block promotion. Lower-severity findings still need review. Do not use an automatic confirmation flag as a substitute for reading the report; an MCP server that serves skills is held for explicit review rather than automatically promoted.
Optional discovery. The find command can search skills.sh, retrieve details or request partner audit results. Search results are unvetted, and discovery requires its documented authentication. Local scanning and the partner-audit layer answer different questions.
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.
| Source type | Example | Notes |
|---|---|---|
| skills.sh slug | owner/name | The registry shorthand most skills are shared as. |
| Git URL | https://github.com/owner/repo.git, git@..., or anything ending in .git | Shallow-cloned into quarantine. |
| Local filesystem path | ./local-skill-dir | Copied into quarantine, same handling as any other source. |
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.
How do you review an MCP server?
Use --artifact mcp explicitly when the candidate is a server. The tool statically profiles detectable capabilities without starting the candidate server. Counts and confidence describe what the scan can infer from the package, not everything the server could do at runtime.
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.
MCP promotion writes a server entry to the reviewed target config with credential values left empty. Supply secrets through the host's supported setup after reviewing the exact server and launch command. A static profile cannot inspect unreachable live content; that content remains unverified.
Key commands
| Command | What it does |
|---|---|
| npx @rhize/skill-forge@0.22.0 init | Detects supported local coding agents and lets you review gate targets, a default promotion target and an optional handoff agent. |
| npx @rhize/skill-forge@0.22.0 add <source> | Installs a source into quarantine and runs the full gate: profile → safety scan → overlap analysis → report, then prompts you to promote, hold, or reject. |
| npx @rhize/skill-forge@0.22.0 scan <source> | Runs the same gate pipeline without ever promoting — the quarantine sandbox is always cleaned up afterward, whether the scan passes or fails. |
| npx @rhize/skill-forge@0.22.0 list | Shows what's currently held in quarantine — installed, answered "hold," not yet promoted or rejected. |
| npx @rhize/skill-forge@0.22.0 status | Shows the resolved configuration (skills roots, quarantine directory, strictness) plus a count of held entries. |
First run npx @rhize/skill-forge@0.22.0 init and review the roots and target. Next run npx @rhize/skill-forge@0.22.0 scan owner/name --json. Read the report and relevant files. Only then run npx @rhize/skill-forge@0.22.0 add owner/name if the candidate is appropriate for the task.
For a local candidate, replace owner/name with its path. A nonzero scan result needs investigation; do not suppress it in CI. After installation, test a small, non-sensitive example and verify that the host loaded the intended skill.
How is Skill Forge different from npx skills add?
skills.sh already provides partner security reports and risk information during installation. Skill Forge adds a local staging decision, configured overlap checks and ongoing provenance and maintenance commands. Choose the combination that fits your workflow rather than assuming every direct installer has no safeguards.
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.
Maintain the collection after installation
Use audit --json to review configured skills and add --claude-plugins to include enabled Claude Code plugin skills. Use watch for upstream drift. A recommendation to review or an unobserved-usage label is advisory; investigate it before removing a useful tool.
The former rhize-meta plugin was removed from the marketplace. Its governance capabilities now live in this CLI, including refinement. For a targeted fix, preview a project override, activate the exact skill and test it in a fresh host task. The companion guide explains that maintenance cycle.
Free vs. Pro and licensing
The project separates the installation gate from additional curation features. Check the release's license files and Pro documentation for the exact terms. Do not assume a future major release has the same access or pricing as the current beta.
| Capability | Free | Pro |
|---|---|---|
| Quarantine install (skills.sh slug / git / local path) | Yes | Yes |
| Profile (name, version, license, structure, MCP/tool deps) | Yes | Yes |
| Safety gate — built-in ruleset + SkillSpector shell-out | Yes | Yes |
| Terminal report + --json | Yes | Yes |
| Promote / hold / reject decision | Yes | Yes |
| init setup wizard | Yes | Yes |
| Overlap analysis against your configured skill set | Yes | |
| Provenance ledger (SOURCES.md audit trail) | Yes | |
| Pending-ingestion queue + --ingest handoff | Yes |
In the checked 0.22.0 release, the documentation says Pro features are free during the 0.x beta. That is a release-bound statement, not a promise about 1.0. Verify the published package and license terms when adopting or upgrading.
When should you use it?
Use this workflow when a new skill or MCP server deserves review before it reaches your working setup. It can also inspect your own candidates for known risky patterns. Keep the task small, review the result and verify runtime behavior before granting broader access.
Frequently Asked Questions
Is this the same as the skillforge package?
Does it replace skills.sh safeguards?
Does the safety scan send content to an AI provider?
Are Pro features free?
What happens when a scan finds a HIGH or CRITICAL issue?
Release and command reference: https://github.com/Rhize-Media/skill-forge/tree/v0.22.0
skills.sh security audit announcement: https://vercel.com/changelog/automated-security-audits-now-available-for-skills-sh
Want this working in your business — not just on paper?
Book a 30-min call to talk through your workflow, ask your questions, and discuss a useful next step. No pitch, no obligation.
Book a 30-min call