Transcription
Every single day, it feels like there's a new Cloud Code feature, a new tutorial, another thing that you're falling behind on. And this is extremely overwhelming if you're just getting started, especially if you don't come from a technical background. But today, I'm going to help you fix that problem and show you what concepts I would start with if I was starting brand new, completely fresh.
Today we are going to cover 35 concepts across four different sections. Starting with the things you have to know at the beginning and ending with super advanced power user type stuff that you don't need to know right now, but you should know that they at least exist. And by the end, you're going to have a clear road map that you can get started with right away and start making some real progress.
And the first concept we're going to cover is what is the actual difference between the claude.ai AI web app, you know, this chat GBT type interface and cloud code itself. Well, it's relatively simple. These two systems use the same brain. So, I have Opus 4.6 running inside of Cloud Code. And right here in the chat menu, I have Opus 4.6. The difference is when I'm using Cloud Code, this brain has a body. It has hands. It can actually do things on my behalf. Whether that's write code, whether that's access my emails, whether that's to interact with my computer itself. That's the biggest difference. Cloud code can actually do things for me by and large.
Now, concept number two is about installing Cloud Code. And luckily for us, this is relatively simple. If you just Google Cloud Code install, it will bring you to the Cloud Code documentation. And all we have to do is copy and paste a single line of code into the terminal or if you're on Windows, something like PowerShell. Now, the one you're going to choose is depending on your operating system. So, if you're using Mac OS, Linux or WSL, you will just copy this. And if you're using Windows PowerShell, you will copy this. To find your terminal or to find PowerShell, you're just going to go to the search menu. Same thing in Mac. I'm on Windows. Type in PowerShell. It will give you a scary interface like this. You're just going to paste it, run this command, and then it will run you through the setup wizard. It's very simple. It's going to ask you to log in, and you will use your actual subscription plan. And after you run through the setup to actually launch claude code, you can just type in claude and you will see something like this.
But now we move on to concept three, which is where do we actually use claude code? Because there's actually a lot of options because while I can use cla code in the terminal like this, I can also use the claw desktop app as well. This is also cloud code. And then we have co-work here as well. What about co-work? And what about chat? Or what about something like VS Code, an IDE, an integrated development environment, where I do have the terminal up right here, same as this PowerShell situation, but I have the ability to look at my files and I have another window here, right? It's all very, very confusing. Again, especially if you aren't used to any of this. Well, the truth is it doesn't really matter all that much. At the end of the day, the most powerful version is the version that lets you work in the terminal. Whether that's using something like VS Code, which I will show you how to do today, or you're just using the terminal raw like in PowerShell or something like that. But when you get started, if that's all too much for you and you're like, "Hey, I just want the easy to understand interface inside the Cloud Code desktop app or even co-work for most users, 99% of the things they are going to do can be done in any of these spaces. You're not going to be losing out. That being said, I do implore you to try out the terminal at least for the beginning. Give it a week or two. And if at the end of that, you know, time period you're still like, ah, this is too much. It's just not for me. Go ahead and move to these other ones, whether that's claude code or even co-work because you can always go from the terminal to these. It's a little harder if you get used to something that kind of has, you know, the bumper rails on it and then you try to move to something more powerful. And as easy as it is for me to say, the terminal isn't as scary as it looks because at the end of the day, it's just a prompt window. We're just going to be prompting Claude code inside of the terminal in the same way that you would chat GPT on the web app. And like I said, we will use VS Code for today because I think it's an easy stepping stone into the terminal environment. This is what is called an IDE, an integrated development environment. It's still the terminal, but it's just a more friendly way to view it because you can see over here I have this explorer tab. So when we start working inside of a file, everything I create inside of the file I can see here and I can actually open up over here and that'll be more obvious later in the video.
Now using VS Code Visual Studio Code is totally free if you search up VS Code in Google and click the first link. You will be brought here, the open source AI code editor. You're just going to download it, run through the install wizard, and that's kind of all you have to do. From there, just search for VS Code. Click on it and you'll be brought to a page like this. You're going to go up to file, go to open folder, and then we're going to create a new folder today. This folder is where we're going to work in just like you would work with any other project on your computer. So, I'm going to go to new folder. I'm going to call mine 35-ash test. Click on it, hit select folder, and you'll see a page like this. Next, I want you to go up to the top where there's the three buttons, hit terminal, go to new terminal, and now our terminal is open right here at the bottom, just like it was when we did PowerShell. And now to open claude, I can just type claude. And there we go. Claude code is up and running.
So let's talk about concept number four, which is permissions. So right now you will notice it should be blank at the bottom. But if I hit shift tab, you will see some options pop up. What do all these things mean? Well, these are the different permissions. These are like almost think of it as security settings for what Claude can and cannot do to your computer to the files on your computer without your permission. Now, when it is blank, we are on the default permission setting. That means it's going to ask your permission explicitly to edit files. If I'm on accept edits on, it will automatically edit files without asking for permission. So, it's a little bit quicker. But, if it's going to use any bash commands, that means terminal commands, that means changes to your computer. think downloading a certain dependency or program and installing it. It's going to ask for your permission to do so. Then we have plan mode which we'll talk about in a second. Now there's actually a third permission but to do that you need to open claude in a specific way. Okay. So, if we do slashexit, that gets us out of claude code. And now, if I do claude and I do dash dash dangerously skip permissions, it's going to open up claude normally, but you will see a new setting here called bypass permissions on. That means it can edit files, delete files, download things, all without my permission. Kind of scary at first, but over time, understand this is where most people end up sitting on because it's just quicker. I will say I've never had an issue with claude code deleting any files that I didn't tell it to. Although, you know, there's always those theoretical stories. In the aggregate though, this will save you so much time once you get comfortable. But if you're not comfortable with that yet, you don't want to go crazy, just keep it on accept edits on.
Now, if you shift tab a couple times, that will bring us to plan mode, which is the last concept we will cover in this core essentials section. So plain mode means that when I tell Claude code to do something like let's build a website, it's not just going to go out and do it on its own. It's actually going to think about it. It's going to come up with a series of steps we need to execute first. And what you will probably see here is it's going to come back with some questions for us. It's essentially prompting us to get a better idea of what we want to build. So plan mode is the number one way for you to get better outputs from claude code because it's going to make sure your prompt doesn't suck. The prompt you're going to come up with is going to have a number of holes and plan mode lets us kind of fill those in because Claude will ask us questions to do exactly that. So it's asking for a type of website. We'll say a landing page. It's asking for our stack if I don't know. We'll just go with number one. And for our purpose, we'll say this is for a personal project. and then we'll submit it.
So, just wanted to take a moment to talk about my claude code masterclass because it is the number one way to go from zero to AI dev, especially if you don't come from a technical background. Everything in this course is for the beginner and we focus on real use cases to help you learn how to master this amazing AI tool. I put out new updates every single week and if you want to get it, just head to Chase AI Plus. There is a link in the pinned comment.
So now is the perfect time to talk about concept number six, which is your mindset when using claude code in the planning phase is a great time to discuss this. Now, right now it's asking me a few more questions about our website and we're saying we want to make it about this fake online app called Argus. It's a social media intelligence app and it's going to create this landing page for us. But when it comes to mindset, you need to start thinking of cloud code as a collaborator. And it's very easy to do so in the planning stage because you have this back and forth. But where people get tripped up is in this back and forth, they're going to just do whatever Claude code says and they're not going to ask it questions. And one example of us doing it the wrong way was when it asked us what text stack did we want to use. We just said, "Hey, we're going to use Next.js and Tailwind." Do you know what Next.js and Tailwind is? Probably not if you've never done something like this before. Now, often times cloud code will give you a recommendation and it's your best bet to go with it. But if you really want to learn cla code and understand the fundamentals of building with AI, that is when you need to stop and tell cloud code to explain these concepts to you. And that is how you're actually going to learn and not just be a caricature of a vibe coder. Because you have to ask yourself, if it's this easy to build things, what's the difference between you and the guy down the street who I can replace you with? Because he can ask those same questions too and just hit accept accept accept build me a landing page. What's going to separate you from the pact and actually build your skills at a foundational level is asking Claude code these questions to explain things to you. It is the infinitely patient tutor and we need to treat it as such.
So here's the plan Claude Code came back with for our landing page and this is what you can expect when you use plan mode. It's going to give you a pretty detailed outline of what it's planning to do before it actually executes. And you'll see some options here. You'll see yes and bypass permissions, which means it's going to run what it planned and it's not going to ask for permission. Yes, manually approve edits. So, it will begin creating things, but it's going to ask for your permission every time it wants to like create or edit a file, which is very annoying. And then we have this one, no, refine with ultra plan. Now, ultra plan will be in section four when we go into some of the power user stuff, some of these like highlevel features inside of Cloud Code. But for now, we're just going to say yes, bypass permissions. And just like that, it's going to start building our website for us. And what you see over here on the left are all the files it's building. So this is what's nice about VS Code, especially when you first get started. All the stuff that's being built is right here. So it's the same as if I actually went into my file explorer, opened up 35- test, and looked what was inside. I'd see these same things.
Now, one of the files Claude Code created was the claw.md file you see over here on the left. And this is what we're going to talk about for concept number seven. So what is the claw.md file? Well, this is going to be inside of every single cloud code created project. And think of it as the instruction manual, so to speak, for cloud code regarding that particular project. This is something that's telling cloud code certain conventions and certain rules you want it to always follow all the time when working inside this particular folder. Now, cloud code will automatically create this when it's building your project. So, you don't have to touch this too much. And do understand there are a lot of techniques regarding cloud.md. Some people like me will say less is more. Other people say put as much information here as possible that you think is relevant and are kind of like outside the box rules. All you need to understand at the beginning is that this exists and whatever you put in here, Cloud Code is going to reference every single time you tell it to do anything. So, it's a very powerful tool, but you want to make sure what you do put in here, if you do edit it, actually is important. And it applies to virtually every single prompt.
So, cloud code created our web page. page. It said a dev server is started here on local host. Local host is like an internal web page. If you click on this, it will take you to the web page. And I'm inside of Chrome right now, but it's not connected to the internet. This is all local. So, this is what it built for us. Extremely ugly. And throughout this video, I'll give you different tips and techniques to actually making this better. But just understand this is where it's living right now. And we can actually interact with it just like we would a normal web page. But before we get into that, let's talk about one of the most important concepts of cloud code. and really large language models in general. And that is concept number eight, the context window.
So the context window can be seen if we do forward slashcontext. And what we see right here is how much of the context window we have used. In this case, we've used 48,000 tokens out of 1 million tokens. And you're probably like, Chase, what the heck does that mean? I don't even understand what tokens are, let alone what that really means. 50,000 of a million. Okay, what are you talking about? So tokens are the currency of large language models and claude code. Every single word is a token. So every single word here that we've given cloud code inside a prompt and every word it's spit back out at us equals one token. One word, one token. A little bit different in reality, but just let that be your mental model. All the tool calls it uses cost tokens. All the code generated cost tokens. Everything it does costs tokens. And the context window is our budget for clawed code. That is 1 million tokens. It differs for each and every AI system. Now, why do we need to care about this? Well, first of all, if we fill it up, our session kind of ends. And you've probably run into this with chatbots throughout the years where all of a sudden it says, "Hey, I don't have enough room. The session is ending." That occurs when you fill up the entire context window. But what's important isn't just filling up the context window. It's the idea of concept number nine, which is context rot. And that's the idea. As I fill up the context window with more conversations, more tasks for cloud code, the actual effectiveness of cloud code goes down. So the more I use it, the worse it gets, which means we want to keep an eye of where we're at on our context window. Especially since we can reset it at any time. I can pretty much start back at zero whenever I want. Now, this comes at a cost, right? When I'm using a normal chatbot, say I'm inside claw.ai and I start a new chat, that's kind of painful because everything we've been talking about, I want it to remember. I want it to remember my conversation. I don't want to start all over again. That sucks. But if I start all over again, cla code works better. So, what am I supposed to do? Well, luckily, starting over inside of Cloud Code isn't like starting over inside of a chatbot. It's actually much better because claude code even if I start all over and I can start over by simply doing slashcle. My session is now reset. Cloud code is living inside this folder. It's on my computer. It's on a chatbot in the cloud. Whenever I talk to it again and ask it questions about my website. It doesn't matter that we started a new chat for all intents and purposes because it can just look inside the codebase. It can look at all these files. It has claw.md. It has the ability almost like a human being to go inside the folder and see what is what. And therefore, because of that, I always want to be resetting my context window if I can because why do I want to be working with a worse clawed code at 500,000 tokens for the sake of keeping a conversation going that I can just have it remember anyways, right? So, there's few downside to constantly resetting. On top of that, as you fill up the context window, your prompts are essentially more expensive. You are using more of your usage because every single prompt is essentially sending everything that came before it. Now, there's a caching system, which kind of alleviates some of that problems, but the point remains, if I'm down here at token number 800,000, that's really costing me more per prompt than if I'm at token number 50K or 100K. And you see a lot of people complain about cloud code usage and this isn't the only reason they complain about it but in large part it's because a lot of people don't know how to manage their context window properly. So they're using more usage and claude code isn't working very well. So you can see the importance of a always having your eye on the context and b always resetting it whenever it makes sense. As a rule of thumb, you don't really want to go past 200,000 tokens if you can help it. There are going to be instances where you know, hey, I I just need to have a longer window for whatever reason, but if you're hitting 20%. You need to ask yourself, do I need to stay in the session? If you don't have a very good reason, you need to reset it. And by reset, all you have to do is what you saw here, which is forward/clear. And if there is something in the conversation you want to bring forward, just ask Claude code to have a quick write up about what you were talking about, and you can copy paste it in the next session.
Now, what you can see here for me, and this is going to be concept number nine, is my status line. So, right here, you can see it says 35- test. You can see the actual model I'm using, and I can see my context window at all times, which says 2% here. And yours probably doesn't say that right now, but you can create that yourself. So, you don't have to constantly do forward/context. You can just look right down here and see where you're at, which keeps you kind of on top of it. So to do that, you're just going to do forward slashstatus line and you're going to write a prompt that says something like, hey, I want you to create a status line for me that's totally persistent that includes, you know, the folder I'm in, the model I'm using, and my current context window usage. Once you do that, it will create that for you and you're just going to have to reset cloud code and you'll have a status line of your own.
So we just hit a ton of concepts right there. context, context window, the ability to clear context rot, and this status line. Take those all together, and frankly, you will be well ahead of people who've been using claude code for a while because people do not adhere to this principle nearly as dogmatically as they should.
Now, let's talk about some other slash commands while we're here. And this is our next concept, and that is rewind. So, let's say you did do slash clear. You've been really on top of making sure that context window is as clean as possible, but you realized, oops, I really shouldn't have done that. I had something else I wanted to do. Well, if I do forward slashre, I can actually go back to previous sessions inside of cloud code. So, I could go back to before I did forward slashclear and essentially bring that conversation back to where I was or the conversation where I said hi. This will also include code changes. So, if we were talking in cloud code and we made some changes to our actual website, let's say I didn't like them, I can do forward/re. It's an easy way to essentially go back to where you were because it has these almost autosave points.
Concept number 14 is another one you're going to want to know and that is forward slashmodel. So forward/model lets me switch between all the different cloud code models. So we have opus 4.6, sonnet 4.6, sonnet with a 1 million context as well as haiku. So what you're going to want to do here kind of just depends on what plan you're on. If you're on the pro plan, 20 bucks a month, you're probably going to want to stick with sonnet all the time. If you're on max 5x, you can get away with Opus a lot. Depends how much you're actually using it. If you're on 20x, you can go crazy with Opus all the time. The model is just going to depend on your usage. That's just kind of what it comes down to. How much money are you paying Anthropic? When it comes to Haiku, you probably don't need to be using this at all. It is an extremely cheap, damn near free model, and its use cases are very specific and niche. So, unless you know what you're doing, you don't need to play around with Haiku. And you'll also notice some other model related commands like effort. This is how much thinking cloud code was doing. It's going to default to auto. And again, this is kind of usage based because the higher the thinking level, the more tokens, the more usage. So, just depends on your task.
Now, the last core concept I want to talk to you about is Git. So, we talked about rewind, right? The ability to have these sort of built-in save points with cloud code. Well, there is another sort of save point and that is git. So git essentially is another type of save point, but it's going to be on your computer and it's pretty much saving your exact spot in terms of the code you've built. So I highly suggest you use this whenever possible. Cloud code is very spun up and intelligent when it comes to git. So you can just say something like let's get commit this. And if I say get commit, it's saving it. This will come in handy later because when we start using things like GitHub, well, we want to take the whatever safe point we have with our code and push it to the cloud on GitHub. And to do that, you need to have committed the code. So, think of git commit as a safe point. Rewind is great, right? Rewind is great in the in the context of cloud code, but as we become more mature and as we like to think about, hey, how am I eventually going to get this code out into the world? We need to start using Git. And that is a great stepping stone and it's almost a secondary safe point next to rewind. So you can see feel feel a little bit more confident that your code is not just going to vanish or disappear.
So now we're in section three which is the toolkit. This is where we're going to start bringing in some outside tools, things like CLI and MCPS as well as introduce skills which are one of the most powerful features of cloud code. And it couldn't happen at a better time because our website is ugly. I mean just look at this thing. This is the definition of AI slop. Boring, flat, purple gradients. How can we fix this? I mean, obviously, we could have given it a better prompt, but there are some tools that can help us specifically with something like front-end design.
So, the next three concepts are going to be skills, the skill marketplace, and the skill creator skill. So, skills are just text prompts. They're just a way to tell Cloud Code to do a specific thing in a specific manner. What we're looking at right here is the official anthropic front-end design skill. And like you see, it's just text. No fancy code, nothing crazy going on, just a text prompt. So the front end design skill is the exact same thing as me taking this whole thing, copying it, pasting it into cloud code, and saying, "Hey, create a better front-end design than what you just did, and use these sort of guidelines." But I don't want to copy and paste it every single time. So instead, I would just use something like the front-end design skill by either doing forward slashfrontend design or just saying in plain natural language, use the front-end design skill and then I give it my prompt. So, let me show you how to do that.
Now, the first thing you need to do is install the front-end design skill. Now, there's a number of ways you can do this. The first way is just to do /plugin. /plugin will bring up the plug-in design marketplace and I can go to discover plugins which you see right here and I can just search for front-end design skill. Once you see that, you just select it and then you install it. And you can confirm you installed it by just tabbing over to the installed section. And you can see right here front-end design plugin. Now once you install the plugin, it will give you some sort of message saying to do something like reload plugins. You just run that and it will get the plugin installed. But at that point, the skill is installed in cloud code. Cloud code knows the skill exists. You just have to invoke it. Like I said, a couple different ways to do that. You can always invoke it by using forward slash whatever that skill is called. In this case, front end design. I can say something like use the front end design skill and it will use it. Or it's smart enough if I say something like, hey, we're working on the front end for this web page. Let's do X, Y, and Z. It's smart enough to pick up on that sentence and say, "Oh, we're working on front end design. Oh, I have a skill for that. Let me go invoke it." Lastly, Claude Code is smart enough to install these skills. If you were to just copy this URL from GitHub, I this is on the Cloud Code official GitHub. So, I could copy this URL, paste it into Cloud Code, and say, "Hey, I want to install this skill. Can you do it for me?" And it will edit its settings on its own to add that. The last thing I'll talk about skills before we see this in action and then go into the skill creator skill is that skills can be both at the user level and the project level. Right now we are in the 35 test project. But what if I created another project and it was for you know my emails. It was my email project. Will that project have access to the cloud code skill? It depends. Normally yes. When I install something like the front-end design skill, it's going to install it at the user level. You are the user which means any project you the user creates has access to these skills. We have the ability to have project level skills. So I could create or use a specific skill just for this project just for our website, right? Maybe you don't want it to ever be used anywhere else. So just understand you have that flexibility.
So let's actually put this to work. So I did for/front design. I said recreate the front end aesthetic. Use anthropics color palette, terracotta, etc. And give the card some visual weight, drop shadows, etc. Stay away from standard AI slop design. So, let's see what it does this time with the skill. So, here's what we got. And this is a huge leap forward from the first iteration. Now, is this perfect? Absolutely not. Does it still look AI generated? Yes. But look at the gap between the first iteration and the second iteration. And that's really thanks to one of the most simple tools out there, one of the most simple skills, which is the front-end design skill.
Now let's talk about the most powerful skill available to you inside of cloud code and that is the skill creator skill which is our next concept. The skill creator skill is not only good because it is trained to create highquality skills but it allows us to modify and improve existing skills and measure skill performance over time. As you use cloud code more and more you are going to find yourself doing the same things over and over. We all have a particular workflow. Anytime you identify some sort of workflow, some sort of repeated task, you want to turn it into a skill. And when we turn something into a skill and create a custom skill, we always want to use the skill creator tool because it's actually going to tell us if it's even worth creating a skill in the first place. Its ability to measure skill performance is huge. It will automatically run AB tests to see is the skill even better than doing nothing at all. And it allows us to test skill improvement. So if you edit a skill, it will test it against the original iteration. And when I say test it, it runs multiple tests and gives us back actual quantifiable data. This is massive. In order to use the skill creator skill, just like the front-end design skill, you can either copy this URL and bring into Cloud Code, or you can head to the plug-in marketplace, find the skill creator skill here, install it, reload your plugins, and you're all ready to go.
Now let's talk about some external tools we can bring into cloud code with concept number 20 and 21 and that is MCPs and CLI tools. So MCPs are a way for us to connect cloud code to some sort of external program. Cloud code has an entire section of its documentation dedicated to MCP tools and lists the type of tool you can connect to as well as the command you need to copy and paste into cloud code to install it. So we have things like Linear, Hugging Face, Cloudflare, Figma, Guru, Monday, Notion, the list goes on and on and on. And with an MCP server in between us and these programs like Notion, I can then just talk the cloud code in natural language and say, "Hey, do X, Y, and Z inside of Notion." And it will do it for us on our behalf, just like as if we were inside of Notion executing those tasks manually. So to use these MCP tools requires a couple things. One, you need the specific command. Like I said, the most popular ones can be found here inside of the Cloud Code documentation, which you can find by either searching CloudCode docs mcp or just asking cloud code to do it. And then you're just going to copy this command. And then you're going to paste it inside the terminal. Now the easier way to actually do this is to just say something like set up the MCP server or notion for me. Cloud code will do all this on your behalf. It will search the web to figure out what sort of commands it needs to run and then it will come back to you with a list of things you need to do. Because for me to you know set up a notion MCP or a PayPal or a stripe or superbase I need to have credentials. So that means I need to go onto a website like Superbase and there's specific secret keys that I need to bring to Claude Code or put into the settings folder. Now that sounds kind of complicated if you've never done that before, but guess who's an expert in these things? That's right, Claude Code. Claude Code will literally walk you through it step by step to to like where it says click on this link, go to this page, copy and paste this. So Claude Code will do all the heavy lifting for you when it comes to MCPS. That being said, MCPs are kind of falling by the wayside. Even though MCPs were hiked to the moon over the last year and a half or so, they are starting to be replaced by CLIs. A CLI tool is a command line interface tool. Just like clawed code lives in the terminal, these programs also live in the terminal. And because both cloud code and these programs live in the terminal, they are perfect for one another versus MCPs. MCPS have a lot of overhead, which means when you compare an MCP versus a CLI, the MCP tends to be slower and less token efficient. So for 90% of use cases, if there is a CLI available, you want to use that over the MCP. A great example of this is the Playright MCP. So Playright is a tool that if we connect cloud code to it, it will do browser automations for us. So it's like cloud code controlling the browser on our behalf, logging into websites, testing things. It's great. It has a CLI and an MCP. The CLI is way better. It's like 90% more token efficient. It's easier for cloud code to use and it's, you know, a perfect case study for the CLI versus MCP dynamic. Now, how do we use CLI? Well, you know exactly what I'm going to tell you. There's specific commands to use CLIs or what do we do? We go to cloud code and we say set up this CLI for me. Now, things like CLIs and MCPs, if you aren't on bypass permissions, right, you didn't start clawed code with, you know, dangerously skip permissions, it's going to ask you to do things. It will probably tell you to open up a new terminal window and pasting these commands. If you're on bypass permissions on, it will do all this for you. Now, part of that's kind of scary, right? Cloud code going in, downloading something on my computer, installing it, and running it. Frightening. However, if you're using a rather popular CLI, one that's definitely been vetted by the community, you shouldn't be too afraid of this. Something like Playright CLI is a great example. The question then becomes, what CLIs should I be using? And the truth is, I can't tell you what CLIs to use. It's entirely use case dependent. Do you need browser automations? Maybe. Do you need something like Superbase for authentication to set up login for your website? Maybe, maybe not. The trap here and a trap a lot of people get stuck in is they after hearing about CLIs and MCPS, they go down the rabbit hole and they search up every single CLI they could possibly use, every MCP that might be relevant to them, install all of them and use them like crazy. Less is more when it comes to cloud code, at least in my opinion. So over time, you will become more exposed to some of these CLIs and MCPS and it will become rather obvious when it makes sense for you. If you are just getting started, I think it's enough to know that CLIs and MCPs exist and more importantly that we can have Claude code install and use them for us and even in many cases create skills that help cloud code use them. So if you just know that's out there, that's enough if you're in the beginning of your journey. If you are a bit more experienced, well then it's just a matter of using cloud code more and also asking claude code if does an MCP exist for this use case? Does a CLI exist for a use case? Oh, by the way, oh cloud code, go use your web search and confirm that's the case because these things are changing all the time. Every single day there's a new CLI coming out. Every single day there's a new MCP going out. So I'm not going to sit here and give you, you know, here's the 30 you need to know. Although I do have some content that hits on some of these things. Just understand it's out there and that Claude Code can find it, install it, and use it for you.
These are the kind of like superpowers Cloud Code has because what I want to talk about for concept 22 is the idea of fosshot prompting. What is fot prompting? Fewshot prompting is the idea that when I prompt claude code like with front-end design, I don't just give it a prompt. I don't just give it a skill. I am in fact going to give it multiple examples of what I want it to do in order to better get the output I desire. And when we talk about something like front end design, we can do better than just screenshots. We can give it actual code, actual HTML that's living under the hood that Cloud Code can use to better get us something we're shooting for. So what do I mean by that? Well, you know, we originally told our web page that we were kind of going for an anthropic color palette/design. Well, for one, I can take screenshots of what I'm going for. Let's add some of these cards. Let's get the footer. But we can look at the actual code. So, if I do control, what we have here is the HTML. So, if I then copy all of this and bring that into cloud code, that is in essence a form of viewshot prompting where I have screenshots plus the code to better guide Claude code to get what I want. And this is perfect for front end design. So I said, can we get the front end to better match the anthropic aesthetic? Here is the HTML from their site plus screenshots. I pasted all that HTML was 2,000 lines. And then I drag and dropped in the screenshots. So let's see how that works. And here's what it came back with. And it definitely has much more of a anthropic vibe in terms of the colors. Now, is it an exact one for one copy? Is there still a bunch of work to be done? Yes, just like before with the front-end design tool. But the point is by using stuff like fuse shot prompting you have more control of the outputs. Anything we can do to get away from just prompt and pray and feel like we have some sort of agency in terms of the output that's huge and fshot prompting is one of the best ways to do that.
But part of the problem of having cla code code things when we ourselves aren't a coder is that we don't actually know if what cla code is creating is correct or right. I mean, I can look at the output and judge it based on its final merits, but is what it created under the hood correct at all? It could be complete gibberish, and for most of us, we'd have no idea. Which brings us to our next concept, which is adversarial prompting, an adversarial code review. Now, adversarial code review just means look at the code and tell me what's wrong. Now, when you do this, there's a few things we want to keep in mind. First is the idea that AI in general and opus and sonnet is part of this under this umbrella is they look kindly on the their own code. Whatever they create, they think it's good. So if I tell, hey, look at the code and tell me what's wrong, it might come back with a few things, but by and large, it's going to think what it did is correct, and that shouldn't really be a surprise. So if I want to make sure that what I wrote was correct, there's kind of two options. So the first is I can create another terminal and I can start up cla code again. So I have cloud code in two terminals and I have a different session of claude code take a look at the code we created inside of this codebase and I tell it to be adversarial. I tell it to like look at it with a discerning eye. I tell it, hey, imagine you're some nerd on Reddit who hates AI and tell me what's wrong with this codebase. Right? That's the first way to do it. The second way is to use a different AI entirely to do the code review. And a great way to do this is using the codeex plugin for cloud code. So openai aka makers of chat GBT makers of codeex have a plugin for cloud code. So if you pay for chat GPT uh subscription 20 bucks a month you can use this plugin. In fact, you can actually use it for free as well but I believe the model is downgraded but we can install this just in the same way we install a skill and have codeex review our code. And they have a specific command for adversarial review. So, if you're someone who's like, I just don't believe what opus is saying and I want a second set of eyes that aren't also opus. Well, Codex plugin is perfect. How do you install it? Very simple. Take this URL, paste it into cloud code, and say, "Hey, I want to install Codex plugin." And it will run you through it. And you just would do for/codex review or for/codex adversarial review. And I think this is really important, especially if you're doing something more complicated. you know, we're doing something here with a front end, like a landing page. There's only so much it can screw up. But the more complex the project, the bigger the project, the more you're going to get out of something like an adversarial review. And this is great, especially especially especially if you don't come from a technical background. You don't know what it built. So, at the very least, you want someone who does know what's going on, aka another model, tell you if it was good or not.
So now we're in section four, the power user section. Everything we've talked about up until this point is something you should be striving to master within your first few weeks. If you can get comfortable with everything up until now, you will be well ahead of your average Cloud Code user. Everything we are now about to discuss though, this is more for the power user, for someone who's more experienced. You don't need to start implementing these things right away, but you do need to know they exist because as you become more experienced, you will eventually hit some walls. And some of the stuff you're going to be exposed to here can help you. So just know they're out there. Know there's possibilities beyond everything that we've termed fundamental or core to cloud code. And the first two concepts we're going to hit are all about custom commands, custom slash commands. So when I do forward slash, as you've realized at this point, is there are a bunch of commands that will prompt cloud code to do something. Things like clear, right? We talked about that with context raw and starting a new session. But we can create our own. Oftent times they are in the form of a skill. So you use the custom skill creator to create skills which you invoke with a forward slash command. One of the favorite ones I use is yt-pipeline. This is my YouTube custom skill research workflow because skills in claude code don't just have to be simple things like a front-end design text prompt that says, "Hey, when we create a front-end design, make sure you do x,
y, and z." custom skills, custom slash commands. They can be workflows. They can be something that tells Cloud Code, I want you to do A, then I want you to do B, then I want you to do C, I want you to do D. It becomes like its own automation. That's what my custom one does. And it uses subskills. So, it's a higher order skill that calls additional skills below it. And it uses things like CLIs. So, your custom slash commands, your custom skills, your custom workflows can be pretty complicated, but they can save you a ton of time. Like I said, this uses the notebook LM API. It goes onto YouTube. It's able to use the Notebook LM actual application through Claude Code to help me do research. And so, whatever you do that has multiple steps that you do multiple times a day, you should be turning into a custom slash command.
Custom commands can also be something like hooks. Hooks inside of Cloud Code tell Claude Code to do something before a specific command or after a specific command. And these can be huge productivity boosts. My favorite hook is one that plays a noise every time it finishes a command. You probably haven't been able to hear it in this video, but anytime Cloud Code finishes a command, I get an audible sound. Now, why would you want that? Well, over time, you'll realize, especially when you have multiple terminals up or it's running on a long task and you kind of just forget about it and you find yourself doom scrolling in between, it's great to have some sort of audible cue to say, "Hey, I'm done. Let's get back to work." I would totally do that if I was you. And it's very simple to create these things. You just say create a custom hook or create a hook that plays a noise. Plays a noise. I can't type when Claude Code finishes a task. That simple. And you could have that hook be anything. Doesn't have to be a noise. It could send you an email for all you wanted every time it completes a task. Right? Cloud code is infinitely customizable. And custom slash commands and custom hooks are a great way to leverage that.
Now the next concepts we're going to talk about are all about sub-agents and agent teams. So when you're working inside of Cloud Code, at any time it can autonomously on its own spawn sub-agents to do tasks on its behalf. Let's imagine I was researching something about Cloud Code skills and I wanted to know I wanted to go out to the web and find me information about Cloud Code skills. Well, it could spin up a sub-agent that's all it's doing is web search. So Cloud Code is essentially creating a second instance of Cloud Code just like you created a second terminal and it's telling that sub-version of Cloud Code, "Hey, go search the web for me." It could do that for any number of tasks it wants. And sometimes it will create multiple sub-agents to do multiple things all at the same time. You as the human being don't really interact with these sub-agents and they have a specific task. They complete the task and then they bring the information back to the main Cloud Code instance. Now you have the ability to create sub-agents on your own. But for the most part, Cloud Code does this all automatically when it needs to. You just need to understand how it works theoretically because you're kind of wasting your time to create sub-agents on your own.
But this system can have some downsides. Let's say I told Cloud Code to create a more complicated web page than the one we've been working on. And so it creates three sub-agents on its own. It creates a sub-agent for front-end design, what we've been doing. It creates another sub-agent for authentication, like a login page. And it creates another sub-agent for payments. Think like Stripe. The issue is these guys don't talk to one another. Front-end design doesn't talk to authentication. Authentication doesn't talk to payments, which can be an issue because we're all trying to be on the same sheet of music. Yet, with the standard sub-agent paradigm, they're all in a silo. They do their own thing and they come back to the main Cloud Code session and then this guy has to figure out if everything actually matches up.
Well, enter agent teams. Agent Teams is similar in that Cloud Code will spawn these sub-agents. However, they now talk to one another. So, front-end design can talk to authentication, authentication can talk with payments, payments can talk with front-end design. And often times, it will actually spawn an additional sub-agent whose entire job is to coordinate what these three guys are doing, right? Kind of acting like a middle manager for a team. It's trying to mimic a real human team setup, which means your primary Cloud Code doesn't have to coordinate everything on its own. Everything is done at the sub-agent level. This is great. This is a more sophisticated setup than your normal sub-agents. However, it's not for free because of that coordination to have all three of these guys talk to one another that costs more tokens. Furthermore, this is an experimental feature. What do I mean by experimental feature? I mean you need to explicitly enable this inside of your settings.json. How do you do that? Well, you can go to do.cloud.cloud and edit it yourself or and you know what I'm going to say, copy this page or copy the URL, go inside of Cloud Code and tell Cloud Code to enable agent teams on your behalf. Once you do that to actually use agent teams, you need to explicitly tell Cloud Code you want to use agent teams. In their example here, they said "create an agent team." So it's not going to do it automatically no matter how you say it. You have to say "create an agent team."
So let's see this in action. We're going to say, "Create an agent team to work on this web page. One agent for front-end design, one agent to create a form submission for people who want to join our newsletter, and one agent to research ideas for a blog machine." So again, you need to be explicit. You can see here the agent team it created. So it has a front-end designer, shows its task, newsletter dev task, blog, blog researcher task. And in this main Cloud Code session, you will get updates as these sub-agents complete their tasks.
And while they're working, let's talk about multiple sessions because we talked about this for a second. And this is something you probably see all over the place, which is people with like nine terminals up at once, all working on the same project. This is something you could do. I can have pretty much as many terminals open, as many terminals open as I want to work on Cloud Code. In a sense, I can manually create my own agent teams. I could have one terminal here that's working on front-end design, one terminal here that's working on the form, etc., etc. When it comes to these multiple sessions, there are some things you need to think about. Mainly kind of what we talked about with agent teams and sub-agents at the beginning, which is like, are we having Cloud Code all work on this the same piece of paper changing different things at the same time? If you had three humans at a desk all working on the same report and the report was on one notepad, you can see the issues you would run into. On top of that, I will say from personal experience, you can only have so many terminals working at the same time before you're just doing so much context switching that it feels like you're being productive. You're giving it a lot of prompts, but are you actually focused on any one particular task? Are you actually moving the needle? Are you actually moving forward in any meaningful way? I would argue after two terminals, maybe three, we're kind of just messing around at this point. Like if you see someone with nine terminals up, this is productivity theater. We're just pretending to do something. We're not really working at max capacity.
But if you are going to go the multiple terminal route and you're going to work on a ton of things at once, you're going to want to deal with that problem that we talked about. Three people at a desk working on one notepad, that's going to have issues. How can we deal with that? Well, one way we can deal with it is get worktrees. So, get worktrees attempt to solve that problem. Without worktrees, we have three people, three agents, three terminals working in the same project. They overwrite their work and we get a conflict. However, with worktrees, instead of having three people at the same desk, everybody has their own desk and their own copy of the files. They do their work and eventually all the work gets consolidated. And guess who makes sure it all adds up when we put it together? Cloud Code does. Now to use worktrees, you'll open Cloud Code like normal, but you're going to use the worktree flag. And then you're going to name that worktree. So something like "front-end-design." So it'd be `cloudctl --worktree` and then name the worktree. And then you would repeat that for all the additional terminals you open. And like you see here, this one is called "main." This one is called "front-end." This one's called "tests." You would work on those things in parallel. And then at the end, you would go back to your primary Cloud Code session and say, "Take a look at these worktrees. Let's merge these and make sure it's clean." A more advanced concept, especially for Git. So if you're just getting started, don't get confused and start using this right away.
Now let's talk about another power user concept and that is frameworks. Things like GSD, get done, things like BMAD to some extent, things like Superpowers. It's this idea that there are GitHub repos out there that essentially act as an orchestration layer around Cloud Code and change how Cloud Code works at a somewhat fundamental level. It's still Cloud Code. You're still in the terminal, but programs like this change how it plans certain things, change the way it executes, changes the way it records its progress. And the idea is that by using these orchestration layers, they help Cloud Code do something. Most often it's it helps Cloud Code handle complex tasks, complex projects. My take on this is that there's a lot of useful things in these orchestration layers, but you need to be somewhat experienced to understand when they make sense. Because just like with CLIs and just like with MCPs, you can be a kid in the candy store and you think you need to use every single orchestration layer that is out there for the sake of it. As if you're just one orchestration layer away from really mastering Cloud Code. I don't think that's the case, especially as time goes on. When GSD first came out, the way it handled things like context rot was pretty brilliant, especially compared to how Cloud Code does it now. Yet, a lot of the cool fundamental things of GSD and other frameworks like it have begun to be seen in the base level, out-of-the-box Cloud Code. It does a lot of these things now. It's constantly being updated. It's constantly importing these best practices. That's not to say these frameworks don't work. It's to say hold off on using them right off the bat. Less is usually more with Cloud Code and just understand what you're actually using. Don't use these frameworks for the sake of them.
Let's talk about the next concept, which is triggers and scheduled tasks, which can be kind of a confusing thing. Triggers that can be a lot of different things. That's just when a certain thing happens, we do another thing. Kind of like hooks. And scheduled tasks are when we want Cloud Code to do something on a schedule, even if we aren't there. When it comes to scheduled tasks, we have some options. And this also kind of plays into triggers. And that's the idea of loop. So with the loop command, I can have Cloud Code do something on an interval, whatever it is I want. Now, there's a few caveats. First of all, it's session-based. So, I have to have this exact terminal open for this to work. Secondly, it has a timer. So, max 7 days as of posting this, and they originally came with 3 days and now it's 7 days. Point being, you're somewhat limited because it has to have that terminal open. So, if I shut my computer down, that loop ends. So, something like a loop is great for, let's say, you were constantly creating deployments and you were constantly updating your website and you wanted a loop that every, you know, 30 minutes checked deployment status. So almost like a mini skill in a sense, but it's hyper-focused.
But what if you want to have Cloud Code do something all the time even if you aren't there? The answer is it kind of depends. So we talked earlier about the Cloud Code desktop app. One of the things the Cloud Code desktop app does pretty well is scheduled tasks. So if I go over here and hit "Scheduled," I can create a new scheduled task which will run every single time, even if I'm not there. So, I can do a remote task that will work in the cloud. So, let's say, "Hey, every morning at 7 a.m. I want you to check my GitHub and do X, Y, or Z." It will do that. It can even do a local task. So, I could have a local task where Cloud Code searches the web, goes on YouTube, uses the Notebook LM tool, and finds me the top 10 trending YouTube videos in a niche. It can do that as well. One of the caveats of doing that with the local task is that again, it's not session-based. So the desktop app will create a new Cloud Code session each time. Kind of like creating a new terminal, but my computer needs to be on. Cloud Code needs to be open in some capacity. So understand that it's not exactly a scheduled task no matter what. But Cloud Code does have the ability to create scheduled tasks on Windows. So I have one that runs a GitHub API and pulls the trending GitHubs for that day every single morning. That has nothing to do with Cloud Code. Windows, my computer, my machine itself does that. But Cloud Code wrote the script.
Now, we just have a few concepts left. And one of them I want to talk about, we alluded to at the beginning, is Ultra Plan. What is Ultra Plan? Well, Ultra Plan is kind of like Plan mode, but it's like a super Plan mode, and it works in the cloud. So, if I do `/ultraplan` and say, "Come up with a monetization plan for our app," it's going to say, "Hey, do you want to run Ultra Plan?" I'm going to say yes. And then it's going to start a Cloud Code session in the cloud. So it gives me a link and you can see Cloud Code just sort of like the chat app working here. Now there's a few differences with Ultra Plan. One, it's not totally confirmed, but based on how it works, the assumption is there are multiple agents under the hood working on this particular plan. So it's a little more powerful than your standard Cloud Code plan. The second thing you'll see is that once it gives it back to us, it's a little easier to change it and give it sort of your input. So, here's what it came back with in Ultra Plan. One of the differences is that I can just copy anything and I can leave a comment on that plan. I can even give it an emoji response because that's the best way to code. But overall, it gives you a just a nicer interface for it. That's the big difference. It's the fact that there's probably more powerful agents under the hood. Again, not confirmed. It gives you a different, more easy-to-use interface and it's easier as well to give feedback on specific parts. If you approve the plan, you just click down here, "Approve Plan," and it ports it back in the terminal. And then you get the option to implement it within the session, start a new session. Start a new session just clears the conversation but retains the plan. So, we get a brand new context window or cancel. This just came out this week, so expect a lot of changes with the Ultra Plan.
Now, we got two more concepts to cover and the second to last one is remote control. How you can use Cloud Code from your phone. The easiest way is with remote control. There's a few other ways, namely channels, but I will tell you for most people remote control makes the most sense. You just use it from your Cloud mobile app, but you need a session open. So, the idea is I already have a particular session open. I'm already working on something inside of Cloud Code, and then I hop on my phone and I use Cloud Code Remote. With remote control, it's almost like I'm streaming my terminal. So, it's pretty much I see the exact same thing just on my phone. So, it's useful in that sense. And if for whatever reason your computer shuts down or it goes to sleep, if it comes back up, the session will reconnect on your phone as well.
And the last thing I want to talk about is finding new tools for Cloud Code. I alluded to this a little bit when we talked about CLIs and MCPs and looking for them on GitHub via Cloud Code, but you can do this yourself. If you go to the trending session of GitHub, this is a great place to find up-and-coming tools for Cloud Code. Better yet, you can have Cloud Code do this for you every single morning. Like I said before, Cloud Code gives me this and it breaks it down by section. So, I see AI-related GitHub repos. So you can see right here, this is the trending for today, Wednesday. I can see the top 10 repos that came out in the last week. I can see their stars. I can see their topics, descriptions. I can click inside of them. And this allows me to have a pretty good pulse on what's going on in the Cloud Code world. And if you're someone who's serious about this and always wants to be kind of on the bleeding edge of what's happening and what's trending, this is the best way to do it. Now, not every one of these is going to blow your mind away, but sometimes you'll see something very interesting and early. And you can also filter it by month. It doesn't have to be by day. So, you can see all sorts of great stuff here because it is pretty crazy the stuff that's coming out every day. Like, it is every day. Every single day, there's something new coming out. And instead of waiting for someone to sort of hand it to you and tell you, "Hey, here's something you should try out," why not just go to the source? And it's also really interesting to see what is trending because just by diving into these and you can point Cloud Code at it and say, "Hey, clone this repo. Tell me what's going on." You're going to learn a lot too because there's a reason these repos are blowing up.
So that is where I'm going to leave you guys for today. I hope this video gave you some sort of framework, especially if you're just getting started, especially if you come from a non-technical background for where you need to start when it comes to Cloud Code. This is an amazing tool, yet it is very intimidating if you don't come from that sort of background. But I promise you, you can get through it. You just need to know where you're going. So, as always, let me know what you thought. Make sure to check out Chase AI Plus if you want to get your hands on that masterclass. And other than that, I'll see you.