How to Make a Skill That Actually Works

Skills are easy to make. Making one that actually fires when you want it to, does the right work in the right shape, and still does the right thing the tenth time you run it is a different exercise. Most of the difficulty isn't writing the SKILL.md file. It's deciding which jobs are worth packaging, getting the description right so the AI picks it up, and editing the file when the work changes underneath you.

This is the practical companion to What Are Skills and How to Use Them. It walks through when to make a skill, the chat-driven way to make one on Zo, what separates a skill that works from one that doesn't, and how to keep skills useful over time.

When to make a skill

The trigger is "more than twice with roughly the same shape." If you've asked an AI to do the same kind of job more than twice, and the result needs to come out in roughly the same shape each time, you have a skill candidate. A status report, a refund response, a listing description, a pre-publish checklist, a research summary, a release-notes format, an investor update. Anything where the second run should look like the first.

Two more questions are worth asking before opening a skill file:

• Could you brief a new hire on this in writing? If the answer is no, the procedure isn't formed yet, and a skill written now will lock in confusion. Run the work in chat a few more times until you can say what's actually supposed to happen.
• Is this about how the work gets done, or what the AI knows about you? Skills are for procedures. If the answer is mostly facts the AI needs to remember (your timezone, your client list, the format you prefer for reports), that belongs in memory, not a skill.

The decision aid:

If a job fails the checks above, hold off. A skill written too early just locks in the wrong procedure. The fix is to run the work in chat a few more times until the right shape emerges, then package what's there.

How to make one on Zo

The fastest way to make a skill on Zo is to ask Zo to make it. The Zo Skills hub includes the skill-creator skill, an Anthropic-authored skill that walks the AI through writing a clean SKILL.md from a working chat. Once it's installed, you don't write skills by hand. You do the work in chat, you ask Zo to package it, and skill-creator handles the structure, the description, and the file layout.

The pattern, end to end:

Step 1: Do the work in chat once

Don't try to design the skill up front. Open a chat, run the workflow end to end, fix the small things as they come up, and keep going until the output is something you'd actually use. The chat is where the procedure gets figured out, and the small fixes you make along the way are usually the parts most worth capturing.

Step 2: Ask Zo to package it

At the end of the working chat, send something like this:

If skill-creator is installed, it picks up automatically and walks the AI through producing a clean SKILL.md, naming it well, and saving it to your Skills/ folder. Zo reads back through the conversation, drafts the file, saves it, and reports the trigger phrase to test.

Take what we just did and turn it into a skill so my next conversation runs the same way.

Saved a skill called customer-refund-response. Description picks up on phrases like "draft a refund email," "refund response," and "reply to the refund request." Try "draft a refund response for the order I just pasted" in a fresh chat to confirm it kicks in.

Step 3: Test it in a fresh chat

Open a new chat and try the trigger phrase Zo gave you. The skill should pick up automatically and run the procedure. If it doesn't fire, the description is too vague and needs sharpening. If the steps drift, the instructions are too loose and need tightening. Two or three rounds of that and the skill is ready for daily use.

If you don't have skill-creator installed yet, the Zo Skills hub has it under External, or you can install it directly from its hub page.

What makes a good skill

The skill-creator skill is good at producing a working file on the first try, but a few principles separate skills that hold up over time from ones that quietly stop working.

A description that uses the actual words people type

The AI picks up a skill based on its description, not its name, which makes the description the most important line in the file. "Helps with reports" is too vague to fire reliably, because the AI has nothing concrete to match against. Something like "Drafts a customer refund response with apology, root cause, refund amount, and next steps; use when the user asks for a refund response, a refund email, or a reply to a refund request" gets picked up the second someone types "draft a refund response." Cover both what the skill does and when to use it, and use the words you'd actually say. If "recap" is the natural ask, "recap" needs to be in the description.

One job per skill

A skill that tries to do three different jobs ends up doing all of them poorly, because the description has to be vague enough to cover all three. If the work splits naturally into two distinct jobs (a customer-facing draft and an internal note, say), that's two skills. The skill-creator skill will usually push back if you try to bundle, but if you're writing by hand, the easiest test is whether the description is one specific sentence or a list of vague gestures.

Just enough instruction

The instructions inside a skill should match the work's fragility. For things that need to come out exactly the same way every time (a refund response, a release-notes format, a regulatory disclosure), be specific: numbered steps, exact phrasing, required sections. For things where judgment matters (a brainstorming session, a research summary), keep it light: a short outline of what good output looks like, not a script. Anthropic's skill-creator framework calls this "degrees of freedom," and getting it wrong in either direction is the most common reason a skill underperforms.

Examples that ground the format

If the output has a format that isn't obvious from the description, include one or two short examples in the SKILL.md. The AI does much better with a worked example than with abstract format rules.

Maintaining a skill over time

Skills aren't static. A skill that worked when you wrote it stops being right the moment the inputs change, the format drifts, or the audience for the output is different. Keeping skills useful is a small ongoing task, not a one-time write. Three signals to watch for, and one moment to retire a skill outright.

The output doesn't quite match what you want, but you keep using it anyway

If you've manually tweaked the same line three times after the skill ran, that line should be in the skill. The skill is supposed to absorb the small fixes; if it isn't, the fixes are pointing at an instruction that should be in the file but isn't.

The description fires for things you didn't intend

"Customer note" was meant to draft a follow-up email to a client, but it's now also firing when you ask for an internal CRM note on a customer record. Either narrow the description with more specific phrasing, or split into two skills with separate descriptions and clearer trigger words.

The skill stopped firing for things you did intend

Usually a sign that how you phrase the ask has drifted from how the description was originally written. Update the description with the new wording, or add the new phrasing alongside the old.

When to retire a skill

When a skill is no longer useful, open the file and delete it, or move it out of the Skills/ folder. A graveyard of out-of-date skills competes for the AI's attention every time a chat starts, and a forgotten skill that fires by accident is worse than no skill at all.

Pitfalls to avoid

Over-prescribing

Telling the AI every word to use in every situation makes the skill brittle. The model is smart enough to fill in the connective tissue if you tell it what you actually want. Reserve specificity for the parts of the output that genuinely have to come out the same way every time.

Vague descriptions

"Helps with reports" is the canonical example. If the description doesn't include the words you'd actually say to trigger it, the skill won't fire when you need it, and you'll end up rebuilding the procedure in chat anyway.

Putting facts in the skill

Your timezone, your client list, your default tone for client emails: those are memory, not procedure. Skills should reference those facts but not contain them, so that an update to a fact (a new client, a tone shift, a moved deadline) doesn't require rewriting every skill that touches it.

Bundling unrelated jobs

A skill that tries to handle a refund response, a status report, and a follow-up email is three skills wearing a trench coat, and the description that covers all three is too vague to fire reliably for any of them. Split them.

Not testing in a fresh chat

A skill might look fine in the chat where it was made, because the model has the recent context to lean on. Always test in a new conversation to make sure the skill itself is carrying the load, not the conversation around it.

Where to start

Pick one job you've already done with AI more than twice, where the output should look the same every time. Open a chat, do the work end to end, send the packaging prompt above, and try the trigger in a fresh chat afterwards.

For the format underneath, What Are Skills and How to Use Them is the primer. For where skills sit alongside MCP, Understanding the Differences Between Agent Skills and MCP Servers covers both.

Frequently asked questions

A good skill turns a working chat into something that runs the same way every time. Done well, the skill stays useful for as long as the work does. Get started with Zo Computer.