TokenPad
Building

AI Skill Generator

Pick what the skill does, get a valid file with triggers that fire.

1 · Pick a starting point
2 · Make it yours
What you get
0tokens
Characters1,078ready to paste
Cost per request$0.00as input
× 100K requests$0.00if sent every time

Why this shape

Review skills fail when the description reads as a title. This one states a condition and names the words a user would actually type, which is what decides whether the skill ever loads.

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

Generated skill
---
name: prompt-review
description: "Use when the user asks to review, critique or improve an LLM prompt, or asks what is wrong with one."
triggers:
  - "review my an LLM prompt"
  - "what is wrong with this"
  - "how can I improve this"
  - "critique this"
---

# Reviewing an LLM prompt

## When this applies
The user has an LLM prompt and wants it assessed, not rewritten. If they asked for a rewrite, do that instead.

## Criteria
Check each of these in order:
output format specified, constraints grouped, no boilerplate

## Steps
1. Read the whole thing before commenting on any part of it.
2. Check each criterion and note whether it is met, with the specific text that decided it.
3. Rank findings by impact, not by order of appearance.
4. State what is already good in one line. A review that only lists problems is harder to act on.

## Rules
- Every finding must quote the text it refers to.
- Do not report style preferences as defects.
- If nothing is wrong, say so plainly rather than manufacturing a finding.
- Suggest the smallest change that fixes each issue.

What comes out

A complete skill file: valid YAML frontmatter, a description written as a condition rather than a title, trigger phrases in the words a user would actually type, and a body of numbered steps and rules.

The token readout splits the two halves, because they have different economics. The description sits in context on every request whether or not the skill fires; the body loads only when it does.

The description is the whole skill

This is the mistake that makes skills fail, and it fails silently — a skill with a vague description simply never triggers, and you conclude the mechanism does not work.

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 review, critique or improve a prompt, or asks what is wrong with one.” Describes when, in the words someone would type.

Every blueprint here writes the description in the second form and generates triggers to match.

The three shapes

Review applies fixed criteria to something the user already has. Its defining rule is that every finding must quote the text it refers to, which stops the output becoming a list of opinions.

Generate produces an artefact to a house standard. The body is a checklist the model applies rather than instructions it interprets, which is what makes output consistent between runs.

Diagnose works causes in order of likelihood. This is the highest-value shape, because the alternative is the model guessing — and ordering by likelihood is what makes it faster than the user searching themselves.

When something belongs in a skill

The rule is about frequency, not importance. Anything needed on most requests belongs in the system prompt. Anything needed occasionally belongs in a skill, where its body is paid for only when it triggers.

Teams get this backwards constantly, because the system prompt is the obvious place to put a fix. The prompt splitter finds the conditional sections in a prompt you already have and shows what extracting them would save.

After you generate

Open it in the skill builder to edit with live validation, and save it to your library. If the body runs past roughly three thousand tokens, it is usually two skills — splitting means the model loads only the half it needs.

Frequently asked questions

Why does the description matter more than the body?
Because the description is always in context and is what the model matches against to decide whether to load the skill at all. A description written as a title matches nothing, and the skill silently never fires — which is the most common way skills fail.
What makes these triggers better than mine?
They are phrased as the words a user would actually type rather than as topics. "What is wrong with this" beats "code quality analysis", because nobody types the second one.
How big should the body be?
Under about three thousand tokens. Past that it is usually two skills, and splitting means the model loads only the half it needs — plus each half gets a description precise enough to match properly.

More building tools