TokenPad
Building

AI Skill File Builder

Write a valid skill definition, validated as you type.

Skill definition

Always in context: 0 tokens on every request, whether the skill fires or not.

Validation6 / 6
0tokens in file
Always in context0
Loaded on trigger0
Name is a valid slug
Description is substantial
Description states a condition
At least three trigger phrases
Body is not empty
Body is a reasonable size

Stored in your browser only — no account, nothing uploaded.

token-cost-review.md
---
name: token-cost-review
description: "Use when the user asks to review an LLM prompt for cost, reduce token usage, or estimate what a prompt will cost per month."
triggers:
  - "reduce token cost"
  - "why is my prompt expensive"
  - "estimate api cost"
  - "optimise prompt"
---

# Token cost review

## When to use
The user has a prompt or payload and wants it cheaper.

## Steps
1. Count the prompt with the real tokenizer, not a character estimate.
2. Identify structural waste: indentation, repeated keys, base64 blobs.
3. Report tokens saved and the monthly value at their request volume.

## Rules
- Never strip spacing between words; it raises the count.
- Always state whether the count is exact or an estimate.

What a skill file is

A markdown file with YAML frontmatter that packages a reusable capability for an AI assistant. It has a name, a description that determines when it fires, and a body of instructions loaded only once it does. The format is convention rather than standard, but the conventions are consistent enough across the tools that use them to be worth validating against.

The economics are the interesting part, and they are why this tool counts tokens in two places. The description is always in context — it is what the model matches against to decide whether to load the skill at all. The body is loaded only on a match. Get that split right and a skill is nearly free until it is needed.

The description is the whole skill

This is the mistake worth avoiding above all others: writing the description as a title instead of a condition.

  • Weak: "A tool for reviewing prompts." Describes what it is. Matches almost nothing, because users do not phrase requests that way.
  • Strong: "Use when the user asks to reduce token usage, understand why a prompt is expensive, or estimate monthly API cost." Describes when, in the words a user would actually type.

The validator checks for this specifically, because a skill with a vague description does not fail loudly — it simply never fires, and you conclude the mechanism does not work.

Trigger phrases

Three or more, written as the literal words a user would type, not as topics. "why is my prompt expensive" beats "cost analysis". Include the phrasings you personally would not use — the point is coverage of how other people ask, and your own vocabulary is the one case already handled.

How large should a skill be?

Small enough that loading it is cheap, large enough that it is worth loading. The token readout is the guide, and the practical threshold sits around 3,000 tokens in the body.

Past that, it is usually two skills wearing one file. Splitting means the model loads only the half it needs, and each half gets a description precise enough to match properly — a large skill almost always has a description vague enough to cover everything inside it, which is exactly the failure described above. Measure the body against every model in the token counter if you are near the line.

Writing the body

The body is read only after the model has already decided to use the skill, so it does not need to sell itself. It needs to be operational:

  • Steps, in order. Numbered, imperative, one action each.
  • Rules and prohibitions grouped together. Same reasoning as a system prompt — grouped constraints are followed more reliably than scattered ones.
  • Concrete examples over abstract description. One worked example usually replaces three paragraphs, and costs less.
  • No preamble. "This skill helps you…" is tokens spent telling the model something it already concluded by loading the file.

Skills against agent configuration

The two solve the same problem at different costs. Instructions in an agent’s system prompt are paid for on every request forever; instructions in a skill are paid for only when the skill triggers. So the rule is straightforward: anything needed on most requests belongs in the system prompt, and anything needed occasionally belongs in a skill.

Teams get this backwards constantly, stuffing rare edge-case handling into a system prompt because it is the obvious place to put it. Price both sides — the agent builder shows the per-request overhead of the configuration, and the system prompt analyzer shows the annual cost of each paragraph you leave in.

Frequently asked questions

What is a skill file?
A markdown file with YAML frontmatter that packages a reusable capability for an AI assistant: a name, a description that determines when it is invoked, and a body of instructions loaded only when it triggers. The format is convention rather than standard, and the conventions are consistent enough to validate.
Why does the description matter more than the body?
Because the description is what is always in context, and it is what the model matches against to decide whether to load the skill at all. A vague description means the skill never fires, or fires constantly. A description that names concrete triggers — the words a user would actually type — is the difference between a skill that works and one that sits unused.
What does the validator check?
That the name is a valid slug, that the description exists and is specific rather than generic, that trigger phrases are present, and that the frontmatter is parseable YAML. It also flags the two most common failures: a description written as a title instead of a condition, and a body long enough to be worth splitting.
How large should a skill be?
Small enough that loading it is cheap, large enough that it is worth loading. The token readout here is the guide: if the body runs past a few thousand tokens, it is usually two skills, and splitting it means the model loads only the half it needs.

More building tools