A lot of the course is centered around skills. I believe that when it comes to designing with AI, skills, next to enforcing strictness in your system, are the most powerful tool at your disposal.
This lesson aims to explain what skills are, how they work, and why they work.
A skill is a folder with a markdown file in it. This markdown file can contain lots of different rules, instructions, and decision trees that the agent can use to build your product.
To put it simply, a skill is essentially documentation for your agent. Before, when you didn’t know how to use say Sonner, you went to the documentation and read through it. Now, the agent can look up how to create animations by using the /emil-animations skill.
The good thing about skills is that they are discoverable and not enabled by default meaning they don’t clutter your agent’s context window. The agent looks at the skill title and description to decide if it should use the skill.
If you have the /emil-animations skill installed, it will most likely be auto-invoked when you ask the agent to add an animation to an element.
That’s why most of the skills in this course are very granular. This allows the agent to better understand the skills and what they do. If we had one emil-skill would the agent know when to use it? What would even be the description of the skill?
Right now we have lots of smaller skills instead. The title of each indicates clearly what the skill does. Use /emil-ui-polish for polishing the UI, /emil-typography for all typography related decisions, /emil-forms-and-inputs for all form related decisions, etc.
Here’s the top of /emil-animations, one of the skills from this course:
Next to a SKILL.md file, the folder can hold other files. /emil-animations has a patterns.md with exact recipes for modals, drawers, and toasts, and a techniques.md for springs and performance. These files can be pulled in on demand by the agent when the task needs them.
The agent only reading a skill’s description until it needs the skill is called progressive disclosure. The agent sees a little first, and only opens the rest when it needs it. This is a great way to keep the agent’s context window clean and focused.
And like I mentioned above, additional files can also be progressively disclosed.
/emil-prep-for-prod is the best example of it. It prepares your app for production across nine areas like accessibility, performance, mobile, and forms. Each area has its own file, close to 2,000 lines in total. Loading all of them at once is not necessary.
So the information is split into layers:
SKILL.md is mostly used as a table of contents. It lists the nine areas and links to the file for each. Then once the agent goes through all the areas, it sees “Load a lane file when you need to check that area.” which triggers the loading of the relevant file.
/emil-typography and /emil-color follow the same pattern on a smaller scale. The core rules sit in SKILL.md, and the details, like how to build a color scale, live in separate files the agent opens when it needs them.
This is also how you can make a skill as detailed as you want without slowing anything down. Depth costs nothing until it’s used.
Skills can be invoked automatically by the agent, but they can also be invoked by the user. This is useful when you know what skill you would like to use for a specific task. I use this all the time, as I like the explicit nature of it. It also makes me feel more in control of the agent and the output.
You can also enforce the skill to be user-invoked by adding disable-model-invocation: true in the front matter.
---
name: emil-build-a-tool
description: Analyze what the user is actually trying to build and
suggest the tool that gets them there. Use when the agent keeps
missing a result after a round or two of re-prompting.
disable-model-invocation: true
---The /emil-product-thinking skill for example is user-invoked by default. You don’t want the agent to randomly ask you questions about the idea you are working on if you didn’t ask for it. You do want your agent to have proper design taste however, so /emil-design-foundations is automatically invoked whenever a task is related to design.
You now know what a skill is. The next lesson covers why skills work, and how to write a good one. One that does exactly what you want.
If you haven’t installed the skills from this course yet, now is a good time. Install them and play with them. Go through the example prompts, and see how the agent uses the skills to build your product.
npx @aiforui/install --token=…