See a skill the way Claude does

Drop a skill folder or .zip below. Skill Lens parses the frontmatter, splits the content into the three levels of progressive disclosure, estimates the tokens each level costs, and tells you when in a session each one is actually paid for.

Drop a skill folder or .zip here

Needs a SKILL.md at the root (or one level down). Reference files, scripts and assets are all counted.

Everything is parsed in your browser. Nothing is uploaded, stored, or sent anywhere.

Start here: how a skill actually works

No jargon. Seven short steps, and each one appears only when you ask for it — which is the exact thing skills do, so you will have felt it by the end.

A skill is just a folder you hand to Claude

Inside it is a file called SKILL.md: plain writing that says "here is how to do this particular job." It might be how your company writes a bug report, or how to deploy a site. Nothing clever — instructions, in a folder.

Claude cannot hold everything at once

There is a limit to how much text Claude can have in front of it at any moment. Think of it as a desk, not a warehouse. Everything you put on the desk takes up room, and room spent on one thing is room unavailable for another.

So skills arrive in three stages, not all at once

If you have thirty skills installed, loading all thirty in full would bury the desk before you had even asked a question. Instead each skill shows up in three stages, and most of the time only the first stage is ever paid for.

Picture a shelf of cookbooks.

Stage one: the title on the spine

Walk into the kitchen and you read every spine on the shelf at a glance — Bread, Thai Cooking, Desserts. That is all Claude gets up front for each skill: its name and its description. One line, for every skill you own, every single time.

This is the part people get wrong. A long description is a long spine label that you re-read every time you enter the room — whether or not you ever open the book. It is the one part of a skill you always pay for, so it should be short and should say plainly when to reach for this.

Stage two: taking the book off the shelf

You decide the bread book is the right one, so you pull it down and open it. Now you are reading the actual recipe — the rest of SKILL.md, the real instructions.

This only happens when the skill is genuinely needed. Which means a long SKILL.md is much cheaper than a long description: you pay for it on the runs that use it, and not at all on the runs that don't.

Stage three: the appendix you only sometimes flip to

The recipe says "for the folding technique, see page 240." You turn there only if you need it. Those are the extra files bundled with a skill — often in a references/ folder.

This is the trick that lets a small skill front an enormous amount of material. One skill on this machine has a 9KB instruction file pointing at 1.4MB of references. Almost none of that 1.4MB is ever loaded on any given run — but it is there the moment it is wanted.

With one catch: Claude only turns to page 240 because the recipe told it to. A bundled file that nothing points at is a page no one will ever turn to. That is what this tool means when it says a file is "never mentioned".

That is the whole idea

Spine, book, appendix. Always / when needed / rarely. When you drop a skill into this page, the three numbers at the top are just those three stages, measured.

And the useful question is almost never "how big is this skill?" — it is "how much of it am I paying for when I'm not using it?"

You just used progressive disclosure. This section did not dump seven steps on you at once — you asked for each one. That is precisely how Claude reads a skill, and why a well-built skill feels small even when it contains a great deal.

1 of 7

The precise version, for when you want the exact rules

Stage	What loads	When
1	name + `description`	Session start, for every installed skill
2	Everything below the frontmatter in SKILL.md	When the skill is triggered
3	Bundled files the body points at	Only when Claude opens that file

"Frontmatter" is the little block at the very top of SKILL.md fenced by --- lines, holding the name, description and similar settings.

Only name and description reach the model at stage 1. Other frontmatter keys — allowed-tools, metadata, argument-hint, user-invocable — are read by the surrounding software, not shown to Claude. This was checked by comparing skill files on disk against the skill list inside a live session's system prompt.

The same applies to hand-rolled keys like references: or resources:, which some skill libraries use to list their extra files. Those lists are useful to the tooling around Claude, but Claude itself never sees them — so a file that is only listed there, and never named in the body, is one Claude has no way to know about. This page flags those separately.

Token method & accuracy

These are calibrated estimates, not exact counts — here is exactly how they are produced, and how far off they are likely to be.

Estimate by default, exact on request. Anthropic publishes no client-side tokenizer, so these figures start as a calibrated estimate. Press Measure exactly at the top and the page asks a small server-side endpoint for a real count_tokens result, then recalculates everything from your file's own true ratio. The API key lives on that endpoint, never in this page — a key shipped in public HTML is readable by anyone who views the source.

Where the ratio comes from

Rather than guessing at the usual "about 4 characters per token", these defaults were measured: 28 real samples taken from actual skill files, 204 to 4,000 characters each, sent to Anthropic's count_tokens endpoint and fitted by least squares.

Model	Chars / token	Median error	90th pct error
Opus 5 / Sonnet 5 / Fable 5	2.65	6.5%	14.6%
Haiku 4.5	3.68	7.4%	13.5%

Opus 5, Sonnet 5 and Fable 5 share one tokenizer — given identical input they return identical counts (299/299 and 349/349 on two test strings, 222 vs 223 on a third). Only Haiku 4.5 differs, and it is notably less dense. If you have read that the Opus and Sonnet families tokenize differently, that is not true of the current 5-series.

Note how far 2.65 sits from the familiar "4 characters per token". That rule describes ordinary prose; skill files are markdown thick with punctuation, paths, code fences and YAML, all of which tokenize much denser. Measured on the same model: plain prose 2.43, markdown with code 2.31, YAML frontmatter 1.90. Content type moves the number more than the model does — which is why no single constant gets below roughly 6% median error, and why measuring your actual file beats any constant.

What this is good for. Every judgement this tool makes is a comparison — is the description too long, what share is always-on, which file dominates the bundle. Those rankings and ratios hold regardless of the exact constant, so a few percent of drift does not change any of the advice. Treat the absolute numbers as a well-grounded estimate and the relative ones as solid.

Want exact numbers?

Run the text through the API and compare against the estimate here:

# exact token count for a skill's always-on cost
curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d @- <<JSON
{"model":"claude-sonnet-4-6",
 "messages":[{"role":"user","content":"PASTE THE DESCRIPTION HERE"}]}
JSON

If you calibrate, put the measured number straight into the Chars / token box at the top — every figure on the page recalculates from it.