My skills have been installed over 2 million times and have more than 50,000 stars on GitHub. This is a testament to the quality of the skills and the trust people have in them. They work, because they are written in a very specific way that works for UI skills.
This lesson explains how I structure my skills, so that people actually get the results they are looking for, and they do! Just look at the reviews below.
Coding agents can build almost anything now, but they don’t quite know what great feels like. That part is on you. In Agents with taste I wrote about packaging your taste into skill files, so your agents can produce work that feels like yours.
But how do you actually write a skill that does exactly what you want it to do every single time? This lesson covers that.
If you want general advice on how to write skills, I encourage you to watch Matt Pocock’s presentation on the topic. This lesson, like this whole course, focuses specifically on UI-related skills, so the advice is tailored to that.
Agents are probabilistic. If you ask the same question twice, you’ll get two different answers. You can prevent that to some degree through skills by forcing the same process when coming up with the answer.
Take easing. Without a skill, the agent might pick a different easing curve for a dialog animation every time. Sometimes it could be good, but you just never really know. With a skill that describes the decision process in detail, it walks the same decision tree every single time:
You essentially narrow the array of possible answers the agent has to choose from.
The animations it produces will still differ, they should, every context is different. But the reasoning is now yours. That’s what a good UI skill does. It gives you predictable behavior based on your taste.
With enough experience, you can not only tell what feels better, but also why. An element entering with scale(0) feels wrong because it comes out of nowhere. Starting from scale(0.95) resembles the real world more.
Shadows work better as borders, because they add more depth to the element.
That why belongs in the skill, not just the rule itself.
When your rule doesn’t cover a situation, the agent has to guess based on its own knowledge. Even if you had a rule, but without reasoning, it would be applied blindly, including in places where it shouldn’t be. A rule with reasoning can be applied more broadly, because the agent can extend the logic to cases you never wrote down.
Think of it like guiding a less experienced designer who happens to be very fast.
Start scale animations from 0.95.
Start scale animations from 0.95, not 0. Elements appearing from nothing feel unnatural, real objects always have a visible shape. The higher the initial value, the more gentle and elegant the entrance.
The most common mistake is writing a UI skill in a way that’s too open to interpretation. You have to be strict. This narrows the array of possible answers the agent has to choose from.
Try to keep animations reasonably short. Use tasteful easing curves where appropriate.
When using words like “reasonably”, “tasteful”, “where appropriate”, the agent can’t act on any of it, it’s too soft to force the agent to follow it. Those are the sentences that don’t change behavior. They are just filler text.
Compare:
UI animations stay under 300ms. Exit animations are ~20% faster than entrances. Larger elements animate slower than smaller ones.
This is much more precise and leaves no room for interpretation, which is exactly what we want if we want to steer the agent’s behavior instead of relying on its own defaults.
The strictness can feel uncomfortable, like you’re leaving no room for creativity, but the creative part of the job is still yours, the skill just makes sure the agent doesn’t have to guess at the parts you’ve already figured out.
Words carry weight here too. “Never”, “always”, “strict” are heavier, they have more importance, those are the words that you should be using in your skills to enforce the rule. If a rule matters, it has to be reflected in the skill.
A great design is defined as much by what you leave out as what you put in. So is a great skill.
Go through your skill sentence by sentence and ask one question: does this line change what the agent does? The agent already knows what CSS transforms are. It knows what a modal is. Explaining these things doesn’t just waste space, it dilutes the lines that actually matter, because the agent’s attention is spread across everything you wrote.
The most common mistake here is adding the obvious stuff into your skill. The agent already knows how to write decent CSS or React, it doesn’t know all the nuances like increasing the duration of an animation if the object is larger.
Domain-expertise is what you should include in your skills. Not how to add padding to a button, but adding a subtle scale down when a button is pressed. Or preloading a font in React with ReactDOM.
One of the most important rules.
One skill per aspect of the interface works well: one for animation, one for typography, one for layout. Small, focused skills instead of one giant one.
This allows the agent to accurately pick the right skill for the task at hand, we talked about it in the last lesson. It also keeps your skills structured and prevents bloat.
In fact, I recommend narrowing it down even more. /animate for building animations, /review-animations for reviewing them, etc.
I get a lot of people asking me whether I write my skills myself. The answer is no. As long as you have a good workflow for creating skills (you’ll get a skill at the end of this lesson), you can ask your agents to write them and improve them over time based on your feedback.
The reason for not writing the skills yourself is that agents are the ones consuming the skills, so you should write for them, and the results from my experience have generally been better when agents write for agents.
It would also be a huge time sink to write everything by hand, and it doesn’t have to be, since again, agents are the ones consuming the skills.
All of this advice and more has been packaged into a /emil-writing-skills skill. You can use it to create your own skills. Note that if you installed the skills using the general install command, you don’t have to install it again.
npx @aiforui/install emil-writing-skills --token=…The way I like to do it is to dump all my knowledge about a specific topic like typography into a document, then run the /emil-writing-skills skill on it. The document can be literally a note in Obsidian. It’s just about putting the knowledge into a format that can be used by the agent.
/emil-writing-skills here are my notes on typography, make me a skill out of it
The skill will then run through your brain dump and extract the knowledge into a skill file while following the advice in this lesson. So it will be strict, focused, and it will explain why a rule is the way it is.