Teaching Claude to Work YOUR Way: Creating Claude Skills

I was messing around with Claude the other day, and I caught myself typing the same instructions for the third time that week.

“Use AutoHotkey v2, not v1. Put the functions at the end. Include the header lines. Dark theme the GUI.”

Every. Single. Time.

And it hit me: why am I re-explaining all this? Claude is smart, but it doesn’t magically know how I like things done. It’s like hiring a brilliant new assistant who’s never met you. Talented, sure, but you still have to show them the ropes.

That’s exactly what Skills solve. And if you’re new to AI and new to Claude Code, this is one of those things that clicks and suddenly makes the whole tool 10x more useful.

Let me walk you through it.

What Is a Skill?

Think of a Skill as a little instruction packet you hand to Claude.

Out of the box, Claude knows a LOT. But it doesn’t know your quirks, your rules, your preferred way of doing things. A Skill fills in that gap. It augments the model’s knowledge with YOUR knowledge.

Here’s the key idea: the model is the raw brainpower. The Skill is the specialized playbook. You’re not making Claude smarter in general, you’re making it smarter about your stuff.

Want every AutoHotkey script to include your header lines and put functions at the end? Write it once into a Skill. Now Claude does it automatically, forever, without you nagging.

The cool thing is you stop repeating yourself and you start getting consistent results. That’s the whole game.

You Don’t Have to Build It By Hand

Here’s the part people miss: Claude has a built-in Skill Creator skill.

You don’t need to learn some scary format or hand-write config files. You literally ask Claude to help you make a Skill, and it walks you through it. Tell it what you want the Skill to do, and it scaffolds the thing for you.

It’s a Skill that makes Skills. 🤖

So the barrier to entry is basically zero. If you can describe what you want in plain English, you can make a Skill.

The Secret Sauce: Your Description

Now here’s something that trips up beginners, so pay attention.

Claude decides which Skill to use based on a waterfall load. Picture your Skills lined up, each with a short description. When you ask Claude to do something, it reads down that list of descriptions and picks the one that matches.

That means your description is everything.

If your description is vague, Claude won’t know when to grab the Skill, and it just sits there unused. Ever hired someone, given them a tool, and they never touch it because they didn’t realize it applied? Same problem.

So spend real time on the description. Load it up with the trigger words and phrases you’d actually say. If you want a Skill to fire whenever you mention “build a form” or “add a settings window,” put those exact phrases in the description.

Now, How Do You Know Your Skill Actually Works?

This is where Tests and Evals come in. Don’t let the fancy words scare you, they’re simple.

Tests = the examples you throw at it

A Test is just a realistic request a user might make.

“Here are 5 example prompts someone might send this Skill.”

You run Claude-with-the-Skill against each one and look at what comes out. That’s it. This is the eyeball test. You read the output and go “yep, that’s what I wanted” or “nope, that’s wrong, fix it.”

Tests give you the examples to run.

Evals = the grading rubric

Now, eyeballing works for a while, but it’s slow and it’s a vibe check. Evals make it a number.

An Eval is a checkable pass/fail statement about the output. Things like:

• “The output is valid AutoHotkey v2.”
• “It includes the required header lines.”
• “The functions are at the end of the file.”

Instead of squinting at each result, you write these assertions and the outputs get scored automatically. You get a score instead of a feeling.

Evals give you the rubric to judge by.

Put them together and you can actually improve

Here’s the loop, and it’s beautiful:

1. Run your Tests (the examples)
2. Check the Evals (the rubric)
3. See what failed
4. Tweak the Skill
5. Run it again

Now you’re not guessing whether your Skill got better. You’ve got a score that says so. This is how you go from “eh, seems okay” to “this Skill nails it every time.” ⚡

The Trick That Almost Nobody Uses

Here’s my favorite tip, and it costs you nothing.

After you finish a session with Claude, if something felt clunky, if you had to correct it a bunch or manually fix stuff it should’ve gotten right, just ASK Claude about it.

Something like:

Claude will look back at where things went sideways and tell you exactly what to add to the Skill so it doesn’t happen again.

Think about that. Your Skill gets better every time you use it, because you’re feeding real friction back into it. That’s compounding. One thing I’ve learned: the tools that improve themselves are the ones worth building.

Oh, And You Can Just TALK To It

One more thing, because I don’t want you sitting there typing paragraphs like it’s 1998.

Hit the microphone button and literally have a conversation with Claude.

I do this constantly. I’ll be describing a Skill, thinking out loud, rambling about what I want it to do, and Claude just goes with it. It feels less like operating software and more like talking to a coworker who happens to be really good at their job.

If you’re new to this, try it. Talking is faster than typing, and it lowers the barrier to actually experimenting. 😊

The Bottom Line

Skills turn Claude from a generic assistant into YOUR assistant.

• They augment the model with your rules and knowledge.
• The built-in Skill Creator makes building them easy.
• Tests give you examples, Evals give you a rubric, and together they let you actually improve.
• Your description decides whether the Skill ever gets used, so make it good.
• And when something goes wrong, just ask Claude how to fix the Skill.

You don’t have to get it perfect on day one. Remember: life is an experiment. Try one small Skill, test it, tweak it, and watch how much time you get back.

Now go build something. 🚀