> For the complete documentation index, see [llms.txt](https://docs.revenium.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.revenium.io/track-and-control-costs/analyze-ai-tooling-spend/ai-coding-data-reference/skill-origin-classification.md).

# Skill Origin Classification

How Revenium classifies the origin of Claude Code skills: the exact mapping from OpenTelemetry attributes to the Origin badges on the Skills page.

The **Origin** column on the Skills page tells you where each skill was loaded from. This page documents how those badges are derived from the underlying telemetry, so you can interpret them precisely.

***

## Where the signal comes from

When Claude Code activates a skill, it emits a `claude_code.skill_activated` OpenTelemetry log event carrying a small set of attributes:

| OTel attribute     | Meaning                                                                      |
| ------------------ | ---------------------------------------------------------------------------- |
| `skill.name`       | The skill's name, or a redaction placeholder when names are withheld         |
| `skill.source`     | The scope the skill was loaded from (see the mapping below)                  |
| `skill.kind`       | `workflow` for workflow skills; absent otherwise                             |
| `plugin.name`      | The owning plugin, when the skill arrived via a Claude Code plugin           |
| `marketplace.name` | The plugin marketplace the owning plugin was installed from, when applicable |

`skill.source` is the only provenance signal Claude Code reports. It has four values, and each maps to one Origin badge.

## The mapping

| `skill.source`            | What Claude Code means by it                                | Origin badge    |
| ------------------------- | ----------------------------------------------------------- | --------------- |
| `bundled`                 | Shipped inside Claude Code itself                           | **Vendor**      |
| `userSettings`            | Loaded from the developer's personal `~/.claude/skills`     | **Individual**  |
| `projectSettings`         | Loaded from a repository's `.claude/skills` directory       | **Project**     |
| `plugin`                  | Provided by an installed plugin, usually from a marketplace | **Marketplace** |
| *anything else / missing* | Source not reported or not recognized                       | **Other**       |

## How to interpret each badge

* **Vendor** — the skill is built into Claude Code. Its presence needs no action from your organization.
* **Individual** — the skill lives in one developer's personal setup. Skills your organization distributes onto developer machines (for example via managed settings) may also appear here: Claude Code reports the scope a skill is loaded from, and the telemetry has no separate "managed settings" source value.
* **Project** — the skill is committed to a repository's `.claude/skills` directory and is shared with anyone who works in that repo. This does not mean the organization sanctioned it: a skill in a personal side project classifies identically to one in your main product repo. The telemetry reports the scope only, not which repository the skill came from.
* **Marketplace** — the skill arrived via a Claude Code plugin. The Marketplace column names the marketplace the plugin was installed from, whether that marketplace is external or run by your own company.
* **Other** — the activation event did not carry a recognizable source, most often because the skill's activation could not be correlated with its cost-bearing request. Revenium re-enriches these rows when a later activation for the same skill correlates successfully.

{% hint style="info" %}
**Why is there no "Organization" badge?** Claude Code's telemetry cannot distinguish organization-sanctioned distribution (managed settings, an approved internal marketplace, a claimed repository) from an individual developer's choices within the same scopes. The badges therefore describe only what the signal establishes. Organization-level classification, where your admins claim specific marketplaces and repositories as company-owned, is on the roadmap.
{% endhint %}

## Redacted skills

Claude Code writes `custom_skill` when per-skill detail is off. It writes `third-party` on the cost record for any plugin outside Anthropic's official marketplace, whatever the setting. With per-skill detail on, Revenium recovers the real name and pairs it with the cost. Revenium keeps these as aggregate rows.

On the Skills page these appear as **Skills with details hidden** and **Plugin skills (names hidden)** rather than as the raw placeholder. When per-skill detail is off, each row links to the setup steps. When it is on, it is still possible a small number (\~5%) of skill executions can't be paired due to the way Claude sends the data. The runs and spend are real and are always counted, but each row represents many skills folded together. For that reason a redacted row never displays or matches a specific marketplace, and its provenance fields are treated as unknown.

Turning per-skill detail on is the only way to see the names behind these rows. Runs recorded before it was on stay grouped.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.revenium.io/track-and-control-costs/analyze-ai-tooling-spend/ai-coding-data-reference/skill-origin-classification.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.