[FEATURE] Surface skill metadata frontmatter on skill_activated/plugin_loaded OTel events

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request

Problem Statement

marketplace.name/plugin.name on skill_activated (and plugin_loaded) OTel telemetry are only populated when a skill was installed through Claude Code's plugin system (/plugin install / claude plugin install). That attribution is sourced entirely from the plugin registry (~/.claude/plugins/installed_plugins.json).

Many skill catalogs document alternative, fully legitimate install paths that never touch that registry — in our case, the liatrio-labs/skills monorepo documents gh skill install (GitHub CLI) and npx skills add (skills.sh) alongside plugin-marketplace install. Both copy the skill's files straight into ~/.claude/skills/<name>/, which Claude Code loads via the plain skills-directory scan — indistinguishable at runtime from a hand-written personal skill.

We confirmed this is purely install-path-driven with a live before/after test: the identical skill (SKILL.md, no plugin.json), same person, same machine, same marketplace — produced skill.source: userSettings with no marketplace.name/plugin.name when copied by hand, and full, correct attribution within seconds when reinstalled via claude plugin install. Nothing else changed.

This means any catalog that supports (or documents) a non-plugin install path has usage that is permanently invisible to marketplace/plugin-level adoption telemetry, no matter how the query is written — it's a structural gap, not a counting bug.

Separately: SKILL.md frontmatter already supports a metadata field, documented as a free-form block "for entitlement or catalog fields, read by your own tooling from SKILL.md" — but Claude Code parses it and never acts on it; nothing reads it into telemetry or anywhere else today.

Proposed Solution

When emitting skill_activated (and plugin_loaded, where applicable), read the invoked skill's metadata frontmatter block and attach it — or a reserved sub-key such as metadata.marketplace / metadata.plugin — as attributes on the event, regardless of whether the skill was loaded via the plugin system or the plain skills-directory scan.

This lets a catalog self-declare its own provenance directly in SKILL.md:

metadata:
  marketplace: liatrio-skills
  plugin: brain-storm

...and have that show up in telemetry no matter which of the catalog's documented install methods a user chose. No change to install/load behavior is needed — only that already-parsed frontmatter gets attached to already-emitted events instead of being discarded.

Alternative Solutions

• Asking catalogs to standardize on claude plugin install only isn't enforceable — gh skill install/npx skills add are legitimate, tool-provided (skills.sh) install paths outside a catalog maintainer's control.
• Inferring catalog identity query-side, by matching skill.name or file hashes against a known catalog's manifest, requires maintaining and updating an external mapping per catalog and isn't robust to catalog changes — it doesn't scale past one or two catalogs an org happens to track by hand.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

1. An org publishes a skills catalog whose README documents three install methods: plugin-marketplace install, gh skill install, and npx skills add.
2. A meaningful share of users install via the CLI methods documented right in that README — not the plugin marketplace.
3. The org wants to measure real catalog adoption via OTel telemetry (e.g. in Honeycomb), grouped by marketplace/catalog name.
4. Today, only the plugin-installed share is visible; the CLI-installed share is indistinguishable from unrelated, hand-written personal skills.
5. With metadata surfaced on skill_activated, the org tags every skill in its catalog with metadata: {marketplace: <name>} once, and gets a true usage count regardless of which documented install path a given user chose.

Additional Context

Confirmed via a controlled before/after test in our own environment (happy to share further detail on the test or our telemetry setup if useful). Not requesting any change to marketplace.name/plugin.name semantics for actual plugin installs — this would be additive, aimed specifically at catalogs that support non-plugin install paths.