Full Walkthrough: Writing & Using Skills — Nick Nisi and Zack Proser

This workshop is going to be "Skills at Scale." We're super excited to be here with you today. There's going to be an interactive component, and we also want you to feel free to interrupt us and ask questions as we go.

Yep. We'll show that slide again with the QR code and the instructions to clone the repo. That repo has the skills that we're working on, plus the slides that we're presenting. So you'll have all of that as reference material.

I am Nick Nisi. I am a Developer Experience Engineer at WorkOS.

I'm Zack Proser. I'm also a Developer Experience Engineer at WorkOS, and we're on the Applied AI team.

And this is like working with agents. That's just like what we do now. Zack, when is the last time you wrote a line of code by yourself?

I think I did a CD in a directory recently. Otherwise, it's been like probably six or eight months now.

Yeah?

Maybe longer. Yeah.

Same. Same. We've been early on from the Opus 3.5 days.

From copying and pasting back and forth through GUIs.

To seven.

To now.

Yeah. It's gotten a lot better. And I don't know, there's a mythos out there that it's going to get even better.

We are at WorkOS. And if you are interested in securing MCP, for example, or just setting up auth for this new agentic startup that you're working on, reach out to us. There's a number of us here with these shirts on, and we'd be happy to talk.

We're also hiring.

Thanks to the AI installer that Nick built as well. You no longer even have to configure or install AuthKit yourself. It can just do it for you. So pretty easy to get started.

For sure. Allright. So as you know, when you're working with these systems, every single conversation that you have starts completely from zero. You're always just passing in new information to it. You've got to reiterate how you do things.

And Claude, for example, never remembers that it ever talked to you. It just continues on a conversation. And so we have to provide that information fresh each time.

Yep. So for example, let's say you have a skill or let's say that you're talking to just in disparate terminal tabs. You're looking at different code bases over the course of a week. Every single time you start talking to it, you need to reload all of that context first and say, this is what I care about.

This is how we do things here. This is what we're particularly concerned with. And it ends up eating a ton of time and slowing you down.

Yep. And of course, there's things like agents.md or Claude.md that you can put in information about the repo or about how you like to work, like in a global directory, so that it can remember that and understand it each time.

You're giving that instruction each time, kind of like appending it, so that it will remember, oh, in this project, we actually use VTest, and we use pnpm. So you should use those each time. So that's like the way to give it some memory for it to understand how to go.

But it can still get it wrong. It can still decide not to follow things that you have. I've definitely had cases where I'm like, do this, this, and then this. And it skipped the step in the middle. And I say, why did you skip that?

And it's like, oh, yeah, you told me to do it. I didn't feel like it. And that's how you know it's a real engineer.

Yeah. So one of the nice things about skills is that you can think of it as like a discrete unit of work where you can encode everything that's super important to you, everything you don't want it to miss, everything you don't want to repeat yourself.

It's almost like carrying, if you will, the dry pattern into the agentic era in a way, and not repeating yourself. And as we'll see, that becomes incredibly powerful, regardless of if you're a solo developer working on your own startup with 12 agents or if you're on a traditional dev team with 12 team members.

Yeah. It doesn't know what you know. So you have to be very specific and be thorough with what you want it to know, because it's not always going to figure it out. Sometimes it feels like magic because it just does.

But a lot of times, you have to put in the work to do that. And that's what those memory files are, like Claude.md and other memory files. It even has like Claude, for example, has its own built-in memory where it kind of keeps track of things that it thinks are pertinent to the way you work or the project that you're working on.

And it will save that off.

Yep. And of course, this works too in just a single project context with some of those files that Nick mentioned. But then again, the problem is that you're still tied to that repo. You need your team members to remember to pull updates to that specific project skill if they want the context.

There's no necessarily built-in script execution. So how do you interleave a deterministic result when you're having a non-deterministic conversation with an LLM? And eventually, that starts to get pretty gross.

Yeah. And there's downsides to this, specifically these memory files, where they're tied to the repos that you're working on. Or you have to put them globally so it affects everything. And you can't do things like give it more smarts like execute this script.

You can, but it's kind of not built in, so to say. But that's kind of like where the things that you put in there are not always transferable or portable to other projects that you might be working on.

And so we need a better way to do that.

And skills are that next step.

Yep. Indeed.

It's a way to make things more portable. And you can use scripts to inject real data. And you can make them composable so that they can be very small and very focused on exactly what you want them to do.

And that way, they're very small, like a very small footprint in your context window. But also, you can build them in such a way that they are only going to be applicable when you actually want to do whatever that skill is set up to do.

So you're not just bloating the context with everything from the start every time, like you are with a Claude.md.

Yep. And so if you haven't seen or heard of a skill before, just to level set really quick, it could be as simple as a single static markdown file without any scripts at all. But let's look at the difference of what might happen.

Let's imagine that we're roasting a repo. We're onboarding a new team member. We want to make sure that they're kind of up to snuff on how things work here. Without a skill, if you're just talking to any generic agent with no specific context injected, you're going to get, OK, looks pretty good.

It's going to be generic advice. It might find some low-hanging fruit. If you say instead, as little as 30 lines of markdown specific to your use case and your conventions, your constraints, you can start to get back very, very hyper-specific feedback about, this is how we handle routing in this project.

We follow semantic commits or whatever. And we've got README drift here, and that's unacceptable. So it can take as little as 30 lines of markdown or less. And so that's one of the first things that makes skills incredibly powerful is that it's a very minimal investment on your part.

And it could be as simple as a small markdown file. And it becomes a composable unit of work that you can share across code bases and your team.

Yep. And you're codifying exactly what you want it to do. And you have freedom to express yourself in the exact way that you want it to do that. And there's a number of different ways and techniques that we'll talk about throughout this workshop.

But it's much better having those skills and knowing that they exist and knowing not just that you can use them, but also setting them up in a way that the LLM can decide to use them when it makes sense.

And it's going to give you a single, repeatable way of doing that thing in the way that you expect it. If I just tell it some generic thing like, look at this and tell me how good of a repo it is, depending on the model that you're running, maybe the amount of thinking that you have turned on, et cetera, it might give you more or less information.

But it's never going to be the same thing each time. If you want it in a very specific format, you want this report in this exact way, that's what a skill is. You're teaching the LLM how to do something in the way that you expect it to be done.

And then it will follow that much more closely.

Allright. Let's take a look at how a typical skill might break down. So again, it could be a skill.md, so simple as a markdown file. At the top, you'll notice a front matter. So think about anywhere else that you've used, like a YAML-based system, almost like headers in other languages or formats.

But you've got a name, a description. And this description is incredibly powerful and loaded. This is what the LLM is going to use at runtime to essentially do routing and determine if this skill is relevant to the task that you've assigned it.

So that's kind of how the AI finds and routes to your skill. And then additionally, you can provide additional context and then even scripts so that, again, think of it as your option or your on-ramp for interleaving determinism with the non-deterministic LLM conversation.

Yep. So the most important things here are exactly what Zack said, the name and the description. It's a misnomer that skills are only a single markdown file. They, of course, can be, but they're more like a folder with a skill.md file in them.

And then they can have anything else in there as well. And we'll kind of talk about that. But they can have references to other things that they might want to know. They can have scripts that it should run.

And they can have images. They can have all sorts of different things and then use that in different ways. But the most important piece of it from the start is the description, which we'll talk about.

Also, just talking about constraints, one of the things that's kind of not intuitive is that it can be more powerful just to provide a few constraints as opposed to being overly prescriptive in exactly how you want the task done.

So if you provide just three constraints and say, never be vague, or when you cite code, it always has to have a specific line and a Git commit reference with it, then you'll get better performance than if you end up bloviating in the middle of a markdown file so it's like a novel.

This is actually common failure mode when designing skills.

Yeah.

Yep.

So today, we're going to put all of this together into a skill that we're going to build here in the workshop. And it's just called repo roast. We tried to think of a fun, generic skill that would be applicable to anyone who is working in JavaScript or different languages, but also if you're not, really.

If you have an idea of what a Git repo is, this is applicable to you. So it kind of transcends all of that and is generally something that's useful for everyone, but also kind of fun. We can kind of be more or less serious with it as we're putting that in.

So it's going to allow for a lot of creativity as we go.

And feel free to also kind of use this as a place to inject the actual constraints or the requirements that you have at work that you're kind of struggling with or testing. So we'll kind of get the baseline together.

And then you can start customizing from there. And we'll have some time to share and discuss them later too.

Yep. So this is that slide from the beginning. If you haven't yet, please download this, clone this repo, and work in there. We've got kind of the basics of the skill. And what we're going to do is just kind of get it set up.

And you can make it your own. We've got some general guidelines and some tips to do. But the fun is going to be that we have a room full of people. And we can have a room full of different ways of analyzing this.

And we'll also share that. In that repo, there is a share.sh that you can run. And it will just ask you for your name. And then it will put that into a KV store. And then I can pull it down quickly on my machine and then run it against some repos on the screen so we can share these at the end of the day.

Yeah. It'll be kind of a fun way to experiment with different approaches to the same skill.

Yep.

So speaking of loading skills, we should talk about how skills load. We are generally kind of talking you'll hear Zack and I kind of always just like when we're talking, we're saying Claude, because we tend to use Claude.

How many here use Claude as kind of their daily.

Daily driver. Whoa. OK.

That's pretty much it. It's like 91% market. And then everyone else, there's Cursor. And I have been dabbling with Py. Py is amazing. But also, Anthropic won't let me use my it's unclear. Can I use my subscription with it?

I don't know. Maybe I'll find out today or this week.

You can pay more for it. You can pay more in credits for it. That's fine.

For sure. But when you're using these, the main thing and the reason that we're so excited about skills too is that they're generally applicable to all of the major models. So Codex supports them. Claude supports them. Cursor supports them.

The desktop apps, like Claude Desktop, supports it. So even if you're non-technical, you can be working on skills and sharing skills and using skills.

What was the skill that you did last week with the recruiting team in Desktop?

Yeah. I was working with our recruiting team. Kind of they were at an onsite. And I was zoomed in with them, helping them build a skill that could take candidate information and format it in specific ways and understand what they're looking for in different things and kind of build reports automatically.

So it's things that they could do pretty simply. But because of the beauty of Claude Desktop and all of the connectors that it has, it could just reach into Slack and pull in information from there. It could reach into Notion and grab that information and then mix that in with the recruiting software that they use and put it all together into a single report that then they can share to build from there.

So it wasn't like, this is the final report that we use for everything. This is a building block that then they can use to do different things in different places. And so it was really powerful for that.

And as soon as you gave them that skill, then everyone on the team is running it in a uniform way, which is the power of it too.

For sure. And so where do those skills go? Well, the most basic place is if you have a repo, you can just put a .claude directory and then have a skills directory and then a folder, which is the skill name, and then a skill.md, all caps, in there, just like this.

And that will be a skill that lives with that repo. And so anyone who is using that repo, it'll just automatically load that and understand how to use it. You can also have that same .claude directory in your home directory and put those skills there.

And then they're generally applicable to everywhere that you would be using Claude. Same thing. There's kind of more standardization for everyone else on .agents. I wish there was agents.md instead of claude.md and .agents instead of .claude. But maybe we'll get there one day.

So you can put them in there. And if you've ever used the NPX Skills tool from Vercel, that is just kind of simlinking them all into all of these different directories. And so the skills are generally applicable everywhere.

That's just an easy way to load and install them, which is why it's so popular.

Yep.

But the main develope with it is you edit the skill, save it, invoke it, see what output it is, and then do that process all over again and test it. If you're using Claude as well, Claude ships with a fantastic skill builder skill or skill creator skill.

And that is really good for critiquing your skill, setting it up in a way that Claude would expect it to be, and even evaluating it, which we'll talk about.

Yep.

Allright. So we're going to start by letting you go ahead and work and build the foundation. So you should have that repo. And we just want to get started with it. So the main things that you want to do is you want to set up a proper description for it.

Now, remember, this description is not for humans. The description is really more for the LLM so that it knows when it should use the skill automatically. And so you want to set that up in some way. We recommend in some way where it describes, oh, we're going to roast this repo.

The user wants to roast this repo and get an analysis, a fun analysis of it or something, be creative and fun with it. But then you should just be able to open up Claude and say, roast this repo, roast my repo.

And it goes and does it.

Yep. And then remember that, in general, it's recommended that instead of being overly prescriptive in how to do something, provide your constraints instead. So say, we're using this format in this repo, or we follow these coding conventions, or we never do X or Y, and then allow the LLM to make theright determination at runtime.

Yep. Yeah. Definitely closing it off like that. Don't prescribe what it should do. Kind of give it advice on what it shouldn't do and let it be more creative on things. But you can also change that as well and be more assertive on things that you know you want in a specific way.

So let's work on that. A couple of things that tips that we want to talk about in this first section is and this, I think, might be pretty applicable, only applicable to Clauderight now. I did ask Py if it could do it.

And Py just made an extension that made it work. So that's awesome. But if you use the bang and then backtick for a script call, Claude will do an interpolation of that, just like how JavaScript has the dollar sign, open curly brace, and close curly brace.

It'll just, instead of having whatever was in there like this, where it's saying stale to-dos, and then it gives you a command to run, it will just replace this with a list of the stale to-dos because it will actually execute this grep command and then do all of these pipes to all sorts of different things that's totally not slipping up keys or anything.

Yeah. But you can imagine how this is really powerful if you're, say, you're doing your morning report, your kind of Git status report. Any of the pieces that you want to be output in a deterministic way, that's an ideal use case for this kind of script interpolation.

Yeah. This is really great because you're not saying, go grab the latest commits or the latest 10 commits and give me some information on it. You're saying, here are the latest 10 commits in the exact format that I expect you to understand them in.

Go and do something with that information. So it's not guessing. It's not going to be non-deterministic each time. It's going to start from this deterministic base and then go from there.

It's also very token-saving. If you've ever said, go and figure out the 10 commits and you've run that more than once or on three different terminal tabs, you know the first two might get it perfectlyright. And the third is spinning and reading Git docs before it finally gets there.

So this is a way to say, once you've formalized a piece of your workflow, you can just codify it and say, run this exact script.

Yep.

Yeah. Like we said, without scripts, the AI is just speculating on what you mean when you say, go get the latest commits.

Yeah. And just remember that descriptions are routing rules. They're less for us. And they're more for the AI to determine when to use it. So a good example is you might have a couple of different image generation skills.

And they're all kind of littered in the projects and maybe in your global skills. Maybe one is more applicable to your personal blog. And you say, on my personal blog, I always should pixel art. So if we're writing on this domain, this is the skill to use.

If we're going to work, it has to be formalized. And we use a completely separate image generation system or we only fetch images from S3. That's where you can kind of codify that in your description.

And if you're not sure, by the way, you can always ask Claude. That's the other kind of secret hack of this era that everyone forgets is that a lot of times, the models are capable enough that you can ask them, have I done thisright?

Or when would this apply? So you can say, as a test run, when would you load this currently? If I only want it to run in these conditions, is this the best description for me or not?

Yep. And a great example of this is when we were building this, I asked Claude. I was like, hey, I know I can do this. But do you actually support skills calling skills? And it was like, oh, let me go check.

And it loaded a Claude Code analyzer skill to get that information and then do that research and come back and say, maybe.

Yeah. It was like, kind of. But you probably don't want to do that.

Yeah. So your turn. We're going to take some time to go do that, to let you go do that. And when we do these breaks too, this is a great time if you have any questions or have discussion topics that you'd like us to talk about.

We can do that. We're trying to fill the dead air of you working on these with general topics. So if there's something that you want us.

I was supposed to say that part out loud.

Oh, that's OK. If there's something that you want us to talk about, we can definitely do that. Otherwise, we've got some discussion topics that we thought we could talk about. But also, if you have any questions or any of that, we can definitely.

I'll run over to bring you the mic. And feel free to shout out any questions. But yeah, otherwise, then feel free to just start on this. And if there's any questions, let us know.

Yeah. Question. You want to run the.

Sorry. What was the question?

You talked a bit about this in the beginning. But I always wonder where to draw the line between encoding instructions in rules, Claude.md, and so on, and creating a skill for something. So I'm curious if you have what's your mental model to making that decision?

Have you landed anywhere? Do you always start with the rule? And then you make a skill if you can make it specific enough? Or do you always start with the skill? How do you go about it?

Yeah. Great question.

Great question.

I usually the number one rule that you have to remember is that the skills sorry, the Claude.md or the agents.md, that is going to be loaded every time. When you kick off Claude, that's going to fill your context window.

And if it's filling it with a bunch of nonsense that isn't actually applicable to what you're specifically doing, then you probably don't want it in there. I can show an example of my

what is it? .claude

and then I think Claude.md if I can spell. This is my Claude.md. It's extremely small. It just tells it that I want things to be a little bit more terse. Don't bloviate. I just want to know exactly what you're saying.

Be extremely concise. And then I also I have this plugin that I'm working on. It's a skill actually called Ideation. And in here, I put some configuration for that so that all of the projects I basically want them all to put the Ideation, the artifacts that it's generating, into my Obsidian vault.

So it puts it all in there so I can more easily find the connections between things. But otherwise, it's extremely tiny. And so that's one thing that goes into it. If it's only relevant to the repo, specifically, I'm tired of it using npm when I wanted to use pnpm, for example.

I'll put that in there, a single line that just says, we use pnpm here. And then anything else, like if it's more specific about testing or anything like that, I kind of leave that to skills so that it's only going to be loaded when I'm actually writing tests.

To the second part of your question as well and we'll talk about this a little bit later. But the other thing that's really fun to do is basically wait a week while working on it and then go back and ask Claude, analyze my week's worth of work.

And then what are the skills I should split out of that based on this?

Yeah.

So again, ask the system to kind of help you do that. Another question, back here. Yes, sir.

OK. You can hear meright? Yeah.

Yeah.

So stop me if you're going to talk if you're planning to talk about this later. I was wondering about global skills, which we will share amongst colleagues. So we're all at the moment, we've got, I think, 60 engineers.

People are writing their own skills. We're chatting on Slack. Oh, I've got this great skill. It's really good. So then obviously, engineering managers are like, well, we should be sharing these. Where do we keep these? Where do we keep them in a repo?

What's our artifacts library? And then others have said, no, we don't want that. Because if I put my skill up and then someone's like, oh, I'm going to change that, then we're going to have MR requests. And then we're going to have to review changes to skills.

So then we'll get someone else saying, well, I kind of like a skill. But I'm now going to push my version of that skill with a very similar description to the shared repo, which everyone's going to get. And then suddenly, we've got 10 from 10.UX skills.

And they're all the agents then. Which of these do I actually use?

Yeah.

And we're wondering if you guys have got to that stage of how to maintain. And then the next one is, three months later, a new model comes out. And these skills are actually a little bit too verbose. So who's evaluating the skills and checking them and saying, OK, let's cut these from the global?

Because now you get what I'm saying.

Totally.

This is where we're at with how. And so a lot of engineers are just like, no, no skills. Everyone does it on their own.

I know.

We are not sharing anything. So sorry. That was a bit of a rant.

No, no, no.

You get where I'm coming from, yeah.

Fantastic question. I'll take the first stab. Interested to hear what Nick says. We have published maybe you want to pull it up GitHub Work OS Skills. That was one of the first places that we started publishing generic skills.

And that's been incredibly useful because, for example, I was building generic RAG pipelines. And then we found that agentic tool calling is higher performance. So I can sideload those skills that Nick put in there that are specific to certain documents to the problem of individual engineers saying, I want a slightly modified version of this.

I would almost say, in that case, cool. You've got a forked skill you keep locally. And then to your question about evaluating the skill, I think asking Claude, with your current model, look at the skill using the skill builder.

Is itright for truncation? Or is there additional extensions that we need now? But I'll also share that we are feeling that same pain as I'm sure everyone else is. And I think the management layer is just shifting to that kind of.

But even if you ask.

Sorry. No, you're good.

Even if you then ask Claude, let's say, a week later, a month later, hey, review our skills. There's 30 skills to review. And it comes up with lots of suggestions. You then got to open a merge request for possibly one human or two humans.

Or maybe we can automatically say the person who wrote this skill originally has to be one of the reviewers. Have you got down to that yet where.

I don't think we've gotten to that level with ours because ours started kind of formalizing documentation into buckets that were then easily sideloadable in different systems. That does sound painful. I'm curious to think what do you think about that, Nick?

We haven't even got there. People have just foreseen that this is going to happen. So they're actually blocking us using shared skills at work because they think this is going to be the problem. So literally, we're overthinking it massively.

We should just do it and try. But still, I'm interested to hear what you guys.

Definitely. And I also think it's going to evolve rapidly too as we're seeing there's still we haven't quite hit the LLM training wall. So there's going to be kind of additional capabilities coming online. And yeah, what does it look like in six months?

Could we pare the skills down even further and get the same or better performance?

Yeah.

But yeah, I'll say that that's yeah, that sounds like a typical human problem of my skill, your skill.

Yep. We have a number of to build on that, we have a number of ways that we solve that. Like Zach said, the skills repo, this is our public skills that you can just install with npx skills add.

And those are all available. But then we also have some internal skills that are more generally applicable to engineers at Work OS. And so it's like there's an auth specialist. There's a DX specialist. There's a ghostwriter, different ones like that.

And then I have my own plugin marketplace as well where I put a number of skills that are applicable to me. And so I just load from all of these in different ways. We also have a big monorepo that most of the engineers work in.

And a lot of skills just end up in there if they're monorepo specific. That's a much easier place. But yeah, it's the same problem. You've got to get a review on it. Or it's got to be it feels kind of dirty because you're just appending that to the work that you're also doing.

So it's like an add-on, which doesn't feel super great on the PR.

If I reverse engineered to some degree the plugin system, I think that's what they're trying to address kind of. Because you can also install a version of a plugin the same way you can an npm package. So maybe that's kind of like the interface on top of the repo.

And then the tooling that I'm seeing everyone keep building repeatedly is the tool that reads from a repo and installs skills into various places, like TUIs and stuff that make that kind of nicer. But that might be a solution to some degree where it's like, cool, there is this master skill of this.

But I'm running this version because I need this fork. But it's not as gross as it sounds because there's an actual standardized API with the plugin interface.

And it's all versioned.

Yeah.

When you npx sorry, guys.

No, no. These are great.

When you npx, do you then have flags? Is it that if you want to go into the public one or your internal work or whatever? I'm front end. I don't want every skill, even if the agent knows not to run.

Do you then flag where npx public flag just front end or just UX or just product? It's just come to my mind. I've never thought. Have you done it?

I haven't, no. I haven't used npx for that. I just used the like I said, we're mostly Claude. I've used the Claude marketplace, like the /pluginmarketplace add. And as long as your Claude instance can access an internal Git repo, it can just pull from there.

And so that's what it does.

It will pull all the skills, even the ones that you don't need because you're front end. You don't want the back end skills.

Oh, yeah.

Yeah. That almost sounds like a packaging thing to me. But I think that you're kind of in good company in a sense that it seems like we've kind of got three marketplaces that are super relevant separate from or in addition to the project-specific skills.

And then it just kind of becomes a matter of taste of each individual engineer saying, oh, I'm going to run this version of that skill. But then something like the plugin interface is the way that you have a uniform way to approach it, which you could actually write docs against for onboarding and say, plugin add these three marketplaces when you come on board.

And then if you're on a front end team, plugin install from the front end marketplace or whatever the case may be. But that's still at the end of the day, on the back end, that's like repo management. It's similar to how it works with code.

Yeah.

Yeah. Great questions. Yes, sir. Sorry.

I was going to ask.

Yeah. So it's actually two questions. The first one is, do you do any formal skill evaluations, like a skill benchmark, so that as a new model drops, which skills are relevant?

Yes. In the public skills specifically, on the ones that I use internally, I am a little less formal about it. But the ones that we actually ship, we do ship in the where is it? We have a whole evals framework that we wrote to make sure that it lives up to the standards that we have.

And we're going to talk about this a little bit. But it's mostly doing several runs where it will load Claude without the skill and ask it to do a task and then load it with a skill. And then it kind of has a rubric on confidence or a grade that it gives it.

And it'll fail if that grade is less with the skill than it was without. It'll also fail it tries to be, I think, 80% above or higher. So like 80% of the time or maybe it's 90%. It's going to get thisright with the skill.

And sometimes it gets itright without the skill. So the skill is maybe only adding 1% or 2% to it. But that's something that we track and keep on top of as new models drop.

Yeah.

OK.

It's sort of fuzzy math. But it's almost like by having this established baseline, you can at least test that way.

Yeah.

It makes sense. And then the second question was about

sorry, one second.

Right. Skill pickup. So if you get lots of skills, the models might ignore a skill or decide, I don't need a skill. I'll just do it. What's your kind of experience with this to, A, test it, find it, and then maybe improve it?

Yeah. Great question. That is a problem. And the more skills that you get, you can have conflicting skills. And so which one is it going to pick?

The solution to that for the Work OS one specifically, we try and keep it for these public ones, we try and keep it very generic, like mention all of the acronyms and things that we would expect to cover from that.

So that'll trigger it to load. And it usually does a pretty good job. You can also, if you're in a skill or sorry, in Claude, you can just do Work OS, for example, the / command if you know that you want to do it.

And so a lot of times, we'll just suggest if that's what you want, I'll say, just run /workos. And it'll load it.

I'll call a skill by name. If I want a specific image gen or something, I'll say or I'll say, use the superpowers brainstorm skill in order to determine a better plan.

Yeah.

Yeah. Yep. But also, if it really wasn't behaving, that's why you use the bang and then put a command.

Right.

Yeah.

I had a question on how do you decide when to create a subagent versus a skill? And can you reuse a skill into a subagent? And there's just some times that I'm going to create a skill. And then I'm going to maybe I should have written a CLI because why did I even made a skill in the first place?

And I struggled between these three things.

That's a great question. On the can subagents use skills, I actually I'm blanking on that. So I'm asking Claude. And you can see that it loaded the Claude Code guide skill to go check that. So this is a great example of doing that.

And we'll get the answer here in a moment. But that's a great question. Subagents is something that we don't cover a ton in this workshop. But it is something that's super valuable. And the number one thing that I think of when I think of when to run a subagent versus a skill is, do I want it to have its own standalone context so that it can go do a bunch of work on something?

And then that's not eating the context window of the main task job that we're doing. And then that way, it can just do a check-in on that. And so for example, I have this ideation plugin. It's kind of like a planner or a superpowers type thing that I like doing.

And as part of that, I'm really focused in on feedback loops to itself so that it doesn't have to bother me all the time about, hey, does this look correct? Or tell me, oh, it's done. And it's totally not done.

I want it to prove to me without me having to go look at the code that it did the work that I expected it to do. And oftentimes, that's feeding the information that I would look for back into it and making it just go in a loop over and over.

I hear there's a Ralph Loops workshop after this. So you should check that out. But

in that case, when it's doing those reviews, those can muddy it up. And so I kick off a subagent to go do those reviews. And then it just reports back like, I found these problems. And then it just has a list of those problems.

And then it can feed back to itself to do it again. So I'm not eating that full context window every time.

Yeah. Now also further confused by agent teams, which are different than subagents too,right? Yeah. Another question. Thank you.

And.

Yes.

Well, I've got another question here.

Yes. I have a question about the overrides in a skill. So for instance, you put a default. And you say, or whatever the user decides. But I find it's very random. Or I cannot really reproduce that. And sometimes the overrides doesn't work.

Yes.

Do you have any idea or I just want to find out what's going on.

My best suggestion for that is just ask Claude, why did you pick that over the other thing? And how can I improve that in some other way? You

consistently or you consistently enough pick the wrong choice or you don't respect my override. Why is that? What can I do to improve it? I wish I had a more clever answer. But usually, it's just like I ask the machine.

Just ask Claude. It's good enough. Thank you.

Great question.

Question?

You called out superpowers. It was a.

Skills library that you referred to. Is there other skills libraries beyond you guys that you commonly use?

Yes. Definitely. So superpowers is one that I actually didn't use until yesterday when Zach showed me it. And I installed it. It has a number of different skills in it that are pretty helpful. These slides are actually written in slide dev.

And you might notice well, you won't. I don't know if I committed it. Let me go to the full repo here. But in here, there's an agent directory and a skills and a slide dev skill. And Claude might have had a hand in writing these slides, which is really cool.

We'll kind of talk about that. But some of the real superpowers, I think, are when you assign it to do non-coding things because you really feel this magic. And we'll kind of show a demo of the remotion skill.

That one blew my mind. It created a video based off of a prompt.

I now use that as my so every Friday when we have the all-hands and it's like a quick demo of what you got done this week, it just reads my Git history for the week and then builds a movie about it, which everyone was tired of on week three.

And they're not going to stop. They're just going to get more like I'm going to introduce characters. And it's going to get awful. But yeah, the remotion is incredible. It'll even pop up a Chrome-based web editor where you can go and be like, oh, trim and cut.

And let me add some fades. So that's insane. And then my favorite one that I probably got the most leverage of since installing it was just I built it with Claude, just a simple Python wrapper around Nano Banana, the image gen model from Google, which continues to improve.

So I just say, hey, now it's on v3. Go update it. And we'll show a little something later. But essentially with that so most images now I generate with that, it takes like sub seven seconds in a single prompt.

But using that same model, I was able to say, take a single string from the user that's a prompt, say, like a child running through a field. First, it makes that image. Then it uses their video API Vio, hands that static image to it, and says, animate this static image in the most obvious way possible.

So one user prompt of child running through field, nothing exists. And then 30 seconds later, you have a video of it running through. And I was able to use that same method to do all of the interstitial scenes that I needed in a 32-minute film.

And I am not a video person. I mean, I like using DaVinci Resolve and editing stuff. But I'm not an animator. And I was able to get all of that done in maybe an hour. So those are pretty trippy too.

If you want to get really, really down there, I have Claude reading my biometrics and stuff and pushing back on me and telling me to take it easy this afternoon because he didn't get any sleep. But there's not necessarily a skill for that yet.

I think the ones that are really powerful are when Claude the other day blew my mind by saying it was also a superpowers. This is easier for me to show you the variants if I just mock them up in a web browser.

Would you prefer that? And I said, yes, please. And then it showed me all those. And I was like, A, go. And then we just built from there, saving countless tokens on just text iteration.

And I'm using that Nano Banana skillright now. But I just ran /plugin. And I'm looking at the marketplaces I have installed. And some of the most important ones to me, I think, are the Claude Plugins official one. I think that's where it has a nice skill reviewer skill or skill creator skill, which is really good.

Obsidian is something that I use all the time. And so having the Obsidian skills and it knowing just how to use that. So it's based on what I want. But then also one that is actually very good where did it go?

Plugin is the Codex skills marketplaces. I don't know why it's not showing it.

There. The OpenAI Codex ones.

It's not scrolling down. But anyway, that is like Claude does all this work. Codex is pretty good at reviewing it. So this is a skill from OpenAI that just pipes that to Codex and says, review this. And it goes and reviews it and then delivers that back to Claude.

And I have cut myself out of the copy and paste game of Claude said this and Codex said that and going back and forth in teamwork splits. So I'm super happy about that.

Yeah. I would say Vercel is pretty skills forward. They've got a bunch of CLIs and stuff that are pretty interesting. And they were kind of the first on using some of the marketplace stuff. So check out their open source skill stuff too as well.

Great question. Thank you. OK.

That's what Nano Banana just made.

Close. Close-ish. Yeah.

Awesome.

But the fun thing about that is that you can ask it for any style. So you can say I mostly do pixel art. So I'll say old school pixel art. And it's a lot of fun.

Yeah. Allright. We are at time for this piece of it. Did anyone build

a first pass on the repo row skill that they want to share? Yeah?

Cool.

Awesome. If you want to run ./share.sh.

I uploaded it.

Oh, cool. Sweet.

This guy. Allright. Wins the workshop.

Allright.

Are you Sharif?

You're Sharif? OK. Are you

OK. I'll run well, I'll just run all three of them real quick. So I'll run them on the skill sorry, this workshop. Oh, what did they do?

That's pretty safe. Don't you want to run it against Work OS or something or the CLI?

Yeah. I just realized that it loaded it locally into this one not in a global way.

Oh.

I can do that.

OK.

Sorry.

I'm going to give it the Work OS CLI. And then I'll say, repo roast Zach B on the CLI repo. We'll see what it does.

That's a new verb defending the Chrome bug.

Oh, yeah. You can customize those. So a lot of my spinner verbs are Lord of the Rings or The Office themed. So you'll see defending as Gilead and things like that.

I didn't think that would work. But that's OK. It's running against the workshop repo.

OK. That's fine.

So it's running all of the commands that you gave. And while we're doing that, I will bring that up.

So this is Zach's skill. Nice good description. Analyze repository health by running Git and file system scripts to find stale to-dos, churn hotspots. Yeah. That's good.

And then it tells it specifically how to find stale to-dos. Awesome. Hotspot files, largest files. Nice. Constraints never be vague for evidence. Never present a finding without a script output or Git data backing it. That's probably why it's running still.

Oh, nice.

Yeah. Scope.

OK, Zach B. OK.

Nice.

Nice skill.

You didn't tell it to just be mean to you.

Yeah. Be super mean to Nick and Zach while they're on stage.

Awesome.

Hi, Amy. She's pretty mean sometimes.

Allright. Awesome. We'll run more of these. We've got more things to get through. And we'll do this again. And we'll test another one.

Yep.

So moving on to the next section, we're going to make that skill smarter. So the first thing that you can do to make your skills smart is by providing more information to it. But this gets into the problem of the Claude.md, where you can be extremely verbose in there and give it so much information about your repo.

And you're just bloating the context window because it doesn't really matter. Well, you can do the same thing in skills. But you can do it in a better way. And that is specifically with progressive disclosure. And I guess you could do this in a Claude.md as well.

But all it is is just saying, hey, if you're thinking about doing testing for excuse me, for example, load this file that I have on testing and read through it. And you just give it a path, like a local path to testing.md or whatever.

And that way, it's only going to load that if it's actually doing a testing skill or a testing task as part of the skill run. If it's not, it'll skip that. And so you can specifically tell it, oh, in this example, if you're doing a scoring if this is a run where it's doing scoring, run the scoring

load the scoring rubric and read through that. So we explain to you how to score things properly. If we're not doing scoring, you don't have to load that. And we don't have to fill up the context window with all of that bloat.

Yeah. This also gets back to that gentleman's question in the back too of you can imagine this pattern really scaling out. So the way that it actually did scale out, even in our public Work OS skills repo, you can go and check out.

We have multiple migration guides that we publish for various folks. So if you're coming from Auth0, we'll happily help you move off Auth0 to get to Work OS. And then there's n number of competitors, essentially, that we've got migration scripts for.

And so in this case, you could say, here's the migration skill. And the migration skill is a pointer to the specific reference. So you're not bloating your context window. It's just loading the two markdown files it needs.

Yep. And if you look at the Work OS skill, we literally call it skill router in there. And it just has a reference map. So if you're going to install AuthKit into Next.js, you should probably load the Work OS AuthKit Next.js.md file from the references.

And so if you're not working with Next.js, we don't want to load that and bloat that. We only load it when you need it for all of those. And so this file is just filled with routing to the actual pertinent information that you need.

OK. Another way this is, again, to some degree, it's fuzzy math under the hood if you really get down to matrix multiplication. But nevertheless, another way to boost performance here is to kind of enforce confident scoring. And one of the reasons that Nick's Ideation Plugin, which is open source that you can go check out, works so well is that it has an internal counter of confidence of how close am I to fully flushing out all of the variables that this task requires before I can go and execute.

And it then forces an iterative loop with the user of continuously asking additional questions until it gets to the point where it's like, I'm 95% or above confident. I've mapped most of this problem space in my head. And now we can start work.

And the result as a result, the output is likely better. And so that same concept applies here when you're building skills. You can kind of add in that same functionality and say, for this particular aspect of the codebase, you must always find this evidence and then get to a point until the tests are either at this level of coverage or you have this level of confidence on A, B, or C.

And that's another way to essentially boost performance in the skills.

Yeah. It's really important like Zach was saying. It's just like kind of pulling that number out of nowhere. If you say, how confident are you? And it's like, I'm sure confident. Well, why? And as you give it ask it to show more of its work as to why it's confident.

It might be like, oh, wait. I'm not actually as confident as I thought. And so that's the whole thing is trying to get it to think more. In the terms of the Ideation skill, what it's doing is it's using that to assess that it has a full understanding of what I'm trying to say because I have a problem where I don't give it enough information.

I have the information. I know what I want. It's hard for me to express it to the machine in a way that it expects. And so it's using that confidence score to say, eh, I don't have a full rounded understanding.

And it loads a whole rubric on what it means to be confident on something. But then if it's not confident, it uses Claude's built-in Ask User Question tool to ask me a number of questions to pull that information out of me rather than me being like, eh, you're not confident.

Let me try and give you more insight. It's like, no, I'm not confident because of these things. And then here's how you can make me more confident by answering these questions. And a lot of times, it'll just give me multiple choice.

So I'm like, do you want this? Is this what you mean? This is the recommended approach I would take. But if you want to go this other way, we could do it that way. And so we have that dialogue going back and forth with it.

But it's all based around how confident is it that it understands what I want and understands how to do what I want.

Yeah. And so then this gets back to just kind of in practice the way this works or at least how it has for me and what we kind of recommend is build an initial skill. Maybe you're doing that yourself in Markdown.

Maybe you're using the skill builder in Claude and saying, I need a skill to do X. You're doing it. You're using that skill for a couple of iterations, maybe a couple of days, maybe a week. You look at what it produces.

And then keep in mind that as you're having multiple conversations with, say, Claude over the course of a week, all of those conversations are even getting saved locally to some degree in JSONL files. And so you can be honest with the evaluation phase about, is this actually improving things?

Is it not? Where does the skill fall short? What are the edge cases it's not currently capturing? What's the annoying thing that I've now discovered that I've been running it seven days that it's missing? And then you kind of iterate.

But again, you're still going faster because you come back to a state that's already working. And you say, these three edge cases are driving me nuts. And you also need to be able to review your own PRs in the future.

And so then once that loop is done, you have a skill that's significantly more powerful. And then you can keep on running from there. But it's kind of like they're sort of evolving over time. So they're again, I think of them as organizational units of where to put kind of work intelligence.

And then over time, if you're doing itright, they're getting better.

Yeah. When Skills first came out, Zach and I were actually at an onsite together in San Francisco. And we woke up one morning. And they're like, us introducing Skills. And we're like, well, this looks like every other Markdown file that they provided.

What's the difference? And later that day, we presented on Skills like, I don't know, four hours later. And the one that I built to present that was a Claude skill, Claude skill that would analyze it wouldn't analyze your skill running because nobody had Skills like four hours into them existing.

But it would analyze, oh, you just did this task with Claude. Let's go through and pick out what could have been what we could encapsulate into a skill so that it can do that in an easier way. And since then, there's meta skills and things like that that have come out where it will analyze the performance of actually how you're using Claude or how you're using the skills in Claude.

And then it can use that to feed back in just like Zach was saying, just by looking at those JSONL files. They're these logs of the conversations that you're having with Claude. And that can inform it on how to improve things.

So for example, in the repo roast, if it's kind of being wonky about how it's pulling in Git information, adding in the bang with the specific Git command that you want it to run to get log information, that's a way to improve it so that it doesn't have to iterate over that and say and you come back to it and say, no, that's not what I wanted.

I wanted it like this. You can be more explicit with it. And that can be fleshed out by reviewing the performance that you had the first time or the first couple of times.

The other intuition I'll share is that it's kind of like in my experience recently, it's the types of nagging things that I find the most cognitive resistance to doing every week that I actually need to turn into skills.

And so a breakthrough moment for me was realizing that context switching between Slack and focusing on code and then going and ticketing new asks in Linear was so disruptive to me that I just needed Claude to do that.

So now it just monitors. And when someone asks me for something new in Slack, it goes and looks in my Linear. And then if there's not a ticket for it already, it does deduplication, adds a new ticket. And then I haven't left my flow.

I'm still able to focus. And so that's kind of the intuition I have now is that you can I think it's really powerful. And I think we're only at the very beginning of it, analyzing your own workflow over time, feeding it more information about how you actually work, and then letting LLMs do what they're really good at and compress down that actual time.

Is there a skill idea that you'd recommend for that?

Oh, was there?

Is there a skill you mentioned that there are skills out there that may ask Skills to review your kind of past conversations and propose skills or improvements. Is there one that you use or would.

That one there's not one for that. And I didn't do this myself the last time. This was like last week. But what I should have done is say, hey, Claude, use Skill Builder yourself because Claude's got that baked-in skill hyphen builder, I think it is.

Use Skill Builder to look back at my workflow and tell me where it's the least efficient. And then that's also pulling in connectors because there's a Slack connector. And there's a Linear connector. So that's where the Markdown might be referencing.

You must always use the Slack connector to pull in this. And I only care about these channels and direct mentions of my name. But yeah, I think it might even be faster in some cases to just say, here's where I work.

This is the tool that we use to communicate. Make me a skill that does that.

Yeah.

Which is also kind of crazy.

I think this is the one that I was thinking of specifically. It's Claude meta skill that helps you configure Claude, including setting up those skills. I think this is the one I've used. But like Zach said, I've also just asked it to review its own performance and kind of go from there.

One really great thing is I built this pretty cool tool. And I wanted to write a blog post about it. And it was all built with Claude. So I was able to just go ask Claude, hey, remember that time we did this fun thing together?

Let's reminisce about it. And we just talked about it. And it led to these anecdotes that I added to the blog post that I completely forgot about. But Claude was very fond of that moment between us.

That's not what's happening. You don't understand that.

No, I don't.

Under the hood, that's not what's happening.

Don't lie to me.

Do you use any skills for memory for maintaining a memory state within Claude?

Great question. Claude has its own memory built in. And there's that auto dream thing. I don't know if that's real yet or if it's like a thing that's coming. But it will actually prune the memory. And so I've been focused on building around that.

But I've been building it in Py specifically. And so I built this I built what it would take to be a DX engineer at Work OS as a full agent using Py. And it's called Case. And it uses memory internally, like memory.md files.

And it works across all of our open source repos. So it knows React and React Router and Next and TanStack Start and all of those. And so then it has general memory files and then framework specific memory files.

And it goes in and prunes those and updates by doing as part of its flow, doing a retrospective at the end and analyzing its own performance and then saying, oh, I spun in a circle a bit for this.

I could have once I got to there, I can just save that to memory. So I know this is the command I run next time to get the information I need. And it just keeps track of that. I haven't built in the full dreaming thing where it prunes that yet.

But I'm experimenting with it.

Yeah. And also, I want to play with the Obsidian connector more because I think that would be super powerful. I had a habit in the past of using Obsidian and just making a daily to-do with just the date as the title.

And then so I think writing to and reading from those vaults so that you could imagine saying, look back over the last week. Last week, it's translated into what are those actual dates. It fetches those files directly. And then it can also write consolidated memories.

It's also worthwhile playing with things like Open Claw, which I've done because that memory system that it ships with was surprisingly good, better than a lot of stock Claude or OpenAI's stuff. And so seeing how it does that with daily journal.mds and then the consolidated memory, which I think the dream stuff is kind of pointing towards consolidating memory over time.

Yep.

But a lot of times, the crazy thing about this is the answer is one turn request with Skill Builder is the fastest way.

Pointing it to.

Yeah.

This is a good repo too.

Yeah, 100%. Yep.

So we're going to jump into the next piece of work on your side. And that's adding phases and confidence scoring to it. So adding progressive disclosure, adding a confidence score, telling it, how confident are you in this? Or we've got some examples of that potentially.

What's a good example?

How confident are you in this? You installed authKit correctly?

Yeah. But I mean for repo roast.

Oh, for repo roast?

You gave me a bad score on, I don't know, Git commits. Why is that?

OK.

Have it dive down deeper than just.

Yeah. This is our pattern of how we use Git commits. We always have our messages like this. We're following these conventions. So then based on that, what's your confidence that this is correct to our repo?

So for example, you might use conventional commits at your work. And if you find commits that aren't like that or you find a bunch of merge commits in there, for shame. But yeah, different things like that you can add specifics to and have that as

a progressively disclosed rubric that it can follow for those things.

A quick housekeeping thing. In case for any reason you're behind or feel behind, you can run setup.sh and then checkpoint 2 to get to the same spot that we're at now.

Yep.

And then yeah, any other questions, feel free to shout out. And I'll run you a mic.

We'll spend about five minutes here. And then we'll move into the next section just to make sure we have enough time.

Do you want to talk about any of these topics, Zach? I can talk about when

confidence yeah, confidence scoring saved us.

Yeah, what's that?

That was when we were working on the when confidence scoring saved us.

Well, that was kind of built into the evals that we wrote. Claude ships with a whole eval framework now that you can use. And it'll spin up a GUI for you. It'll create an HTML report. And you can see before and after and all of this insight into how your skills are running and whether they're actually improving Claude or making Claude worse at the task.

But before that existed, I was writing my own to do that. And it was all based on that. And so let me bring up the

ideation skill. And I'll just say, let's see. We'll go to the CLI.

And I'll say.

So for context, this is our Work OS CLI that we're building.

I'm on the main branch of that. I use work trees for that. What's a feature that we want to add? I want to add a fun slash buddy command similar to how Claude Code shipped that for April Fool's Day.

I used a tool called WhisperFlow to go full WALL·E and not even type anymore. And I just press a button. This is how I code now.

Do you prefer that over the Claude voice mode?

Yeah, I do. I've been on WhisperFlow for maybe a year now. And the thing I like about it is that it can input anywhere on Mac. So if you're in some funky old website in Chrome, it works there.

It works in Safari. It works on any app that you've got. As long as you can focus a cursor there, you can insert text there. And it's also fine-tuned towards technical terms. So you can say@userauthentication.ts. And it'll come out correctly.

You can reference files, et cetera. So it's great. I imagine that more and more of the tools are going to get their own native voice. And over time, that's going to become a dominant interface. Butright now, WhisperFlow is a pretty sweet experience.

Yeah.

I turn on fast mode so it'll go faster. Yeah, it also does cool things. You can say, when you're dictating into Slack, be more casual. When you're dictating into an email, be more formal. And it will kind of.

It's sort of context aware in the formatting that it'll put out. You can say it knows you're in Gmail or it knows that you're writing code or requesting code.

So this is an example of the ideation skill. I gave it that simple command. And now it's saying, oh, what do you I don't fully understand what you mean. What kind of fun are you looking for? I'll say a visual gag.

ASCII art gallery, sure.

Hidden Easter egg, yeah, we'll go listed but subtle. So I give it one sentence. And it's like, well, what do you mean by that? And it's like pulling all of that out of me.

But there's the value in thinking. It's like the same way that a good engineer in a whiteboarding session would kind of draw the same stuff out of you.

Yep. And soright there, it did this confidence score. Based on the problem clarity, it has a 20. Goal definition, 18. Success criteria, it doesn't really know what I'm asking for. So that's the lowest one. Scope boundaries and then consistency.

So those all add up to 100. And I got a score of a 90 out of 100. So it's not going to just be like, OK, I know what you want. It's going to ask me some more things.

Like, oh, we'll do that. And we'll just have minimal. I'll say zero config. I just want it to go fast. And so now I'm at 96 out of 100. So it understands what I want. And now it's going to write a contract for me to read.

I read and review the contract. And then it's going to build from there these phases that I can execute or these specs that I can execute in phases and then go from there so that I can clear the context for each one and have a fresh context going.

Yeah. The way I would say that is, is the math there tight? No. Does it matter? No. Because the value is in the iterative loop of clarifying and clarifying your own thinking by responding.

Yeah. Oops.

And so there's the contract that it's loading.

And it tells what success criteria means, the scope boundaries, what's in scope, what's specifically out of scope, any future considerations, how we plan to execute it. This is an easy one, just a single phase. And so it's going to just create that spec for me, which it did here.

And then I could run this and go. And so it was all gated on that confidence score.

Cool.

Allright. You want to jump into.

Yeah, let's do it.

Allright. Well, we're going to skip ahead into the next section. And we'll have one more thing. And we'll do some sharing after that one. So kind of moving beyond the editor, we thought about this. And we're like, does that title make sense?

Skills beyond the editor because we're not really in an editor. But for us, we kind of are. I don't open Neovim nearly as much as I used to. So I've lost my identity a little bit. But yeah, these skills, they really do work in a lot of different places.

Another thing that you can do is you can level up your skills in a number of different ways. So for this repo roast, for example, you could have, oh, I want to know who the BusFactor people are. So use Git short log to understand who's committing the most, who's committing the most in specific sections of the codebase.

And list out what the BusFactor is and how vulnerable we are to that. Commit crimes, this would be people who just have bad commit messages. It's so easy. You just tell Claude, commit it and go. Zombie branches, you could list out all of the branches that never went anywhere or that are still hanging around.

Who is committing at 3:00 a.m.? Who's up the latest working and making us all look bad? And then this one is definitely something that you should add. And that's.

Read.

Yeah. Is my README real? Does it explain or describe real things?

Yeah. And so again, the reason that this is so powerful is that it's no longer specific to any foundational model provider. You can define these skills. And then you can use them locally in Claude Code. But you can share them with your team, as we talked about, with a Git-based plugin architecture.

But now you can also put them in Claude Desktop and web, as we talked about with the recruiting team. Folks that identify as completely non-technical are loading specific skills and running them in their own sessions.

And sharing them.

And sharing them. And then now, as we're finding agent harness is becoming more and more relevant. And so things like Py, which is what Open Claw runs under the hood, you can load them there as well. So the value is really in defining the discrete work block and then figuring out exactly which tweaks make it the most effective description of getting that work done and then sharing it with your friends and putting it on different boxes without having to do much more than authoring some Markdown and possibly some scripts.

Yep. And skills, if you took a skill file, you took repo roast with that skill.md and any scripts or references and all of that. But you took that folder, repo roast, and you zipped it. You'll get a .zip file back.

Rename that from .zip to .skill. And now a non-technical teammate can drag that into Claude Desktop and use that skill. And that's just how they're shipped. That's a really easy way to share them, not a really easy way to version them.

They're still paying too around how do you handle sensitive credentials in that case. You don't do it that way. Please don't put it in the zip file.

For sure.

But it's evolving.

But you can also use those marketplaces. The Claude marketplace works in Claude Desktop as well. So that's an easy way to share skills if they are applicable to non-coding workflows.

Yep, for sure.

And so some of the we've talked about this. But one of the things that I really wanted to drive home is with the Work OS CLI, it's like a generic CLI that you can use to do Work OS commands in it.

But its flagship feature is this ability to just run install. So if you have a project that doesn't have auth in it or you have other auth in there that's not Work OS, you can just run Work OS install in there.

And it's going to politely remove the other auth that you might have in there and then add in based on what you are using. If you're using Next.js or tansect start or whatever, it's going to figure that out and load that in there for you.

And the CLI is using the Claude Agent SDK, which is like a programmatic Claude code that I can ship in the CLI. And the smarts of that, all of the brains are actually skills that are in the Work OS Skills directory.

So it knows all about that. And the reason we did that is so that we just had the two birds with one stone. We build the skill. And we make it good. And then we prove that it's good by having the CLI run it.

And the beauty of the CLI is it's an easy command. You just do npx work OS install. And we're proxying all of the commands to Claude so that it hits our API token. And so it's an easy way to just say, here's a zero-friction way to get set up with it.

It'll even create a Work OS account for you. And you can go back later and claim it. So it's like five minutes and you're set up. And all of that is entirely skills-driven.

Yeah. Another place we're seeing high levers with this is, imagine, blog writing. Lots of folks on the team, as it's growing, want to write blog posts in a uniform way. But they don't know exactly how our CMS works, exactly the tone or format and the conventions that we use.

And that's the type of thing that you used to put in a Notion doc and then hope that you could inject it in someone's Slack and force them to read it before they write something. It's just easier to define that as a skill so that they can interact with it and then get to 80% of that artifact without having to consult somebody else, essentially.

Code review, image generation. With image generation, too, you can also put additional parameters there to get specific styles as well, CI pipelines. And as I mentioned earlier in the talk, once Nick had published the public repo of Work OS Skills, the RAG pipeline was able to just start loading them all as agentic tool calls.

And performance on all those queries just jumped over just flatly chunking all documents and putting them in a vector database, for example.

And you saw the giant lobster outside when you came in. That's all can be skills-based as well. So skills are just this uniform way that transcends the Claude Code or the Codex and is something that you can load anywhere at any technical skill level.

So it's really easy. We talked about evals. Measuring this stuff matters with the skills, specifically with the Next.js installer skill. I actually found out through my evals that I was making things worse because I was overly prescribing what to do with Next.js.

And Claude Code was just inherently good at working with Next.js. And I was making it worse by being too dogmatic about what I wanted it to do. And it led to a 30% drop, I think, in overall accuracy based on these numbers I made up.

But I was able to use that. And I kind of think of evals in a lot of ways like my Apple Watch. It tells me my heart rate and how many calories I'm burning throughout the day. Is it accurate?

No, of course not. But it gives me a general baseline of like, oh, I am more active today than I was yesterday. And I can kind of use that to gauge where I go forward. Is it accurate? And would I base my life on it?

No. But it's a general vector that I can look at and see whether I'm improving or making things worse.

Yep.

So some skills in the wild. Zach, you've made a couple of skills. These are specifically not code-related. But they're pretty impressive.

Yeah. So this is the one I was talking about earlier, just to show what I am the most excited about is taking what seems like an incredibly complex workflow and then just making it available as a skill. So

this is an example where I have a Slack avatar that I had generated for me months ago. And I just handed it to this animation skill. And I said, animate this in the most obvious way possible. We'll see if that's actually obvious.

So taking a giant ball of energy and grimacing at it as one does. But the point is, that was a single text prompt of like, make this person look like they're in Fallout holding a ball of energy and then animating it.

This one is the same exact skill, so same Markdown file and two Python scripts saying the prompt was child running through a field.

And there's also sound with this because it's hitting the VO API. So again, at first, Claude reads the Markdown skill, says, OK, I understand what this is. It's a sequence of two API calls I'm going to make. The first API call is the user's prompt to make the static image.

The second API call is the output of that, the static image. And then a new prompt that I write saying, animate this in the most obvious way possible, hitting VO API with that, and then getting back an animation.

But again, that's like 30 seconds of generation time. And so I use this exact same workflow to do all of the interstitial scenes in a film recently.

And another example, I mentioned this earlier, but the remotion skill. I'm terrible at video editing. I don't know anything about it. But when I was working on the Work OS CLI, I thought, oh, it'd be kind of cool to make a fun video that I could use on Twitter to demonstrate it or talk about it.

And so somebody was mentioning remotion. And I just asked it to make this. And it put it together pretty much like this. I asked it to use our actual logo rather than some made-up one. But it even understood the output of the CLI and put all of this together into a demoable video that showcases what it can do.

And I didn't have to do that at all. And I looked super impressive without knowing anything about video. And also, the skill, when I said do this, it loaded up a localhost:3000 in my browser that was a full remotion video editor.

And so I could see it playing on a loop in there. And it was doing things. And I'm like, oh, you didn't use our actual logo. Go use that. And I just told Claude to do that. And it just updated in real time.

It was so cool.

Yeah. So imagine hooking this into your GitHub CI/CD flow. And then at the end of a big project or every time a milestone gets merged, you auto-update whatever document and then even include a demo. It can start to get pretty powerful if you orchestrate skills that are well-defined.

Is this the.

This is exactly how that one works under the hood. So you can imagine the one that I showed you that had the two YouTube videos. So if it's called animated image, the first one's going to be generate a minimalist static image and then take that image and animate it via VO.

And there's just two scripts. There's one to generate an image here. And then there's one to generate the video. But the skill file itself is like 30 lines of Markdown.

Yep. And that Nano Banana one that I ran earlier, that was just like coming up with a creative enough prompt, taking the idea that I had, flushing out the prompt. And then it passed it to a TypeScript file that called the Nano Banana API and got the image back.

So that skill is just basically like a simple LLM wrapper

around a TypeScript script that uses their API to go do that.

So it's also just broadly applicable to workflows. It's not just a dev thing. You can imagine if sales has a very specific way they have to reach out to people or there's always a type of report that you're generating for customers or prospects or whatever.

All of this is excellent for use with skills.

So did anyone have a repo roast skill that they want to share? Yeah.

I think it was.

OK.

Yeah. The Amy and Wolfram Ravenwolf skill. Try that. You have to see the results.

Which one is it?

Number two. I uploaded another one. Number six is the newest one.

OK.

Used.

I'll do number six.

Allright. So while that's running oh, no. We ran the wrong one.

There we go. While that's running, let's go look at it.

Oh, nice.

Ruthless honesty. I love it.

Brutally honest. With a heart of gold. Awesome. I love the context. Lots of.

Thick files. Very nice.

Yeah.

Excellent.

Constraints.

And here, the audience detection. You told it to load audience guide.md. Here's that progressive disclosure about that. This also just helps to keep your Markdown files manageable.

This is a 10 out of 10 skill.

Yeah.

Very nice.

All the credit goes to my engine.

This is awesome. Allright. Let's see if it gave us anything.

So it's grading the workshop itself.

Six out of 10.

Six out of 10.

Brutal. I feel that. I thought we had something going.

Fair.

But OK.

Ooh.

Raw.

Hopefully, you give us a little bit more of a grade than that. That's awesome. Some critical things.

Test suite isn't on fire because it doesn't exist.

Yeah.

That's great.

1,200 lines of monolith. Yeah. Yeah.

Git identity crisis, Zach, is two people. That's how it feels, too.

Hard coded secret. That's OK. It's not really a secret.

That's awesome.

Love it.

Super cool. Allright. We got three minutes left. Is there any questions or

anyone else want to share a skill?

So this is a skill that you can use. But more importantly, it's techniques that you can take and use to build your skills and build them up in different ways. There's a lot more advanced topics that we can go into as well.

We mentioned subagents, for example. Subagents is a great way to extend those skills without bloating the context and having it kind of do one-off things and then exiting. And to take this to the next level, I really recommend having Claude's own skill creator skill installed because you can just say, hey, I have this skill.

Is it any good? And it'll give you pointers. Or you can say, run some evals on it. And it'll run a full eval test suite on it and tell you, yeah, it's good or no, it's bad. And can go from there.

And then, like Zach was saying, reflect on the transcripts. Reflect on how you're actually using the skills. And you can use that as insight to see how to improve the skills and the execution of those skills. For example, if somebody kicks off a skill and it's always asking questions about a specific thing, maybe that's something that you can provide ahead of time.

Or if you see it like, oh, it's going and doing 10 tool calls, maybe you could condense it down to one or two tool calls and pre-provide that information so it doesn't have to do that each time.

Yep. Plus one recommendation on the internal skill creator. And the other thing it kind of

suggests you to do over time is to think about the way you manage your context, even stuff that you used to think of as disposable. So in the pre-LLM era, we might have dev'd real hard at the keyboard all week, as I used to do.

And then finally on Saturday, wipe it all away so that I can GitHub for myself. Now all of that context is gold. The conversation, especially what failed, especially what didn't go well, especially what was frustrating because now all of that is very rich context for a skill creator or refiner to mine and then build you a bespoke tool that's going to solve that problem smoothly next week.

Yeah.

And you can also think of skills you could use that progressive disclosure to disclose things to different audiences. So for example, you could, depending on who's running the skill, you could say, get config user.email and figure out who the user is.

Or you could do things like, oh, how many commits does this user have in there? They have 10,000 commits in here? OK, we can really roast with them. But this other person who has four commits, they're probably a new hire.

Maybe go a little gentler on them.

Be nicer.

Don't scare them away from this project that they just sent us.

Well, I'm just doing it, me, too. Question. Yes.

Very quick, Zach. Could you take me through again? You were saying about the context switching. You'd somehow hooked up Claude with Slack and Linear. So it sounded almost like it's constantly being able to read what Slack's doing.

Absolutely. I have it.

Is this a Code Code or Code Code? We use Cursor. So I don't know if we have the same.

Gotcha. Yeah. I'm using Claude Code now. It's possible to do it in Claude Code and Claude Desktop. But essentially, I just have the connector in Slack. So I say, I had to do GitHub or just had to do OAuth with Slack.

And then it can read my Slack messages. You can now run the loop command, at least in Claude Code, to have it do that every 15 minutes if you want. And then you say in the prompt, if there is not already a correlative linear ticket, make a new one for me.

If there is one and there's additional asks on this request, update linear. And then, by the way, you have a second terminal tab that's looping against your linear state. Kathleen works at Work OS. Earmuffs, Kathleen. I'm really working really hard.

You have a second one that's looping and looking at your linear tasks and then doing work for you, essentially. But the main point was just that yeah, sorry we're at time. The main point was just automate those loops.

So that's our time. Thanks so much, guys. Thanks for being an awesome audience. Thanks for all the great questions. Really appreciate it.

Thank you.