Event schema

Skill events use skill_id for capability drill-downs and may carry plugin_id for product roll-ups. Package-level and non-Skill component events require plugin_id and do not invent a synthetic Skill.

{
  "event_type": "skill.invocation.end",
  "plugin_id": "plg_product123",
  "skill_id": "skl_abc123",
  "version": "1.2.0",
  "installation_id": "inst_xyz789",
  "occurred_at": "2026-05-20T12:34:56.789Z",
  "idempotency_key": "uuid-v7-generated-client-side",
  "runtime": "claude-code",
  "runtime_version": "2.0.40",
  "properties": { "duration_ms": 4321, "tool_calls_count": 7, "trigger": "explicit" }
}

properties is a closed set of known keys per event type, validated at the API boundary. No user content, no tool arguments, no file paths.

event_type	properties
plugin.install	via, source?, install_context?, initial_version?
plugin.update.applied	from_version, to_version, update_source?
plugin.component.invoked	component_type, component_name, operation, duration_ms?, outcome?
plugin.component.error	component_type, component_name, error_class, blocker_reason?
skill.install	via
skill.invocation.start	trigger
skill.invocation.end	duration_ms, tool_calls_count, trigger?
skill.invocation.error	error_class
skill.script.invoked	script_name, exit_code, duration_ms
skill.reference.loaded	reference_name
skill.modified	frontmatter_changed, body_changed
feedback.submitted	rating?, comment?

If you want to emit something exotic, open an issue — we'd rather add it to the schema than have you stuff things into ad-hoc keys.

Canonical plugin component types are skill, connector, agent, sub_agent, hook, mcp_config, command, asset, tool, app, channel, model_provider, harness_adapter, runtime_component, context_engine, memory_provider, lsp_server, monitor, executable, settings, theme, and output_style. Component operations are closed too: use invoked, executed, tool_called, connected, configured, loaded, registered, started, completed, enabled, or disabled.