Back here in my project, I can add a local skill which is
available in the project by again going to the .Claude folder and
adding a skills subfolder in there.
You can also create global skills, and I'll get back to that.
In that skills subfolder, which also must be named skills, by the
way, you then add one subfolder per skill.
So, for example, here since we're in a React project,
a
modern-best-practice-react-components
skill. So my folder is named
modern-best-practice-react-components, and it's in that skills folder.
And in that folder, so in that modern-best-practice-react-components
folder, in my case here, you then add a Skill.md file, and that
must be named Skill.md. In that Skill.md
file, you then add some Markdown metadata, and you must have
a name and a description in there. You can add more, I'll get back
to it, but these two are required. And these two will help
Claude Code discover and load that
skill when it needs to, because the idea behind skills
is that you can put quite a lot of text into
those skills if needed. You should still be as concise as
but you can add all the information in here that makes up that
skill. But all those skills will not be loaded
context window by default, unlike Claude MD which is always
loaded, as you learned. But instead, they're discovered and
loaded dynamically. So, for example, if I have a skill that has
something to do with React components, it should be discovered whenever
Claude Code works on React components.
Now, the name must be the name of that folder.
So that's not a human readable name necessarily, but that is the
name of that skill, must be the same as the folder.
And, of course, that name should include some important
gives Claude Code some ideas on when to use that skill.
But the even more important part will be the description.
So here that could be something like build clean modern React components that apply
common best practices and avoid common pitfalls and so on.
By the way, you find the finished skill or skills, since I built
multiple skills for this project here, attached.
Now, this description is important because combined with this
title, Claude Code will decide whether to use
not. So all the titles and descriptions of all your skills
will be loaded into the Claude Code context window, but only
that. And the rest of the skills, so whatever goes into the main file, will
then only be loaded if Claude Code determines that a skill
Now you can also add more fields to that skill
metadata here. Attached you, again, find a link to the official
documentation that lists all metadata fields.
Name and description are the only required ones though.
But you can give Claude Code access to certain tools when it
uses that skill. So you could restrict that
by setting up some allowed tools. If you don't do that,
all the tools with that skill. You can define which
model to use with that skill, if it should open up a new
context window by setting context to fork.
Otherwise, it will use the context window off the
used the skill. Now I'm fine with all the defaults where
main agent could use that skill and can use all the tools.
So here, I then set up a basic React
component skill as I might want to use it with certain
conventions and patterns I want to use when building React
components. And obviously, if you're a React developer, you
can fine-tune or extend that skill exactly as you need it
for your projects. Now there's one important thing about this
specific skill here though. I have one
extra document which I want to connect to this skill.
And you can do that because you want to keep your skills
fairly concise. Yeah, they will only be loaded dynamically,
they're loaded, they, of course, still take up space in the context
window. So you want to keep them concise.
But when it comes to React, there actually are some additional
rules I want the AI to be aware of
when working with a feature called useEffect.
You don't need to know it. It's a React-specific feature
complex, which is why there are some specific rules related to that.
I don't always want to load that, but instead only when working with
useEffect. And the dynamic discoverability of
skills doesn't stop with the skill itself, because even after
this skill was loaded, more skill-related
documents and resources can be loaded dynamically by the
AI if it determines that it needs them.
That's why I'm putting these useEffect specific rules into a separate
file. And the common convention for that is to add a
references folder in the skill folder.
So in this specific skill folder, the
modern-best-practice-react-components folder, in there I add
references. And in that references folder, I then add another
Markdown file, and that's all part of the attached skills
find. And this Markdown file,
YouDon'tNeedUseEffect.md, is the file
referenced here. So I'm pointing at it to tell the AI,
if you need more information, if you're working with useEffect,
at this file, please." And in there, I then got more rules related to useEffect
which I did not want to include in the main skill, because I got
examples in there and all that. And that is all very useful
and something you want to do. That is exactly why skills exist.
It gives you a powerful tool for providing more context and more
information to the AI. But you want to build them such that
they're dynamically built up and dynamically
discoverable, because that's the main advantage of this
featureNow, I added a bunch of skills now.
Skills related to Next.js, to TypeScript, Bun,
and you absolutely can and should extend these skills
as you need. These are not necessarily the best or
final skills you can write here, but these are just some skills we can use
project to hopefully achieve better results when working with
React, Next.js, and so on. Now, of course, you can also have
global skills just as you can have global sub-agents in
your root cloud configuration folder on your system, so
outside of your project. You can add a skills folder and add
any skills you want to share across projects in there so
that they would be available in all projects you manage with Cloud
Code, not just the one you're currently on.
Unlike with sub-agents, the question is whether you want to do that though,
different projects may be using very different tech stacks.
And even though skills are discovered dynamically,
a certain skill does not matter to a certain project at all because,
for example, Next.js isn't used, you might want to avoid loading
anything related to that skill, even just the name and
description. And you want to avoid the skill
used by the AI. That's why I typically prefer
local project-specific skills, but you can also set up global ones
as mentioned. With those skills added though, we can try
moving on with this project. So, for example, we could define
a prompt like this and rely on Cloud Code automatically
discovering the relevant skills in reading the Cloud MD file, and
therefore, understanding the project.
So, therefore, here I just ask it to add a proper
authentication route page content to this app, and I tell that we only
have email plus password authentication, that users should be able to switch
between modes with help of search params, and that we don't
need password resetting in this demo app.
And I'll then again run this in plan mode.
And now, it should use the different sub-agents we
Explorer in our case, and also load skills as
needed to build these components.
And it's up to Cloud to decide whether it needs a certain skill or
not. And it gives me a plan that sounds
almost good to me, though I don't want users to enter a
I just want to use their email for that.
So, I'll deny this plan and ask Cloud Code to check if we
need to collect the name, and if we do, I just want to use the email.
So, here we go. We'll use the email. We get an updated plan.
I'll clear the context and accept all edits.
And I'll do something you can actually always do, I'll inject a message
whilst it's working, and I'll tell it to use modern,
JSX, and Tailwind code to give us a
higher likelihood of it using the appropriate skills
under the hood. And you can always do that.
Whilst it's working or whilst it's planning,
will not be sent automatically. Instead, they will be injected
when there is time for it, so to say.
So, here, I didn't get any feedback related to my
this follow-up message here to Cloud Code before I manually
review the code. And, of course, behind the scenes, it's very likely that
it also did explore and use the skills we gave it
to solve these tasks or to handle these different
prompts. So, that's all looking good to me.
This page also looks good to me. And if I go to the
Authenticate page, I have a nice sign-in box.
If I click Sign Up, I switch to that mode.
So, that's all looking good. Now, I'll try creating an account here,
and this is only locally, so I'll use a test email and a made-up
password. So, looks like that sign-up worked.
I also have no error message here in the server side log for my development
server, and therefore, we can continue with the next steps now
also giving Cloud Code some useful skills it can use when it needs
them