Architecture

Skills, Connectors, and Tools Are Plugin Components

The plugin is the product. Skills, connectors, tools, MCP servers, hooks, commands, agents, and assets are the components that make the product useful.

Publish the product

Use Telvine when the plugin is ready to be treated like software.

The first useful milestone is simple: one plugin directory, one owner, one release record, and one measurement model.

npm i -g @telvine/cli
telvine login
telvine publish ./my-plugin

The clean layer model

A Skill describes a task-specific capability. A connector gives controlled access to a system. A tool or MCP server lets the agent take a callable action. A hook or command changes runtime behavior. Assets provide reusable context or resources.

Those are not separate products by default. They are components inside the installable plugin customers adopt.

Why the distinction matters

Without this distinction, teams end up measuring the wrong thing. They count tool calls but cannot tell which product is improving. Or they publish one Skill at a time and lose the broader customer workflow.

Telvine keeps both levels visible: the plugin as the app-level product, and the components as the execution-level surfaces.

  • Plugin: install, update, adoption, retention, version promotion.
  • Skill: invocation, error, latency, outcome, eval pass rate.
  • Connector or tool: dependency health, auth failure, action result category.
  • Hook or command: runtime availability, failure category, execution duration.

How to instrument components

Use skill.* events for SKILL.md capabilities. Use plugin.component.invoked and plugin.component.error for connectors, tools, hooks, MCP config, commands, apps, agents, assets, and other non-Skill component behavior.

Keep the event payload metadata-only. The point is to understand behavior, not to move sensitive work content into analytics.

Where it applies

Use cases that deserve a maintained plugin

Product teams

Separate plugin adoption from component performance so roadmap decisions are based on better evidence.

Engineering teams

Map every component to runtime behavior, errors, and version changes across harnesses.

Governance teams

Review the full component inventory before approving a plugin for production use.

FAQ

Common questions

Is a connector a plugin?
Usually no. A connector is a component that gives a plugin approved access to a system. The plugin is the installable product around that access.
Is a Skill a plugin?
A plugin may contain one Skill, but the Skill is still the capability and the plugin is still the product boundary.
How should non-Skill components emit telemetry?
Use plugin.component.invoked and plugin.component.error, and keep payloads limited to typed metadata.