Agent Skill Tips

A few months ago I wrote about Agent Skills and why designers should pay attention. Since then I've been building skills regularly - for work, for this blog, for side projects. Enough time to pick up a handful of things I wish I'd known earlier.

These aren't revelations. They're the small friction points and workarounds that don't make it into the documentation.

Enable the skill-creator skill first

Before you do anything else, make sure the skill-creator skill is enabled in your Claude settings. It's a meta-skill - a skill for building skills - and it makes the whole process significantly less fiddly. Without it, you're essentially constructing the folder structure and schema by hand and hoping Claude follows the right format. With it, you have a guided process that knows what a valid skill looks like.

It's the one skill that should always be on.

Tell Claude to reference agentskills.io

Claude will sometimes declare a skill finished before it actually is. It'll generate a SKILL.md file, present it to you, and consider the job done. The problem is that a valid skill has a specific schema, and Claude doesn't always follow it without prompting.

A simple fix: ask Claude to reference agentskills.io when building any skill. This grounds it in the actual specification and tends to catch omissions before they become problems. Chain this with the skill-creator and it'll get the job done.

Ask Claude to package and validate - not just build

This one catches people out. Claude will often build a skill and share the SKILL.md file directly in the conversation. That's not the deliverable you want. While valid (as are .zip skills) it's not the standard.

A .skill file is a packaged bundle - the SKILL.md plus any referenced files, scripts, and resources, zipped together. That package is what you upload to Claude. For simple skills with no supporting files, the difference is minor. For anything complex, it matters a lot.

Adding "please package this using the skill-creator skill" to your request tends to trigger the right behaviour. It's a small prompt that makes a meaningful difference in what you get back.

Pay attention to the metadata

Skills support a range of metadata fields in the frontmatter - name, description, version, and more. Worth reading through what's available.

The version field in particular is easy to overlook and worth caring about. As you iterate on a skill, ask Claude to increment the version number with each meaningful change. It's a lightweight way to track what changed and when, especially once colleagues start using your skills and you need to communicate updates.

The share button (if you're on a team account)

If you're on a multi-user Claude account at work, there's a relatively recent Share button in the skills interface. It lets you share a skill with colleagues without sending them a file. They'll need to go into Customise > Skills to enable it on their end - worth mentioning this to them, because it's not obvious.

The benefit is straightforward: when you update the skill, everyone with it enabled gets the latest version automatically. No redistributing files, no version drift across a team. It's a small thing that removes a real coordination overhead.

Skills as a lightweight knowledge base

This one's less a tip, more a use pattern I've found genuinely useful. Skills aren't only for procedural workflows - they can hold standing context that you want available across all your chats.

Writing guidelines, tone and voice rules, design-system tokens, team terminology - anything you'd otherwise paste into the start of a conversation can live in a skill instead. You define it once, enable it, and it's just there. Not as sophisticated as a proper RAG setup, but for stable, reference-level knowledge, it works well.