> 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

When an organization disables per-skill telemetry detail (`OTEL_LOG_TOOL_DETAILS=0`), Claude Code reports placeholder names instead of real skill names: `custom_skill` on the activation event and `third-party` on the cost-bearing request. 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. Each row names the setting that is withholding the skill name, and confirms that its cost, run and user counts are correct. 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 back on is the only way to see the individual names behind these rows. The Skills page links to the instructions for doing so.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.