What a Marketplace Must Govern

The marketplace around knowledge-work-plugins changes the trust problem. A plugin is no longer only a workflow an author designed for one team; it is also a package that may be installed from a local path, a subdirectory of another repository, or an external source. This chapter focuses on what that distribution boundary must govern: the complete shipped payload, its provenance, its network and hook behavior, and the action rules that remain specific to each package. The reader’s practical judgment is that catalog membership is not the same as package-level trust.

Installation ships more than the visible skill

The repository’s marketplace policy asks reviewers to inspect the whole payload that installation makes available. That includes the manifest and MCP configuration, but also skills, agents, commands, hooks, scripts, examples, tests, hidden directories, and dormant code. A file does not need to be automatically loaded in the first interaction to matter. If it ships with the package and an agent can be led to run it, it belongs to the trust boundary.

This is a different boundary from the active context surface. Progressive disclosure intentionally keeps some references out of the immediate interaction. Marketplace governance must take the opposite view: an unloaded resource is still part of what the user is accepting. The two principles are compatible. Progressive disclosure manages attention during normal use; full-payload review manages what installation makes reachable.

The policy’s concern is not limited to obviously malicious code. It asks whether a plugin observes more user data than its stated purpose justifies, whether its description discloses what it actually does, and whether its instructions try to circumvent other controls. A harmless-looking skill can still be inappropriate if it reads unrelated files, watches every tool call, sends undisclosed telemetry, or presents a connector with a broader data scope than the user expects.

The marketplace registry makes the supply boundary visible. In the checked snapshot, entries may point to a local path, a GitHub URL, or a git-subdir source. They may carry a publisher, category, homepage, and pinned commit SHA. The local checkout contains 225 skill files, 15 legacy command files, five agent definitions, and 21 MCP configurations, while the registry extends beyond the local packages with partner and external sources. Those counts describe one repository snapshot, but they show why the review surface grows as the catalog grows.

flowchart LR P["Publisher or source"] --> M["Registry metadata"] M --> F["Full shipped payload"] F --> R{"Security and privacy review"} R -->|passes| I["Installation"] R -->|fails or needs change| X["Reject or remediate"] I --> T["Connectors and hooks at runtime"] T --> U["User and organization oversight"]

Metadata helps a user establish provenance, but it does not substitute for inspection. A pinned SHA can make it easier to identify the revision that was selected. It does not prove that the revision is safe forever, that the remote connector remains compatible, or that the package’s behavior matches the description.