Governance Before and After Installation

The official plugin directory governs more than whether a folder has the right shape. Its workflows check structure, frontmatter, licenses, endpoint liveness, policy behavior, and compatibility across updates. This chapter separates those controls and follows them through a plugin’s lifecycle. The practical judgment is what each check can establish, what it leaves open, and why several narrow controls are more informative than one generic “approved” label.

Governance matters because the runtime behaviors described earlier begin before a user invokes a command. A marketplace source can change. A plugin name can break an existing installation. A hook can be described too narrowly. An MCP URL can disappear. A license can be missing. These failures have different causes, so they need different evidence and different owners. The repository’s control system is strongest when it keeps those categories distinct.

One approval cannot cover several failure types

A structural failure is not a licensing failure, and neither is the same as an unsafe data flow. The repository’s validate-plugins workflow runs a shared validator when relevant manifests, component directories, MCP configurations, hooks, documentation, policy files, or workflow files change. It is configured as a required check and uses a SHA-pinned validation action. This control answers questions such as whether a marketplace entry and plugin structure conform to the expected schema and whether changes that affect the loading surface trigger validation.

Frontmatter validation targets a different boundary. Agents, skills, and commands use Markdown with YAML frontmatter, and a malformed description or field can prevent a component from loading or make its trigger behavior ambiguous. The frontmatter workflow identifies changed files and runs a parser against them. It also avoids validating fork pull requests in that job, protecting the shell steps from untrusted filenames while a separate contribution policy decides what outside changes are in scope.

Licensing is another distinct contract. The license workflow checks that every internal plugin ships a LICENSE file and expects Apache 2.0 text except for the documented proprietary claude-security exemption, which must still have a license. This does not assess runtime security or code quality. It answers whether the package carries the required legal artifact and whether an intentional exception is visible rather than silently inconsistent.

Endpoint liveness is narrower still. The MCP URL workflow discovers HTTP and SSE URLs declared by plugins whose files live in the official worktree. It first probes the endpoint and can retry with a JSON-RPC initialization request when a simple HEAD receives a response such as 404 or 405. It treats a range of auth, method, and server errors as evidence that a host is reachable, while failing on connection-level errors or endpoints that return 404 or 410 as gone. This is a useful operational distinction: an endpoint can reject an unauthenticated probe and still be alive.

But liveness is not trust. A response proves that a host and path answered a request.