[00:00] In this video, I'm going to show you nine advanced cloud code features that most people don't even know exist. We're going to go through custom sub-agents, scales, hooks, MCP servers, parallel sessions with things like Git Worktree, headless mode, and much more.
[00:16] Every single one of these is going to come with a real demo so you can see how you would actually use it, and by the end of this video, you'll be able to set it all up in your own project. If you want the references in this video, I'll leave a link below. You can join my school community. It is completely free.
[00:30] and I'll have everything here so you can follow along with a text-based guide. With that said, let's get into it and look at the first feature. So the first feature on my list here is custom sub-agents. Now, most people know that Cloud is capable of creating its own sub-agent.
[00:44] That means you can give it a prompt, and automatically it can delegate to other agents, or do things in parallel, right? So it can have multiple agents running at the exact same time. Now, Cloud will do this automatically, and it can make its own agents without you doing anything.
[00:58] However, you can also create your own custom sub-agent that Claude can then invoke. Now, the way you do that is you create a .claud folder, you then create a nested agents folder, and inside of there, you create some markdown files that specify what the agents are.
[01:12] So you can see I have two here. I have a debugger agent and a reviewer agent, and the format and syntax looks like this. Now, you don't need to manually write all of this yourself. You can tell Claude to create the agent spec for you, but when you have this,
[01:25] it will specify a list of agents that Claude can then invoke. So you'll notice we have a reviewer and a debugger, and for these we have a name, description, the tools that they're allowed to use, as well as optionally the model that we want them to run.
[01:37] This can be helpful, especially if you're running a lot of sub-agents, to reduce the cost. So once we have those set up, what we can do is run Claude inside of our project, so inside of the sub-agents folder here, and if we want to make sure that these sub-agents are appearing,
[01:50] we can run slash context. When we do that, it should show us here that we have two custom subagents. You can see they're specified right here. And then if we ask Cloud to do something that would involve invoking the subagent, you should see it spin that up automatically.
[02:03] So for example, I may say something like, please review this PR before I merge it, tell me if there's any issues. Okay, let's go ahead and press on enter, and we should see that it pulls up our reviewing subagent here and does that automatically.
[02:15] Boom, so you can see I'll have the reviewer agent examined, and then you can see that it is calling the reviewer subagent, and running that in its own thread. Okay, so we can see the review agent is done, and we get back the overall response,
[02:27] and effectively what Claude does here is it will invoke the sub-agent, and then it will only take the response from that sub-agent and bring that into context for the main thread that we're currently chatting inside. The reason this is important is it means that our main thread
[02:40] stays a little bit leaner, so we can have separate context windows for each of the individual sub-agents that only need to know what it is that they're specifically working on, which typically will give us better accuracy than doing everything in one massive thread,
[02:54] where when we start getting near the context window limit, as you guys probably see, the agents start to get a lot dumber. So that's custom sub-agents. I would only create them when you want to delegate things out of the main thread, when you want specific rules to be set up in terms of tools, read-only,
[03:08] your models to be used, etc. But they are super useful, and you can create them in the way that I showed you. Moving on, we talk about skills. But I'm going to show you some advanced features that you haven't seen before related to them. If you're unfamiliar, a skill is just a markdown file that outlines a set of procedures or a set of steps that are kind of like a reusable workflow.
[03:26] Rather than constantly telling the model to do the same thing over and over again, you create a skill so it's kind of a reusable workflow and then you can trigger it. The model can automatically call the skill and it will discover it when it needs to use it, or you can manually invoke the skill yourself and force the model to go through the process.
[03:43] Now that's actually the first feature of skills that I want to talk about here. First, skills fit inside of .cloud slash skills, similar to how we have this agents folder for the subagent. You can make them manually by writing them yourself, you can ask the agent to create them for you,
[03:57] or you can import them from something like a GitHub repo or someone else's skill that's already been written. Now, when you create the skill, you'll see that you can have a name and a description, and this is the only thing the model will see before it decides to invoke the skill.
[04:10] Now, inside the skill, you then have all of the steps. Now, another interesting thing you can do is add this flag called Disable Model Invocation to Your Skill, which most people don't know about. Now, what this will do is actually tell the model whether or not it can call this skill itself or whether you have to invoke it manually.
[04:27] So when you set this to true, essentially that will prevent the agent from automatically loading this skill, so it won't sit inside of the context, and this will only be used when you invoke the skill yourself. I'm going to show you what I mean by that, but if I go into my terminal here and I invoke
[04:42] clob from this folder, first we can type slash skills and see all of the ones available. So you can see that we have this deploy skill and this rumbleback skill these are project skills so they just available in this specific folder and you see that one of them is locked because I have that disable model invocation Now if I want to actually run that skill I can invoke it manually by just typing slash rollback
[05:02] and then it should go through the process of actually invoking the skill. Now, I'm just going to cancel it for right now because I don't want to do that. Alternatively, if I want to run a different skill, so let's say maybe the deploying skill, I can actually add an argument to this when I run it, so slash deploy and then staging.
[05:16] so you don't just have to do the slash command, you can say afterwards what you want to be done, then again, Cloud should find the skill, discover it, figure out what needs to be done, and then go ahead and actually run the entire process. I'm not going to walk you through the full thing, I'm sure you guys understand what the skills are.
[05:30] I also could tell Cloud to do something that would involve invoking the skill, and then it would just figure it out and call the correct one. Point is, they have a few more features, and I wanted to show you that kind of locking feature, which is quite useful when you want to have to manually invoke it
[05:43] and not accidentally have the model do it on your behalf. So the next feature to talk about is called Hooks. Now, this is a much more advanced feature. It really deserves its own video, but I'll quickly cover it here so you can look into it more if it seems useful.
[05:55] Now, Cloud has a bunch of different events that will happen throughout its agentic loop. The events look something like this, and while they look a little bit confusing, you can at least get an idea of kind of the flow. For example, we have session start, user prompts submit, pre-tool use, right?
[06:09] You get the idea, and all of these things will occur throughout some kind of process while you're using Cloud Code. Now, what you can actually do is you can hook into these events, and you can trigger a bash command to run whenever these events occur.
[06:24] So, for example, if you scroll down, you can see all the events that the session starts, set up, user prompts, submit, whatever. So, you can do something like, hey, whenever it's set up, I want to automatically create a markdown file. I want to automatically test my application.
[06:36] Or, hey, after we use a tool or before we use a tool, I want to make sure that tool is permitted. You get the idea, okay? So there's a lot of interesting stuff you can hook into here to customize how Cloud works, and the way you do that is by writing a config file that looks something like this.
[06:51] So let me show you an actual example here on Windows. You can see that this is an example of a config file that you can create right inside of a hooks folder inside of Cloud. So what you'll do if you want to create hooks is you'll create a Cloud folder, you'll create a hooks folder,
[07:03] you'll create a settings.json, and then the hooks can include different files that you want to actually run or different scripts that you want to run when an event occurs. So, for example, what we have here is post-tool use and pre-tool use, and what will happen here is that we're going to mash against edit and write, and whenever there's a tool that has edit or write, we're going to run this Python, quad, hooks, format, hooks.py, Python shift.
[07:26] So, that's going to automatically format all of the code for us before any tool is ran, or sorry, after any tool is ran. Then we have pre-tool use, and what this is going to do is run the block dangerous. So what that's going to do is it's going to block any dangerous commands or whatever from being read before it allows those to run.
[07:43] So if we have an exit code too, that means it blocks a tool call so that it cannot work in Cloud. I'm not going to go through exactly how you set it up, but the point is we can have these hooks, and I'm going to show you now how they actually work. So let me get out of Cloud. Let's change into the other directory, which is 03hooks, and let's run Cloud and give it some prompts.
[08:00] You can see how they trigger. Okay, so we're just going to say something like add a function called getAverageAge to messy.js that returns the average age of all of the users. Okay, and let's see what we get here.
[08:13] So you can see we're reading a file, messy.js, searching for a pattern. Okay, so we're going to go yes, we do want to allow this. So let's proceed. Okay, keep going, read file. And we should see that the hook will actually trigger now because it's gone with that process.
[08:28] Perfect. So you can see the post-tool use hook then ran prettier on the file automatically, so the whole file got reformatted after my edit. So you can see this ran, right? Both our hooks went through, and essentially it just worked, right?
[08:41] So we didn't need to do anything. It just automatically formatted the file. And if we go back here, maybe we can have a look at, let's see here, message.js, and you can see that it's formatted. So the next feature I want to show you is related to NCPs or Model Context Protocol.
[08:54] Now, these are servers that you can add inside of Cloud that allow you to connect to external tools. Of course, there's tons of different MCPs that are worth adding, and I'll make an entire video on that, but one that I want to highlight here that I've been using a lot recently is Grinor.
[09:07] Now, they've kindly sponsored this video and been a long-term partner of the channel, but this is an AI note-taking app that I use pretty much every single day that automatically transcribes your meetings without joining your call.
[09:19] So rather than having that little annoying note-taker that joins in, it just sits on your computer, It reads your computer audio, and it keeps track of all of your notes, keeps track of your calendar, and sends you reminders, and then saves everything in a nicely formatted way so you can view it,
[09:33] and also pull it into NI to have additional context. So earlier this year, they actually released an official MCP server. You can see I'm connected to it right here. It allows us to query all of the different meetings, and I want to show you just in live time how it works Using the Granola MCP server tell me what I learned in my most recent Indonesian lesson And that because using Granola I actually automatically transcribe all my lessons with my teacher so it should tell me some words that I actually learned here Let see
[09:58] Cool, so you can see it pulled the most recent transcript and gave me all the information. Now, let's just open up the UI so you can see what it looks like. Notice that we have the Indonesian language lesson, a bunch of other stuff that I was going through, and you get the point. Granola is great. Download it from the link in the description, and now let's move to the next
[10:12] feature. So the next feature to discuss here is work trees. Now this is super useful whenever you're going to run cloud in parallel and you want to make sure that agents aren't changing things that other agents are working on. It's effectively essential if you want to have multiple
[10:26] agents that are working on the same pieces of projects. Now work tree is really an isolated copy of your project that's on your own computer. It's similar to something like a git branch but it differs just slightly and works better with agents. Now you don't really need to understand
[10:41] the mechanics of the work tree, but what you need to know is how to invoke one and create one. Now, Cloud will sometimes do this automatically for you, but you can do it manually, and it's best practice to create it on your own. So, for example, I'm inside of a folder, you know,
[10:53] work trees, right, where I have a quick demo setup. What I can do is run Cloud, but rather than just running Cloud, I can add this work tree flag. Now, for the work tree flag, after this, I can do something like fix delete bug. Now, what I'm doing is giving this work tree a name,
[11:08] and when I go ahead and press on enter here, Claude is now going to be running inside of my folder, but inside of this work tree. So it's on its own isolated version, which is essentially a copy of whatever was inside of my project.
[11:21] And from here, I can give this a prompt. So let me just copy this in, read bug.md, reproduce the bug, right, find the root cause, and fix it. And at the same time, I can create a new work tree in another terminal, so Claude work tree, and let's go maybe feature dark mode or something,
[11:36] because we want to add a dark mode feature. Again, I'm just going to copy in another prompt. From here, let's put it in this, I don't know, auto mode, and same thing here. Okay, so let's go yes, and just put it in auto mode. And you'll see that both of these are now going to work in their own repo,
[11:50] or own copy of the repo, so they're not actually going to mess something up. All right, so we can see that both of the agents are finished. So now let's just open up another cloud code session here. This one I didn't put in the work tree, and I'm going to say, can you find all of the changes that have been made across the different work trees
[12:04] for this repo or for this project, and tell me which ones are there, and just ensure that they are actually in isolation, and then I want to combine them together. Okay, so let's press Enter here. And by the way, if you guys are wondering what I'm using to dictate,
[12:17] I'm using a really cool tool called WhisperFlow. You can see I have almost 300,000 words at this point. I use it literally every single day. I do have a partnership with them. It's free to try out, so I'll leave a link to it in the description. But it's just the fastest way to work with AI,
[12:30] as you guys can see from my own usage. So anyways, I would highly recommend it. From here, let's go Yes. I'm just going to put this in auto mode so it can run, and let's see what it tells us. So you can see right away that it found both of the work trees and now it's inspecting them, and then what we'll be able to do is actually combine these changes together
[12:44] without losing anything or messing up either one of these branches, right, that we're running in isolation. Okay, we can see it was able to kind of reconcile all of this together, and now it told us what was in both work trees, and then it combined them or merged them,
[12:57] so that now everything is in this one repo. Anyways, that's work trees, definitely use them, especially when you have multiple agents. So the next feature I want to show you here is headless mode. And this allows you to run Clod without actually being in the interactive terminal, which is super useful when you want to use this as a part of something like a bash script or kind of a one-step process.
[13:16] So I'm just going to show you a few really quick examples, and of course, if it's going to be useful to you, you'll know. So you can see that I'm inside of the headless folder, and what I'm going to do is, actually, let's make sure we get the full thing. I'm going to run the cat command, so this is just going to log out whatever's in this buildlog.txt,
[13:31] and then it's going to pipe that into this, where we have clod-p, which essentially is prompt, and then we place a prompt right here. So what's going to happen when I run this is Clod is going to run, but it runs in headless mode where it's not opening up the interactive window for us,
[13:45] and it just gives us the response. So I was able to take the result of the build log, I was able to include that as part of the context in this Clod prompt, and then just tell it, hey, why did this fail? And then it gave me the response right here directly in my terminal,
[13:58] which means you can then use this as a part of other scripts. Now I'm going to show you even how we can use this with something like JSON. So, for example, now I said, hey, I want the output format to be in JSON, and I want to use JQ to actually parse out the result.
[14:11] And now we're going to have this in the format where I can use it more kind of reliably in a script. So here you can see it's build failed. Here's just the errors. You get the idea. Now let's have a look at maybe some of the metadata here. So same thing, I'm going to do this again, summarize this build failure in one sentence,
[14:26] output format JSON, and notice this is what the result looks like. So we get the result, we get the total cost, the number of turns, and then the duration in milliseconds, and of course the cost doesn't really make sense in this context because I have the subscription, but you get the idea Let do one more so maybe I want to run this but I only want to allow it to read something so I don want it to actually have access to a bunch of tools I can add a loud tools read The reason I showing this to you is that you don need to use clon from the interactive
[14:51] terminal, you can trigger it from scripts, you can run it on one off prompt using this command which I always thought was really useful. So to kind of prove what I mean here, notice that I wrote this triage script, and you can
[15:03] see that what we actually do here is we run this clon headless mode automatically and and then get the result and print it out. Now, I'm not going to run this script, but the point is I can do something like this where I'm actually triggering it inside of the script.
[15:16] All right, so the next feature that I want to show you here is checkpoints and rewinding. Now, in order to do this, I'm just going to do a prompt in a new example that I have here where I tell it to rewrite app.js from scratch as a single-tip calculator class.
[15:29] We have, like, you know, a quick kind of React example or whatever, and we'll just give this a second here to rewrite it, and I want to show you how I can roll back so we can actually go back to different checkpoints in case Claude makes a mistake. So this is effectively the app I had, super simple, right,
[15:42] where we can just calculate the tip based on the bill amount splitting between a certain number of people. You get the idea. Well, let's do one more prompt here where I'm just going to tell it to rename every function and its ID. I'm not to touch index.html, and hopefully I'm going to have this actually break the app
[15:56] so I can show you how we can roll back to a working version. So now we are going to see that actually the app is completely broken, and if I try to do anything, it just doesn't work because I intentionally broke it. So let's say you were to do that, but obviously unintentionally,
[16:09] and you wanted to go back to a previous point. Well, Cloud will actually checkpoint different builds for you, so what you can do here is you can use the command slash rewind. Now, when you do that, it's going to show you whatever was in the current conversation,
[16:22] and you can go back at any point. So we have current, we have rename every function, we have rewrite every app, whatever. So I'm going to go to rewrite, and I'm going to go restore code and conversation, And now it brings me back to this stage where if I go back to my application here and I refresh.
[16:37] Okay, let's put in 100. And you can see now the app is working. So basically, just understand that you have that slash rewind feature, so you can always roll back in case you make a mistake. This next feature is super useful when you want to go back into an old conversation that you had in a particular project.
[16:53] So let's say I go into, I don't know, three hooks, right? And I want to go back into the previous conversation that we had at that point. Well, in order to do that, I can actually just type claude-continue. Now, this is going to bring me back into whatever that conversation was,
[17:08] because this session is stored and saved on our machine. There's actually multiple ways to get into different sessions, which I'm going to show you in a second, but the point is that you can do this, right? So you don't need to always restart a new session. You can resume different sessions.
[17:21] And you can notice here that it has various IDs for each session, which you can manually invoke to get back into, regardless of what directory you're in. So now that you understand continue, let's talk about being a little bit more proactive with our sessions.
[17:34] So you saw that random ID we had for sessions previously. That's great, but you can actually name your sessions as well. So for example, when I run clot, I can do dash n and then call this something like auth refactor. Now I've just named the session auth refactor, so it's always going to be saved as that.
[17:50] And again, I can give this a long prompt, so let's paste something in like this. And notice in the bottom right of my screen that it shows us what session we're in. We'll just put this in auto mode so it can go. So I'm going to say look at source, you know, auth.js, make a change, whatever,
[18:03] and then we can get out of this session and come back into it at any point that we want. Okay, so let's get out of this, and I'm going to show you again, if I want to resume this one, I can do clod dash dash resume, and then auth refactor, and it's going to bring me right back in to where I was before.
[18:17] There's some other interesting stuff we can do in here. For example, we can use slash branch. And when we do that, it's going to create a branch of the current conversation, but not override this session. So when I do that, notice that I'm now in a branch, okay?
[18:29] And then I can ask it to do something that's maybe risky, that I'd want to potentially have to get back to the main conversation for. So let's say, actually, scrap incremental changes, rewrite the entire module of the class with static methods and see how that looks, okay?
[18:42] And you can see that we're now working inside of this branch of the main conversation. Okay, so this is finished. And now what I can do if I want to go back to the original branch, so not the one that I just branched off on, I can type slash resume, and I can go back into this before the branch, so we no longer have those changes that were applied.
[18:59] And then same thing, I can go slash resume here, and you can see we have the branch, and I can go back into that. The point of me showing this to you is that you can be really clever how you manage sessions inside of Cloud. There's actually a lot more that you can do that I haven't shown you in this video, because it's meant just to be kind of a quick run-through,
[19:15] but you can name them, you can branch them, you can resume them, you can go in and out of them, and you can be really clever and have a lot of parallel work going on that's also going to be safe. So anyways guys, with that said, that's going to wrap up this video. If you enjoyed, leave a like, subscribe, and I'll see you in the next one.