Product teams
Separate plugin adoption from component performance so roadmap decisions are based on better evidence.
Architecture
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
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
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.
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.
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
Separate plugin adoption from component performance so roadmap decisions are based on better evidence.
Map every component to runtime behavior, errors, and version changes across harnesses.
Review the full component inventory before approving a plugin for production use.
FAQ
Related pages