What a plugin can teach, trigger, and connect
The cursor/plugins repository gives a plugin several ways to influence an agent, and those ways are not interchangeable. This chapter distinguishes skills, rules, agents, hooks, and MCP connections by the kind of control they exert. The goal is practical. When you open a plugin manifest, you should be able to tell whether you are reading a procedure, a routing constraint, a delegated role, a lifecycle trigger, or a path to an external capability.
The distinction matters because a plugin can combine several of these parts. Google Docs pairs an MCP server with a skill. Shopify uses a rule to route requests between connected-store tools and developer-oriented skills. Advisor combines a skill, an agent, and hooks. Treating all of those files as “instructions” hides the difference between something an agent reads on demand and something that changes what happens at a lifecycle boundary.
Skills make a procedure reusable
A skill is the component most directly concerned with how an agent should work through a task. It carries frontmatter that gives the host a name and description, then supplies a procedure with triggers, prerequisites, workflow, guardrails, and output. That structure lets a skill be specific without becoming a general-purpose system prompt.
The repository’s examples show several kinds of procedural knowledge. The CLI-for-agents skill says that a command should accept flags instead of requiring a hidden interactive dialogue, expose layered help with examples, return actionable errors, support safe retries, and offer dry-run behavior for destructive operations. This is not a command implementation. It is a reusable way to reason about the boundary between a CLI and an agent.
The Origin API skill uses a different kind of procedure. It tells the agent to read the live documentation index and relevant contract sections rather than naming endpoints, scopes, headers, or limits from memory. The procedure is partly about retrieval discipline. Its value comes from controlling when a claim can be made, not from adding another endpoint list to the agent’s context.
Google Docs turns the same principle into editing behavior. It tells the agent to locate fresh text ranges before applying styles, to avoid stale positional indexes, and to re-read after changes that affect structure. The skill therefore mediates between a natural-language request and a tool whose indexes shift after writes. The tool exposes an operation. The skill supplies the sequence that keeps the operation from being misapplied.
A skill can also shape the representation a human sees. PR Review Canvas groups a change by reviewer value instead of file-tree order. Docs Canvas calls for an overview, navigable contents, logical sections, and references. In both cases, the component changes the route from question to understanding. It is still procedural, but its output is a more inspectable review or explanation rather than a modified external record.
Rules decide which path applies
A rule is useful when the main problem is not how to perform one operation, but which operation or capability belongs in the current situation. Rules can be always applied or can provide routing and boundary guidance that a skill or tool alone would not know.
The Shopify rule makes the distinction concrete. If the user asks about their own store data or changes, the connected-store MCP tools are the relevant surface. If the user asks how to build on Shopify, the toolkit skills are the relevant surface when available. The rule also says to read before writing and to confirm before write tools. It does not create the store capability. It selects the capability and adds a condition around its use.
This separation is important in a composable marketplace. Installing two related plugins can create overlapping routes. A tool may be present, but presence does not answer whether it should be called for this request. A rule can reduce that ambiguity by naming the subject of the request and the boundary that applies. It can also prevent a tempting fallback. The Shopify rule says not to use web search as a substitute for a missing connection to the user’s store data.
A rule is not a permission system. It is an agent-facing constraint. If the provider rejects a call, the rule cannot override that result. If the agent ignores the rule, the rule alone may not prevent a side effect. Its contribution is earlier in the decision path. It makes the intended route and the condition for using it explicit, which gives a reviewer something concrete to inspect.
Agents own delegated judgment
An agent component represents a role that can be delegated work. The repository’s authoring plugin includes a plugin-architect agent for choosing a component mix and manifest shape. Advisor includes a read-only advisor subagent that examines a briefing and returns a verdict with guidance. These are different from adding more paragraphs to a parent skill because the delegated role has its own scope, output, and relationship to the main agent.
That separation protects both reasoning and context. A parent workflow can ask a specialist to inspect a question without absorbing every intermediate thought into the main task. A read-only reviewer can challenge a plan without editing the repository. A plugin architect can focus on component responsibility rather than executing the implementation. The agent boundary is therefore a way to keep judgment attributable. The parent still decides what to do, but the delegated role supplies a distinct piece of evidence or design work.
Delegation only helps when the role is bounded. A vague agent that “helps with everything” adds another source of ambiguity. The authoring guidance instead asks for a concrete goal, users, component mix, and implementation checklist. The role should make it clearer who owns a decision, what the delegate returns, and how the parent can verify it.
Hooks turn instructions into lifecycle behavior
A hook is triggered by an event rather than by a reader deciding to invoke a skill at the moment of need. That difference introduces state and time. Ralph Loop registers an afterAgentResponse hook to detect a configured completion promise and a stop hook to feed the original prompt back into the next iteration. The stop hook checks the stored iteration, completion flag, and maximum limit before continuing. The loop ends when the promise is fulfilled, the limit is reached, or the state is invalid.
Continual Learning shows why a lifecycle trigger needs more than a single condition. Its stop hook counts completed turns, tracks transcript modification time, stores cadence state, and uses different thresholds during a bounded trial window. It avoids repeating work for the same generation and emits a follow-up only when the turn, time, and transcript conditions align. Advisor uses file-edit and response events to mark pending work, records completed consultations, and nudges the main agent at stop time when edits remain unreviewed.
The common mechanism is event, state, decision, and follow-up. The hook receives an event. It reads state that may have survived the previous turn. It decides whether the conditions for action are met. It writes updated state and may emit another message. A hook that skips the state or stop condition can turn a helpful workflow into an unbounded loop, duplicate a memory update, or nag at the wrong time.
This is why hooks should be treated as control logic. They are small, but they sit at a powerful boundary. They can continue work after the agent’s visible response, alter what happens at stop time, or create a durable record. Their design needs duplicate protection, bounded retries or iterations, and a quiet path when the event does not qualify.
MCP connects the component to a capability
An MCP declaration gives a plugin a way to expose an external capability to the host. The manifest can point to an MCP configuration, while the README explains setup and the skill, if present, explains when and how to use the tools. Many integrations use only this connection layer. Others pair it with guidance because a connection without a procedure leaves the agent to infer too much.
The combination in Google Docs illustrates the division. The MCP server gives the host access to document operations. The skill teaches the agent how to locate fresh ranges, structure a document, apply formatting, and verify the result. One is the capability boundary. The other is the behavioral boundary around that capability.
The same split appears in Origin Apps. The skill does not pretend to be the live API. It directs the agent to the current specification, names the rules to check first, and separates planning a port from writing code. The connection between procedure and external contract is explicit, but the procedure does not replace the external source of truth.
A plugin can therefore be thought of as a set of control surfaces with different timing. A skill influences a task when the agent loads it. A rule influences routing whenever its condition applies. An agent owns a delegated piece of judgment. A hook reacts after an event and may persist state. An MCP server supplies operations at the moment of use.
The diagram is useful only if the relationships remain distinct. A rule is not an MCP server. A hook is not a second agent. A skill can describe how a tool should be used, but it does not become the provider that enforces the tool’s permissions. The component model is compositional precisely because each part has a narrower job.
One request can cross several component boundaries
Imagine a request about a connected store. The rule first identifies whether the user wants store data or developer guidance. If the request concerns the user’s own products or inventory, the rule routes it to the store tools. If the request concerns how to build a Shopify application, the rule routes it to the toolkit skills instead. The same plugin bundle contains both routes, but the request determines which capability is relevant.
If the selected path includes a write, the rule adds another condition. The agent should read the current state first and confirm what will change before calling a write tool. That confirmation is not the same as permission from the provider. It is a human-control step in the agent’s reasoning path. The provider still decides whether the authenticated account can perform the operation, and the runtime still decides whether the tool is available.
Now compare that with a document-editing request. The MCP connection supplies document operations, while the skill controls how the agent locates text, applies a change, and re-reads the document after structure shifts. The failure mode is different from the store case. The main danger is not choosing the wrong product surface, but applying a correct operation to a stale range. In both cases, the component mix carries the reasoning that the raw capability cannot supply by itself.
This example also shows why component boundaries should be read as a sequence of decisions rather than a list of files. The rule determines the route. The skill determines the procedure. The tool performs the operation. The provider or document system returns the result. The agent verifies what happened. The components are valuable because they assign those decisions to visible places.
Why a focused mix beats a maximal bundle
The authoring workflow asks for a focused use case and a selected component set. That constraint is an architectural advantage. Every additional component adds another place where identity, state, routing, or documentation can drift. A plugin with one clear skill may be easier to invoke and verify than a plugin that includes unrelated agents, hooks, and external connections merely because the schema allows them.
A focused mix also makes failure easier to localize. If a procedure is wrong, inspect the skill. If a request is routed to the wrong tool, inspect the rule. If a consultation is not recorded, inspect the hook and its state. If a tool cannot connect, inspect the MCP configuration and provider setup. The boundaries do not remove complexity, but they keep complexity attached to the responsibility that owns it.
That is the real value of the component vocabulary. It lets a reader ask not only what a plugin contains, but what kind of influence each part has and when that influence takes effect. The next step is to follow those influences over time. Once components can trigger work, persist state, or delegate judgment, a plugin stops looking like a static bundle and starts looking like a managed agent loop.