The first working model

The cursor/plugins repository can now be read as one system rather than as a set of unrelated examples. The marketplace gives a capability an address, the manifest gives it a declared shape, components govern behavior, lifecycle state governs continuation, and verification determines whether a result deserves trust. This checkpoint connects those boundaries so a reader can inspect one plugin without collapsing structural validity, agent behavior, and external effect into a single claim.

The model is deliberately small. It asks five questions in order, then adds a sixth when the plugin can affect a system outside the repository. The questions do not replace the source. They tell you which source surface to inspect and what kind of confidence each surface can support.

Five boundaries, one inspection path

First, how is the capability found? The marketplace entry identifies a plugin by name and source. This is a question about discoverability and client visibility. A plugin that cannot be resolved from the catalog has no useful installed behavior, regardless of how well its files are written.

Second, what does the unit declare? The plugin manifest identifies the unit and points to its component surfaces. It can declare skills, rules, agents, hooks, variables, and MCP servers. The schema and validator can check whether the declaration has the expected shape, whether the source exists, and whether the marketplace and plugin use the same name.

Third, how does the unit change behavior? A skill can impose a procedure. A rule can choose a route or require a condition. An agent can own a delegated judgment. A hook can react to an event and change what happens next. An MCP declaration can make an external capability available. The question is not which files exist. It is which decision or transition each component owns.

Fourth, what persists or moves between turns? A hook may store an iteration number, a transcript timestamp, a pending marker, or a completion flag. An orchestration workflow may store a plan, a task state, or a handoff. This boundary tells you whether a workflow can resume, whether a retry can duplicate work, and which evidence survives after the visible response ends.

Fifth, how is success checked? The repository’s workflow plugins repeatedly point toward verification against the real artifact. A run should have a terminal result. A delegated task should return evidence. A document edit should be re-read. A generated harness should be checked against its source. A compatibility review should try startup, validation, or the documented setup path instead of inferring success from metadata alone.

A sixth question appears when the plugin reaches beyond the repository. Who authorizes the effect, and what can the provider or human still decide? At that point, structural validation is only the first layer. Identity, permissions, transport, provider behavior, and confirmation must be inspected separately.