Claude Code Skill Governance: The rhize-meta Plugin

rhize-meta is a Claude Code plugin that governs a skill set over time: it decides what external skills are safe to adopt and keeps the skills you already own accurate as they get used. It ships two skills — rhize-skill-forge for vetting inbound candidates and skill-refinement for patching your own skills from real usage feedback.

We built rhize-meta because a Claude Code skill set is a living thing, not a folder you fill once. This article is part of our series on Rhize plugins for Claude Code — here we go deep on the one plugin whose entire job is managing every other skill you install.

What is the rhize-meta plugin?

rhize-meta is Rhize Media's meta-skills plugin — the tools that manage the Rhize skill set itself, rather than tools for any one domain task. Commands namespace as /rhize-meta:<command>. It bundles two skills, rhize-skill-forge and skill-refinement, that together decide what comes in from outside and keep what's already yours sharp.

Every other plugin in the marketplace does something for you — SEO audits, Obsidian notes, project scaffolding. rhize-meta is different: it's aimed at the skill set as an object in its own right. If you've ever found a promising skill on GitHub and wondered whether it's safe to run, or watched a skill you wrote quietly misfire the same way for weeks because nobody got around to fixing it, that's the gap rhize-meta closes.

What problem does it solve?

Left unmanaged, a growing skill set drifts toward one of two bad states: bloated with half-vetted external skills nobody fully checked, or stagnant because the false positives everyone's quietly working around never get fixed. rhize-meta addresses both — one skill gates what comes in, the other keeps what's already yours accurate.

Those two failure modes have different root causes, so rhize-meta treats them as two different jobs rather than one generic "manage skills" catch-all. Adopting an external skill is a due-diligence problem — you need to know what it does, whether it's safe, and whether it duplicates something you already have. Fixing your own skill is a feedback problem — something didn't do what you expected, and that gap needs to become a tracked, reviewable patch instead of a workaround someone remembers by hand. Rhize-meta's own docs put it simply: if the skill in question doesn't exist in your set yet, that's forge; if it's already yours and behaving badly, that's refinement.

What skills does rhize-meta ship?

rhize-skill-forge activates on language like "should we adopt," "ingest," "absorb," "evaluate," "steal the good parts of," "vendor," or "import," in reference to an external skill, plugin, or MCP server — and also for drift checks like "did upstream change?" on things you've already absorbed. skill-refinement activates when a skill "doesn't work," "should have caught," "missed," produced a "false positive/negative," or when you ask to "improve/extend/add to" a skill you already own; it also fires automatically after long or error-heavy sessions to check whether something's worth capturing.

Forge doesn't operate in isolation from refinement. When forge decides to ABSORB the good parts of an external skill rather than adopting it whole, it hands the extraction off to skill-refinement's patch machinery instead of hand-merging code — that's what keeps the change tracked, generalizable, and reversible. Forge is the one deciding what needs fixing; refinement is the mechanic that does the fixing.

How does the forge pipeline work?

rhize-skill-forge runs candidates through a five-step pipeline — profile, decide, execute, verify, record — landing on one of five outcomes: adopt as-is, absorb the good parts, fork and reskin, reject, or watch. Nothing sticks until it clears a two-layer safety gate and is proven better than what you already have, not just assumed to be.

The pipeline, command by command:

The safety gate has two layers, and only one of them is mandatory. Safety scanning via NVIDIA SkillSpector needs no Vercel account — install it once from github.com/NVIDIA/skillspector (Python 3.12+), and static scanning runs with no API key at all (an optional LLM stage takes an OpenAI, Anthropic, or NVIDIA key). This is the core, always-available gate, and it blocks on HIGH or CRITICAL findings — no exceptions. Discovery via skills.sh is optional and authenticates with a Vercel OIDC token: teams set up one empty Vercel project with OIDC Federation enabled as an auth anchor (it deploys nothing), then each developer runs vercel link and vercel env pull. Clients without Vercel still get the safety gate; discovery is simply opt-in on top of it.

The key discipline forge enforces: it never adopts on trust. Every DEFER, ABSORB, or FORK has to clear the safety scan and a license check, and every absorbed or forked result has to be proven better than the baseline skill it's replacing — not just assumed to be. Skip that verification step and you haven't adopted a skill, you've added bloat with extra confidence.

How does skill-refinement turn feedback into a fix?

skill-refinement gathers context on the misbehaving skill — git status, existing overrides, similar past refinements, session or error history — then converts "expected X, got Y" into one of four patch types: a section patch, an extension, a config override, or a full rewrite, previewed before anything is written.

Refinements start scoped to your current project, deliberately. A one-off fix stays a one-off fix until the exact same pattern recurs in a second, different project — repeating it in the same project doesn't count. Once it does recur, /rhize-meta:review-patterns flags the pattern as ready for generalization (it tracks patterns at count 1, patterns ready at count ≥ 2, and patterns already generalized, filterable by --status, --skill, or --project), and /rhize-meta:apply-generalization [PATTERN-ID] promotes it from a project-local patch to the new user-scope default — showing the affected files and diff first, backing up existing files, and supporting --dry-run and --rollback if a generalization turns out wrong. That staged path is what keeps a bad or overly-specific patch from contaminating every project by default.

Override precedence matters if a patch doesn't seem to take effect: project-local (./.claude/skills/[skill]/) beats project-shared, which beats user-scope. If the behavior doesn't change after a refinement, check whether a narrower override is shadowing the fix you just generalized.

How does rhize-meta relate to the skill-forge CLI?

rhize-skill-forge (the Claude Code skill) and the separate skill-forge command-line tool work together but aren't the same thing. The CLI can quarantine and gate external skill candidates on its own, writing them to a pending queue; running /rhize-meta:forge-ingest with no argument drains that queue and runs each candidate through the full plugin pipeline.

The standalone CLI is @rhize/skill-forge, the npm package that does supply-chain-style vetting outside of a Claude Code session — see Skill Forge npm package for the full rundown of what it does on its own. Inside rhize-meta, it's an upstream feeder: nothing lands in your skill set just because the CLI quarantined it, since a queued entry still has to go through forge's own profile → decide → execute → verify → record steps and clear the same safety gate as any other candidate.

Example prompts

Who is rhize-meta for?

rhize-meta is for anyone maintaining a Claude Code skill set that's meant to grow over time — deciding whether to adopt something new, or fixing something that keeps misbehaving. If your skill set is static and small, or you never pull in skills from outside your own team, you likely won't reach for it often; its value compounds as the set does.

Practically, that means teams running a shared marketplace (internal or public), anyone who regularly evaluates skills.sh candidates or GitHub repos before installing them, and anyone who's noticed the same false positive or missed trigger keep showing up across projects without a system to promote the fix. /rhize-meta:skill-doctor is the right first command — it confirms SkillSpector is installed and, if you want skills.sh discovery, that your Vercel OIDC token is present — before your first real forge session.

Getting rhize-meta

Install the marketplace with /plugin marketplace add https://github.com/Rhize-Media/rhize-plugins in Claude Code (or Settings > Plugins > Add Marketplace in Cowork), then /plugin install rhize-meta@rhize-plugins. Run /rhize-meta:skill-doctor right after install to confirm the safety tooling is wired up before you run your first forge-scan or forge-ingest.

rhize-meta was promoted out of the rhize-devflow plugin so the coupled skill-governance toolchain — forging new skills and refining existing ones — lives in one place instead of being split across plugins. For the full catalog of what else ships in the marketplace, see Rhize plugins for Claude Code.