plugins

The plugin catalog for Verdict — one marketplace, every toolkit.

This repo is a catalog and nothing else. Each plugin is its own repository, with its own tests, docs, and release cycle; this is the single place that lists them, so runverdict-plugins resolves to exactly one authority.

Table of Contents

• Install
• The plugins
• Why a separate repo
• Adding a plugin
• Caveats
• License

Install

Add the marketplace once, then install whatever you want from it:

claude plugin marketplace add runverdict/plugins
claude plugin install repo-standard-toolkit@runverdict-plugins
claude plugin install sf-security-review-toolkit@runverdict-plugins

You add the repo (runverdict/plugins) but install from the marketplace name (@runverdict-plugins). They differ on purpose: the name comes from the name field inside .claude-plugin/marketplace.json, never from the repo it lives in — which is also why claude plugin marketplace remove runverdict-plugins takes the name, not the source you added.

Already added an older per-repo marketplace? Just run the marketplace add above. It registers under the same runverdict-plugins name, replacing the stale pointer, and your existing installs keep resolving because no plugin names changed.

The plugins

Plugin	What it does	Repo
repo-standard-toolkit	Scaffold README, CHANGELOG, and community health files from published standards (Keep a Changelog, standard-readme, Contributor Covenant), then keep them true: a committed, dependency-free lint + CI gate — and an optional required-check ruleset — that run without Claude.	runverdict/repo-standard-toolkit
sf-security-review-toolkit	End-to-end AppExchange/AgentExchange security review preparation: autonomous codebase audit, submission artifacts, scan orchestration, test-environment runbooks, and an honest readiness verdict.	runverdict/sf-security-review-toolkit

Only publicly installable plugins are listed here, and that is enforced rather than promised: acceptance/test-catalog.mjs fetches every listed plugin's manifest anonymously on every push, so a private or unreachable repo fails the build. A catalog that lists something you cannot install is worse than no catalog — it fails in your terminal, with our name on it. More Verdict toolkits exist and are listed here as each one is proven and made public.

Why a separate repo

A marketplace name is a global key, once per user: registrations live in ~/.claude/plugins/known_marketplaces.json, keyed by the bare marketplace name — not per project, not per repo — and claude plugin marketplace add registers whatever catalog that name resolves to. Only one marketplace can hold a given name at a time. So the name needs exactly one authority.

When two repos each shipped their own marketplace.json claiming runverdict-plugins and listing only themselves, adding the second one replaced the first — and every plugin installed from the first stopped resolving (✘ failed to load). Two repos cannot both be the catalog for one namespace. This repo is that catalog; the plugin repos ship a plugin.json and no marketplace of their own.

The name is deliberately plugins, not claude-plugins: the Claude Code catalog lives under .claude-plugin/, which already namespaces it, leaving room for other ecosystems to be catalogued here later without renaming anything.

Adding a plugin

1. The plugin's repo is public and ships .claude-plugin/plugin.json (CI checks both, anonymously).
2. Add a row to .claude-plugin/marketplace.json with a github source: {"source": "github", "repo": "runverdict/<name>"}. Optionally pin it with ref (a release tag) or sha; left unpinned it tracks the repo's default branch. Never add a version — the plugin's own plugin.json owns that and silently wins over anything set here, so a value here could only ever be a lie. CI enforces this.
3. Add a row to The plugins — CI fails if the table and the JSON disagree.
4. claude plugin validate --strict . then node acceptance/test-catalog.mjs — green means a stranger can install it. CI runs both: the validator for schema and source shape, the acceptance test for the thing it cannot check, which is whether the entry actually resolves for someone who is not us.

Version discipline

The version string in a plugin's plugin.json is what ships a release. Installs are cached per version (~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/), so pushing commits without bumping it changes nothing for anyone already installed — they stay pinned to what they have. Bump it in the same commit that cuts the release; each plugin's own CI is where that gets enforced.

claude plugin marketplace update refreshes the catalog, not an installed plugin's files. To pick up a change at the same version (dev loop only), uninstall and reinstall.

Caveats

This repo holds no code, no skills, and no plugin of its own. Its tests check that the catalog is well-formed and that everything in it publicly resolves — nothing about whether a listed plugin is any good. That is each plugin's own business, gated in its own repo.

License

Apache-2.0 © runverdict. See LICENSE.