Introduction

I've been here before in November, and I also gave a talk about Clot Code. Most of what I presented then is completely ancient history. Things are moving so fast.

I was talking about things like custom commands and how to handle permissions, and Anthropic almost every week releases a couple of new things that obsolete a lot of the stuff that have been needed earlier.

earlier, so what I'm showing you now might also be outdated in a few weeks from now, but let's see.

I'm going to, it's three main categories that I'm talking about.

The

Efficient Context Engineering with Claude Code

first one is Efficient Context Engineering with Cloud Code, how to structure the context files and the skills.

Then I'm going to talk about orchestrating a deaf environment in TMAX and the third one is about actually I forgot what the third one was about um we'll see it when we get there all right so when cloud was released

initially the story was you open your repo you you type slash in it then it will create this one monolithic cloud MD file and then it knows all about your repository and all is great it's it's been later discouraged and a couple of

weeks ago there were a couple of posts about hey if you still using in it to start your development with cloud code then you're doing it wrong the better approach is to keep the cloud MD file very simple and and then put stuff in different layers of context them it's called in progressive disclosure

Progressive disclosure: global, project, and rules layers

disclosure the the concept and the way that works is so there's the cloud MD on on your user level. It's on Mac, it's this home cloud, and there you have your global things,

the thing that you always want to cloud to know, maybe certain preferences about how you want to address, it's manner of speaking, but also maybe some basic principles to work together

that they always should know what kind of tools you're using, like, hey, we're always using PNPM instead of NPM, or we're using BUN instead of NOTE,

that kind of thing and then you also have project level skills obviously sorry user level skills which are skills that you want to have available in all the projects you work with cloud code and then you have the same thing again on the project level and then inside the project you

have an additional thing which is called rules which is also a folder that is cloud is reading when it loads up when it starts up and that helps a little bit so when when cloud starts up in your project it will read both your cloud md from your project as well as the rules file and the rules help a little bit with for example certain development specific rules hey if you

want if you're working with typescript then these are our conventions and you might not want to put that in the cloud mb just to make it a little bit more modular but in the end it's going to read both the cloud md and the rules files and then you have your project level skills and then

Then you have the docs, which is not a thing that Claude automatically uses, but it's more of a convention that inside of your .Claude folder, you also have your docs that maybe are used across different skills.

Skills basics: user-invoked vs model-invoked

The next thing that you need to be aware of that there's two main kinds of skills, the ones that are invoked by users, and then... Sorry, the ones that are invoked by users and the ones that are invoked by the model.

And... Okay, sorry.

The difference is obviously that the user invokes once you invoke yourself by using a slash command, while the model invoked once you describe in such a way that when you ask Claude to do certain things, it will find, oh, there's a skill and the description matches of what I currently want to do. So let's maybe invoke that skill.

And in the skills, there's something called front matter, which is which is basically just something in the skills MD file on before you describe the skills I can show that I'm real quick I just have to I can't I can't properly read it from here unfortunately okay I'm gonna do

Skill front matter: discovery, tool access, model choice, and argument hints

that a little later sorry I'm going to show some skills later so there's front matter and the skills and they have those flex inside like disable model model invocation or true or false to determine whether or not the model could discover the skills or it's rather for the user. There's a couple of more interesting things that go in the front matter.

The name of the skill is just the one that you invoke it with, with the slash command, but then the description is extremely important for all the model invoked skills because the description is what the model will need in order to decide oh yeah that's a skill that I want to use for the workflow that I'm currently doing.

Then we have a couple of other interesting things. You can inside of a skill front matter allow cloud to only use certain tools. For example for this skill you only are supposed to use these read only tools like read and grab and bash and then for other skills. So there's a couple of built -in Claude tools, and you can here tell Claude which of those tools are available for a skill.

1The other even more important bit is that you can define which model should be used for a certain skill. That is extremely helpful when you have skills that you don't really need the full power of Opus. For example, it's just a file linter or something where you want to write a git commit message from all your stage changes. You can use Haiku or Sonnet for that, and it's a bit of a waste to use Opus.

Not so much in terms of tokens, because Opus is more expensive, but most people use the subscription anyhow. But in terms of latency, because Sonnet or Haiku are much, much faster. So if you want to do something that really doesn't need the full power of Opus, you will find that your cloud skills will be much faster when you say, say, hey, this skill runs on Haiku and this skill runs on Sonnet.

Another thing you can do with skills is that when you call them, you can make it so that after the slash command, you get an argument hint. Let me just see if I can find a skill where I can show that. I can't really, unfortunately, it's not showing on my screen, so I don't really see.

Yeah, I can do that for sure, the problem is that I cannot read it from here because of the angle. You know what, maybe I can do, I don't know, okay, sorry, I want to increase font size, I want to increase the font size again, okay, so now, I'm going to find the right skill to use.

oh yeah so for example in this window here okay okay so there's a skill called in here there's a request click on Redis Explorer yes and this is really annoying I'm so sorry about that I didn't know that it's gonna work like this so you can see these are the user hints you can basically give the skill hints hey you can pass me a parameter prod or preview or local and then and after that you can put some more things. This is what these skill argument hints are about.

So there's a couple of really useful things in the skill front matter that you can use to basically give your skill some superpower.

Another thing you can do is you can have hooks, which we're going to talk a bit later. I have to make fast because I have a lot of slides. slides.

Common skill types: conventions, components, domain knowledge, and workflows

So what kind of skills do you usually have? This is just from a random project that we, sorry, this is from a random project of us, so what we have is usually skills like hey these are our linting rules, when you write TypeScript use types and not interfaces, when you write CSS use nesting, don't use utility classes, that kind of stuff.

If you have like a couple of rich UI components you can have skills that are experts in that components. Hey, I want a data table, so I do slash data table. The skill knows all about the different configuration options that I have on a data table.

Do I display the header or not? Does it come with a filter, with sorting, with paging, that kind of stuff.

Then you have skills for domain knowledge, skills that know your business domain, your data model. You can ask the skill, hey, that's our account model. Is that field nullable? Do we have that kind of thing?

saying, can you print out the relationship diagram for our trades and accounts, that kind of thing.

And then the workflows are skills where the cloud knows your software development process. It knows, hey, whenever you make it add a new field to the entity model, then you need to run this script and this script, and then you need to wire up some permit files, and then you probably need to run another linter and whatever.

So these These are the types of skills that we usually have.

Sorry? It would be, if it's mostly text processing, summarization, if it's something like, hey, just follow a couple of linting rules, then you can use something like Haiku or Sonnet. If it's really supposed to reason, if it's architecture,

if it's going to, hey, I want to implement this new API and I need to make it efficient. So when you want it to reason a bit more, if it's a complex task, then you would use a skill that uses opus and if it's if it's like a very narrow task And if it's mostly a text -based test then sonnet or even haiku are good enough for that

Yes The the cheapest is haiku in terms of tokens and it's also by by far the fastest So the the latency makes a huge difference opus is really slow, but smart haiku is really really fast

There was a very well received blog post from this guy here, from Tarek, he's a developer relationships guy at Anthropic. He posted how they use skills and added their skill classification. This post had over, I don't know, 50 ,000 bookmarks and shares, and this is an extremely

useful post if you want to get into skills. It's right from the horse's mouth. It's how how anthropic put put their cloud code skills in their own project and they're in this case He in this skill he describes that they are using this set this kind of a skill taxonomy

So yeah best just Look at the look at the the tweet. It's it's very insightful. It's really there's a lot of alpha and that in that one post

Orchestrating a Development Environment with TMUX

Okay, I'm going to move on quickly to the environment and orchestration so what we're doing we have relatively complex monorepos that there's a lot of stuff inside there's a there's there's dockers that run all sorts of databases and middleware layers and and apis and there's a ui libraries and front ends so usually there's a motor monorepo

Describe your TMUX layout so Claude can navigate panes

that has a lot of stuff inside and if you work with claude in such a monorepo then it's extremely helpful when you tell Claude that hey listen you live in this in this TMUX in this TMUX session and it has all these different windows and panes and Claude knows exactly what lives in which panes you can for example tell it and

it's a that's just an example I'm going to show here so this is this is a project where we're telling Claude these are all the different windows that you have them in here you have some CLI panes where you can just do similar CLI stuff.

In here you have the, in the server window, you have four panes in which different backends and frontend servers are started. Then here there's the one that has a TypeScript watcher.

So Claude doesn't need to start TypeScript every time it has changed TypeScript because it always takes a lot of time and sometimes it's, oh, the server's already running and I start another one. And in this case, it can just read the pane.

You literally just I just tell Claude, hey listen, when you want to see how your TypeScript build is doing, you just read the last line of this pane and if that says success, then you're good and if not, then you have TypeScript error, so you have to read more of it.

And this is a huge unlock because suddenly your development workflows become really, really quick. So, we do that, for example, in here you can see that those are the different panes from, So here's some stuff with the Docker, somewhere here is the TypeScript watcher, somewhere here we have a couple of servers and Cloud knows all that.

I can tell Cloud, hey, can you see if the other server is still running? And so it knows from every session how to look into every other session.

DB and Redis explorers: query helpers tied to specific panes

Or in this case, I can ask it, hey, what's the DB? Sorry, unfortunately, I can't read it there. What's it called? Yeah, DB Explorer.

Here you can ask it, hey what's the top 10 politicians, it's a data set of politicians by last name or something.

And in that pane for example there's, so the skilled DB explorer that knows exactly, that knows our data model, it knows the tables. I don't need to remember what the tables are, I don't need to remember how to construct how to construct a SQL query because Claude already knows all that and he knows that there is a pane that runs P -G -C -L -I -N

and just run the SQL command and pipe it in that other pane. So if you set your development environment up like this you will find that it's a real joy to work like that with Claude.

Here you have the Redis Explorer, you have all these different specialized windows They just know exactly what's what's going on

Okay, yeah, so okay.

Well, I just talked about the typescript checking well, okay, and then I could

Hooks, Automation, and Headless Workflows

Go on another 10 minutes about hooks because if you start to use cloud hooks you can these are lifecycle events that fire whenever things happen within Claude For example, they Claude knows hey when the session starts this hook fires when this when I start to use the tool this hook fires and so on and with these tools

what you can do you can things like whenever you edit a file edit to a linting queue and when you're done you go and lint all those files that's what I'm what I'm doing here unfortunately I have no time no longer to show that or

you can you can build I've built a whole tool that basically shows my shows my my Clot in real time and I can see how Clot is working while I'm, now I just have to find

the, this is so annoying. Is that running? Okay, this could have done better.

Hey, if anybody wants to see that later, I'm going to show that, I'm going to show that afterwards.

Real-time visibility and running Claude headlessly

was I'm sorry it didn't didn't work so well yeah finally you can you can run cloud in headless mode and let it run git commands that or whatever commands

Conclusion

you want unfortunately I'm out of time but I will be up there later and I can show you especially this thing that is driven by by the hooks I have a full visibility in real time but how cloud is working what skills it's using and I can a lot of do a lot of fun stuff with that all right that was it sorry for the for the awkwardness