Using Claude Skills to Reduce Token Usage

I had a CLAUDE.md file that was doing three jobs at once — SEO writing guidelines, a code review checklist, a deployment runbook — all stitched into one file because that’s where “instructions” go, right? Every session loaded all three, whether I was writing a blog post or fixing a typo in a config file. Three unrelated documents, paid for on every single turn.

Skills are the fix, and the trick is almost embarrassingly simple once you see it: a one-line description stays in context always (small, unavoidable — Claude needs to know a skill exists before it can decide to use it), and the actual body — checklists, templates, reference tables — only gets read when the task genuinely calls for it. The expensive part becomes conditional. Claude Code’s own docs cover the mechanics of how and when a skill gets loaded, if you want the full reference.

1. Write tight, specific descriptions

The description is the only always-on part, so it earns its keep twice over: short enough not to matter, specific enough that Claude reaches for it at the right moment and doesn’t reach for it otherwise.

---
name: seo-content-writer
description: Use when the user asks to "write SEO content"; drafts posts, articles, and landing pages with keywords, headers, and evidence boundaries.
---

A vague one (“helps with writing”) either gets ignored or gets invoked for tasks it has no business touching — both waste tokens, just at different ends.

2. Push detail into linked files, not the main body

A skill’s main file should read like a table of contents with instructions, not the whole manual inline.

## Reference Materials
- [Title Formulas](references/title-formulas.md)
- [Content Structure Templates](references/content-structure-templates.md)

Claude only opens these if the task needs that specific detail. A listicle-writing task never has to touch the comparison-article template — that content never enters context at all.

3. Split, don’t consolidate

Tempting to build one “engineering skill” covering testing, deployment, code review, and docs. Don’t. Every time any part of it is relevant, Claude has to weigh loading the whole thing, and overlapping scope makes relevance harder to judge from the description alone — which is the one piece of the skill it can actually see up front.

Narrower skills, each with a precise description, cost less because only the one you actually need gets pulled in. This is the same reasoning behind keeping a single Claude Code session scoped to one task instead of one sprawling thread that drifts across three unrelated things.

4. Avoid unconditional file reads inside a skill

“Always read the full API reference before responding” costs the same every time the skill fires — even for a question about one endpoint. Point Claude to search or read narrowly within the reference material, the same discipline you’d want from it in any other task.

5. Let skills replace repeated context, not add to it

The strongest case for a skill is one that replaces something you were already re-typing into every new chat — your commit message format, your brand voice, your PR checklist. If you’re pasting the same paragraph of instructions into every conversation, that paragraph is a skill waiting to happen: fixed cost once (the description), instead of re-sent in full every time from your own message history.

Key lessons learned

• The always-on cost of a skill should be tiny (a name and a description); the expensive part should be conditional.
• Narrow, specific skills beat one sprawling do-everything skill, both for token cost and for Claude actually picking the right one.
• If you’re retyping the same instructions into every chat, that’s the tell — turn it into a skill instead.

If any of your skills touch frontend work — a design-review skill, a UI-bug-triage skill — the same discipline applies to what you feed them: a skill expecting a screenshot costs more per call than one expecting structured element data, because Claude has to infer the selector before it can even start on your actual instructions. UICuts captures exactly that — selector, computed styles, DOM hierarchy — straight from the browser, so a UI-focused skill can work from text instead of guessing from a picture.

Related reading

Skills are Claude Code’s answer to a problem every AI coding tool has: Cursor solves it with Rules, Windsurf with Memories vs. Rules, and GitHub Copilot with scoped instructions files — same load-on-demand principle, different names. See the main Claude Code post for the rest of the session-level habits, and the MCP tool-schema tactics if your skills also connect MCP servers — the MCP specification is worth a skim if you’re writing tools that a skill will call.

Try UICuts free if UI feedback shows up anywhere in your workflow.