A Working Mental Model: Capability, Timing, and Trust

The official Claude Code plugin directory becomes easier to judge once its local pieces are viewed through one model. This checkpoint connects the marketplace, package, skills, commands, agents, and hooks around four questions: where a behavior is declared, what triggers it, when it runs, what authority it has, and what data boundary it crosses. The result is a practical judgment a reader can apply before enabling a plugin: classify the behavior first, then inspect the evidence that supports its purpose and scope.

The aim is not to repeat definitions. A plugin is a system whose risk changes as behavior moves from a description into a runtime event. A contextual skill, an explicit command, a delegated agent, and an event hook can sit in the same package but enter the session in different ways. The marketplace can record the source and provide governance signals, but the user’s decision still depends on the relationship between trigger, timing, authority, and data.

Four questions classify behavior better than component names

The first question is where the behavior is declared. A marketplace entry gives the public identity and source relationship. The plugin manifest identifies the package and may configure component paths. A SKILL.md, command, agent, hook configuration, or MCP file supplies more specific behavior. A script or bundled resource may implement details that are not visible in the short description. The declaration layer tells the reader where to continue inspection; it does not by itself tell the reader what will happen in a session.

The second question is what triggers the behavior. A skill is matched to task context. A command is selected by the user. An agent is delegated or selected for a role. A hook responds to a lifecycle or tool event. An MCP tool is called as part of a command, agent, or other workflow. Trigger visibility is a trust variable. A visible command gives the user a clear moment to choose. A contextual skill is less explicit but usually tied to relevance. A hook may be invisible at the moment it activates, so its matcher and conditions must carry more of the explanation burden.

The third question is when the behavior runs. Timing determines what information is available and what can still be changed. Before a tool call, a hook may be able to approve, deny, or modify the call. After a tool result, it can provide feedback but cannot use a warning to undo an already completed external side effect. At session start, a hook can load context for later work. At stop, it can challenge completion. A command or agent can run when requested, but the timing of the tasks it launches still determines whether they see current files, current diffs, or a changed project state.

The fourth question is what authority and data boundary the behavior has. Authority can range from adding advice to reading files, writing files, blocking a tool, changing a remote record, or invoking a service with user credentials. Data can remain in a prompt, cross into project files, reach a local process, or travel to a remote endpoint. A component’s label does not settle either question. The same “review” purpose can mean a local pattern check, an agent that reads related files, or a hook that sends diffs through a configured model path.