Well, hello there. How's it going, everybody? Today, we're gonna go over my 50 Cloud Code tips. I've been working with Cloud Code basically every day for about six months now,
and I feel like I've learned a ton of things. And, yes, I am one of those engineers that are basically not writing code anymore.
I'm still in Cloud Code, like, twelve hours a day, actively
pair programming with Cloud Code, basically, and reviewing a ton of code. I still read every single line of code. That's actually my biggest bottleneck right now, the reviewing of the code. But I thought it would be great to show you kind of the best tips that I've learned along the way, and these are kind of tips that I wish I knew when I was first getting started. We're gonna start off with some foundation stuff like setting up very quick setup stuff, a little bit about, like, Cloud. MD rules, like, what you should put in, what you should think about,
and kinda some of the advanced stuff for later. But without further ado, let's dive into 50 Cloud Code So I got my terminal here, and I just have some slides behind to
tell you guys what I'm doing. So here is the foundations
that I mentioned. We're gonna cover getting started, keyboard shortcuts,
some essential, like slash commands, and a little bit of a deep dive into the Cloud. Md. So let's get started.
Alright.
So for tip number one, you wanna run Cloud Code in your root directory
of whatever project you're working on. So for example, I have this Pomodoro app that I'm, like, kinda been working on. So I'll type in, like, Claude here, and that's essentially how you get started. And you really wanna do this because
later we'll talk about this, but if you have rule files or any kind of setup,
the initial root directory is where Cloud is gonna zip up the context into that first token. So if you ever wonder why you had a bunch of tokens used even though you just opened up Cloud, this is probably the reason why. It's because Cloud's getting your project ready. Alright. So one of the first things that you wanna do is run slash init
like that. And what this does is cloud will go and look at your code base and do an analysis of your code base and then create that initial cloud dot m d file in the dot cloud directory
of your code base.
Now there is, like, different
directories that you could source from. Like, you could have a global one or, this one. But, yeah, at a high level, what this is doing right now is just is just looking at the code base, looking for the architecture,
and then, basically, it's creating that Cloud. Md.
Alright. So it just finished. It does take some time. And as you can see, it's
kinda going and saying, oh, this is this is like a Next. Js 15 app. It's like a portfolio site. But, yeah, it's just going over high level things about this particular project,
and then you could just essentially hit yes to commit that to your dot clot. So this is, like, really important for new projects, so I highly recommend you to run it. Alright. So the tip number two is that clot dot m d file that we just created, it kinda runs on a hierarchy.
So if you go to memory slash memory,
you could kinda see right here that there is a checked in memory, which is the current root directory, and then there's a user memory. This is like your global one. So that's, like, in your tilde
dot claud slash claud. So you could kinda choose between it, but it's it's really there so you can know what the core rule that the cloud code is operating on right now. Looking at the cloud.md that Cloud just created,
like, this is a pretty good one to get started. Right? It just has, like you you don't want it to be too large. It's, like, very small. Right? I I think around 300 lines is about a decent place that you wanna aim for. And to be honest, going larger is fine, but just remember that every time you increase that initial context window, you're gonna use more tokens, first of all, but also the more bloat you have in your context,
the less likely the AI will do exactly what you're trying to do. Alright. So for structure and what you should be thinking about putting into your Cloud. Md, I just opened another
project. This one is my Anime Pomodoro.
This is an iOS app, so I wanted to show you a little bit more examples. But, basically, the things I like to put is, like, high level technical architecture and the requirements, You know? Like, what is the project? Like, that's kind of important.
And then you wanna give it, like, some domain context. Right? Like, oh, it's using Swift UI, and I probably would add high level architecture and, like, kinda the file path and things like that. And just some of the high level design patterns,
like, you'll see, like, all of that should go in here. And then one of the important thing is kind of having your build flow, like, your validation flow, and this is, like, kinda where my build and validation is. So you can see that I'll, like, build the Xcode and then build a project, make sure things compile. Just having this loop of validation is so amazing because the AI will just be able to self improve
and keep going until it fixes itself.
So, like, if you're ever in that situation where you just, like, ask cursor to do something or ask some AI code agent to do something and it just doesn't work, a lot of that gets resolved when you fix the validation.
And validation,
I think, as a side tip is probably one of the most important topics that you should really think about when you're thinking about trying to build good AI agentic, like, coding systems or any workflows
is really what is the validation loop because that will dramatically improve
how good your AI will be. Alright. So let's go to some keyboard shortcuts.
And the reason why I even have this entire section for this is because if you're gonna be in Cloud Code all day, every day,
like, you're an engineer, you're just gonna be on this workhorse
for quite a while. So you should learn how to actually use most useful hotkeys, and there's essentially
shift tab toggle modes is pretty useful, and that's just like hitting shift and tab. And then you can see right here that we're switching from accept edits to plan mode. I actually use plan mode quite heavily.
I I think I use plan mode almost exclusively
whenever I start a new feature. It's rare that I start in edit mode. I always just want to verify and double check that my assumptions about the code base that I'm working on and the the direction that I'm trying to go with is the best option.
So I usually start in plan mode and spend a decent amount of time before I go to accept and just, like, start execution.
Alright. Escape interrupts. Let me just get something started here. Tell me a good way to plan a live activity
for
when I background the app. Okay. So I'm gonna let this go to show you guys what escaping
the interrupts is, but you can see that Claude is, like, thinking here, and it's, like, going through and doing things. Sometimes if especially during plan mode, you wanna kinda, like, look at this and look at the thinking and see if it's going off track. If it is, you just hit escape,
and then it interrupts.
Now a lot of people might be, like, kind of, like, scared to interrupt it, but you can just, like, hit up and then go right back to where you're doing,
or you could just interrupt it and tell it something else. The whole point is Cloud Code has a really good way of, like, deducing and entering prompts in a nice queue. It, like, it logically knows what to do. So you don't have to be so scared to, like, enter more than one prompt and also, like, escaping early and interrupting and changing course. Like, it's actually recommended to do that. Tip number eight is if you ever had something, like, really big where you copy paste something
and you're like, oh, I don't wanna delete everything, a handy shortcut here is just double tap escape, and it'll clear the input. There's also a VIN mode if you're into that, but I use this all the time. Another thing is when you're on an empty input, if you double tap escape, you'll see that you can rewind to, like, a previous point
and then restore that context point. This is kinda common with clock code, but a lot of the tools, I feel like, is really built to manage your context and context engineering.
And then there's just, an agent
that is wrapped around the orchestration.
But a lot of the, like, slash commands and stuff that we'll be going over, I feel like it's it's really to manage that context window. Alright. Screenshots is obviously a pretty common thing to do. There's a lot of ways to do it, but you can essentially take a screenshot
and then drag it over and just drop it in. And then, obviously, another good tip is to add context.
This is a cool picture of the Clockholm mascot.
Do something with it. I don't know. But
yeah. So that's a really good example of, like, taking a screenshot and bringing it over. If you are doing any kind of UI work, you'll definitely use this workflow. I also highly recommend finding, like, a Figma MCP or some form of MCP that works really good with the specific validation that you're trying to do. Alright. Moving on to essential commands, and this is slash commands. Before I end on the keyboard shortcuts, there's a lot more keyboard shortcuts, things that I don't use all the time. If you just go to, like, slash help, you'll be able to see a bunch of them. But the ones that I covered, I use all the time every day. So definitely just memorize it. I think it would be really useful. Now essential commands is, like, the slash commands that I think you should know about. There's way more slash commands, and you could, like, make your own slash commands, but these are the ones that I think is useful. Alright. So
slash clear is basically a way to
clear the context. Now you could actually do this by just creating another instance of Claude. Right? That's basically the same thing.
But if you don't wanna, like, do that, you could just clear the context. And this is really good if you wanna start a new feature and you're completely done with the old task, and you don't want the old context to blow up the new context and influence the new project that you're doing. Alright. So I just loaded some stuff. Let's go into slash context.
What this does is it will give you, like, a visual representation
of the current context
that
Cloud Code is operating in. Now why is this useful? So the main reason why this is useful is because it gives you an opportunity to reason about the context that Cloud Code is making assumptions on on your code base. Now I always say context is best served fresh and condensed, and you really want to take a look at this from time to time. If you ever felt like Cloud Code has regressed and, like, things are not working the way it is or your, like, cost and usage, like, bill is going up, you really wanna look at this and then see which are, like, the most biggest offenders.
Right? You just wanna, like, audit it. Like, MCPs are one of those very common things that blows up your tokens. I mean, like, look at all of this Xcode related MCPs.
And every time it runs, they're like I mean, these are not a lot because I haven't been doing that much in this particular workflow, but you could just imagine that once I start doing those iteration cycles, this, like, usage will, like, blow up. But So if you look at this and you're like, oh, this MCP is using so much, then you could remove it or just disable it for this directory.
So slash context is something that you probably should not ignore. Again, I think Cloud Code, all of the tools is really there to manage a lot of the context and doing really good context engineering, so this is a good slash command. Alright. So in terms of compaction, like, if you use CloudCode at all, if you had a long session, it'll start auto compacting at some point. All auto compaction does is it takes your current context window, like context that you created,
and then it will just summarize it. And then it does a pretty good job. For my projects, I usually just let the auto compaction work, but if you really want to compact what you have right now, you could just compact.
But I I rarely use this. The only time I use this is if I wanna save
some version
of my context into, like, my local, like, second brain. If you haven't seen that video, go and check it out. But I have the second brain concept when I work on projects, and that's where that goes. So for slash models, this is, like, very useful, I think, if you have unlimited tokens. Like, if you're doing this at work, for me, I usually just default it to Opus 4.5.
But if you're very, like, cost sensitive and you know certain workflows work well in Sonnet or, like, Haiku, then you could just go and change that.
Keeping at default is fine too, but I would try to use Opus as much as possible. Alright. So slash resume is really useful if you accidentally, like, lost your instance. Let's say you created another one and then you accidentally killed it or something like that. Right? Oh, you killed the wrong one or something. Then when you go back into ClawCode, you could just slash resume
like so,
and then it'll give you kind of the old context, and then you could, like, recover your context so that you don't lose the all the work that you did in building up that context window. Alright. Slash m c p is really about
showing the MCPs that you have installed.
If I have to be honest, I try very, very hard to not use MCPs
because I think they blow up your context window. So I only install ones that are needed for that very specific project,
and I try to just leverage Cloud Code and write scripts and, like, these kind of things manually, like myself,
to do the validations and things like that. But some projects, you just do need MCPs.
Like, this Xcode one, you kinda need it. And for other projects like my Next. Js apps, I have, like, a whole set of MCPs for that. But just be careful with MCPs, but it's a really fantastic way
to teach Claude how to do certain things, especially with, like, third party software
and things like that. You know, it's a protocol. Right? Model context protocol. So it's basically used everywhere, but, again, it's known to blow up your token usage and your context window. So just be careful. Alright. So slash help is the last thing I'm gonna teach you, you know, teach a man how to fish. So this, like, little wizard here will just teach you what they are and give you, like, descriptions of everything. So just go ahead and, like, try these out and just take a look and, you know, explore. Alright. So the next thing is around git. So
you could ask Cloud Code to manage your Git. I think there's a bunch of, like, skills you could download to Cloud Code to manage all your Git, and I think that's something that you should do. Like, I write a lot of my summaries and test plans all using, like, Cloud Code now. Obviously, I have my own templates that I wrote, so Cloud kind of sounds more like me and is not too verbose and things like that. So I highly recommend you to use Git as a safety net. There is actually a rewind feature, like I think I told you, where you could restore the code in the conversation, but this is a little confusing to me. Like, Git is just better. I use this as, like, a last resort if I didn't have Git
for a certain checkpoint. So now that you know how to just navigate around Cloud Code and things like that and just kinda high level important, like, commands and things like that, I think it's a good time to deep dive into the cloud dot m d file. I think for most people, most users, like, 80% of users,
if you just have a really good cloud dot m d file for your project, you could get really, really far without learning, like, all the advanced stuff. Just having a really good rules file will save you a lot of headaches. Let's kinda dive a little bit deep into this. Okay. So one of the most important things in
the claw dot m d files is first of all, it's like, it actually reads top to bottom, and it keeps the priority from top to bottom. I think that's, like, a very small nuance. I'm pretty sure that's true. I think I read that somewhere. But So you wanna go top to bottom as, like, important to least important.
And you wanna add things that are, like, never do something, but always do this. And then have, like, clear snippets of examples, I think, is really good. And I don't have that many on this particular project because it's stock SwiftUI,
but the context here is that you should really think about how unique is your project, how many things about your project is, like, homegrown and, essentially, like, the AI may have never seen. Like, remember, a lot of this code is, like basically, a lot of the AI, like, coding is basically just
an accumulation
of, like, the best code that the AI is trained on. So it might not know your, like, super special
DSL
language that you created or, like, some random archaic
patterns that your company has,
and that's where you'll be like, oh, why is the AI never doing this? So whenever you run into something like that, you wanna fix it manually,
and then you just
update your cloud.md
rules so that it never does that mistake again. Think of it as, like, Lint files kind of. And then when you ask Cloud to update the rules, you shouldn't ever do it manually.
You should just go here into Cloud and and say, hey. Can you update that rule for me so we never do it again? Something like that. Like, as simple as that, we'll go and update the your Cloud dot m d files.
You see how it's trying to do it? Obviously, there's nothing that I just did, so it says nothing to add. But yeah. Okay. It it added something that I thought, but you get the point. Alright. So this next one is really around
using, like, keywords
to trigger your skills. So, basically, I have these, like, build commands inside of my rules. So when I say, hey. Use my Xcode MCP to build, it'll try to build the app, for example. Use my Xcode MCP to build the app.
Okay. My whisper stuff is, like, failing a little bit, but maybe you'll get the gist of it from build the app. And as you can see, it's it's asking if I can use the Xcode Build MCP. So that's kind of the high level of, like, using skills and, like, trigger words to be able to trigger a certain behavior. This next one is something called, like, compound engineering. That's, like, kind of a new term that is being discussed, but
it's essentially to take your Cloud. M d and start,
like, committing it into the code base. Now, obviously, you need to get rid of anything that's, like, generic for your code, like file paths and things like that, and you also wanna be mindful of how large this file becomes. Right? Because, like I said, every time someone hits
Claude in that directory or Claude is trying to read that directory, it will load that Claude dot m d file. So you don't wanna blow up other people's context windows, so you really wanna be have this be, like, a high bar when you're committing it. But the nice thing is once that's in, you essentially make that AI coding experience better for your teammates. But you just need to make sure that whatever you're landing is actually helping. There's a lot of school of thoughts around this right now. I don't think it's, like, completely solved, but there's gotta be some form of evaluations
here. And a lot of people are just using, like, Vibes. So you just, like, test it for, like, a few weeks, and then you just try to land it aft and then ask for feedback, essentially.
So dangerously skip is essentially like claw code in YOLO mode. You know? Like, just basically,
if you use claw code, it'll ask you to accept a bunch of stuff. It could get really annoying. So a lot of people, they use, you know, clawed and then dash dash dangerously
skip.
Okay. So it's
dash dash dangerously skip permissions.
And when you run this,
Claude code will no longer ask you essentially to accept that. I think it will completely just ignore it except for, like, anything you put into your slash permissions, which we'll talk about. But
you only really wanna do this in in
environments that you can kinda throw away
and you're doing specific work that is not, like, super dangerous. Like, if you're gonna start touching the OS and stuff like that, you could really mess it up. I've messed up some of my Linux machines because I was just going too aggressive, and I was just testing it out, and I was trying to set up some of my Linux stuff using ClockCode,
and then, like, I had to reflash the entire thing. Like I said, you can use slash permissions
here to kind of, like,
tell which ones are like, you still want to accept. So it does you know, like, r m dash r f or something, like, don't do that. Or
yeah. Just like mutations. Like, just be careful with mutations, like, deletion mutations. Right?
Alright.
The next big one, I think, now that we talked a little bit about the CloudNMD rule of files, I think we should talk about workflows
because
I have a very specific way I'd like to work, and I've actually refactored
my entire work
so that it's works with Cloud Code. You know, I used to use Cursor or, like, Android Studios mostly and Versus Code to do a lot of coding and stuff like that, but I dropped basically all of that, and I use just iTerms now.
Some people use, obviously, Vim, but I think iTerms is fine. So I'm gonna show you guys a few things. So
like I said,
I always start with plan mode. Let's go in, like, plan, like, a little feature for this Pomodoro app that I've been, like, kinda working on. I don't know. I actually need to remove a bunch of audio stuff. So let's just say, audit my code base and make sure that we're removing all of the audio playback and references to the audio
of part of the Pomodoro app. I'll always start with plan mode, and I'm, like, iterating with Cloud Code.
I'm arguing with it. I'm having a conversation with it. You know, Clocko, you're so beautiful. You're so amazing.
No. But, like, I'm really treating it as, like, another, like, just good engineer that I'm, like, working with, and I'd never just, like, purely accept
the first answers that it gives to me. I'm always kinda challenging it, and I spend a lot of time and put a lot of effort at this stage of the development.
Because I feel like once CloudCode builds up that context and have good execution
specs,
the generation of the code is actually the easy part. And I I do wanna take a moment and talk about, like, kinda the news cycle about people saying,
oh, like, people are no longer writing code. I think, like, the
creator of Node. Js said, like, the era of, like, people writing code by hand is essentially over, and I actually truly believe that. And the thing is I love, like, being in the zone and writing code. At least I used to. The thing is it's really hard to get back into that mode. It's, like, very different levels of abstractions of the way you're working.
And right now, I'm just doing one instance of it, but you could imagine
just having, like, multiple cloud instances
like this, and and and then you're just actively working on a bunch of different things at the same time. Because you have this, like, new superpower,
the new next level of engineering is really, like, jumping between
cloud instances
and and really context engineering
that instance and then getting it good enough to start executing. And I keep talking about this, like, context. Right? And this tip is really around, like, fresh context
beats, like, bloated context. I think I kinda cover this throughout this,
but that's why you wanna start with plan mode, make sure it's good, and then just go and execute. Instead of, like, having a bunch of, like, try this and then try that and then try this and then try that. Like, that will just bloat that context and then the AI will get really confused at some point because it it can't remember what what part of what was good and not good. So that's why you wanna spend the time in the beginning building up the good context, have a good plan doc. So it always has something that initially was good to reference,
and then it builds little by little. Alright. So this next one is really around persisting
that context.
I have a full video on this about,
like, the second brain concept, so I'll link it here. But the idea here is that, let's say, you've finished something. You could just say, save this to my local cloud.md
in my project's directory.
Save the work that we just did. So you you could say something like that, and then, um, I I essentially have a full workflow for this to manage this. But, yeah, you you could do that.
Load my context
from
my
local projects. So once you have that second brain concept, you could say a command like this,
and it will pull that context
and then load it for your new session. So here's a good example. I like to do a lot of my to dos inside of Cloud Code itself. These are kind of the high level things that I still need to do for this next feature that I'm working on. So I'm, like, working on a widget for this Pomodoro app, and I have, like, a live activity, for example.
And I'm also, like, deleting all the music stuff because I don't think it adds value.
So I have a bunch of stuff that I'm tracking, but because I keep all the to dos in my local
index, like, that I'm lazy loading, I don't always load it. I only lazy load it when I ask for it. It allows me to, like, context switch from project to project without, like, carrying around, like, complex, I don't know, Asana boards or whatever. I just keep it all in here, and it's this is this works because it's my own project. But you can technically do this with, like, an MCP with Asana or, I don't know, Jira or whatever
as long as you can whatever project management that you can think of. Alright. So I think we covered this a little bit, but really think about the build cycle. Like, obviously, if you're mobile,
think about x code building the x code. But there's a lot of other workflows that you could think of. Like, for example, you could ask Cloud Code to like, let's say you're debugging something that's, like, kinda tricky, has, like, race conditions or things like that. You could ask Cloud Code to, like, add debug logs, for example, and then run the app and then
have Cloud Code control the emulator. You could just ask it to do that and then, like, do the actions that you're trying to do and then read the logs through a tail log or something and then debug that way. Or you could use, like, Perfetto or something like that for kind of performance things. You could hook into Perfetto MCPs,
do a run, and then have it read the traces, and then see if it can find jank just from, like, the timings. Right? There's just so many validation loops that you could think of. Like, for web, you could do, like, Puppeteer and have Claude navigate it using a slash Chrome command and then just actually do the navigation or have it write just test or have, like, integration end to end integration test. You know, there's there's a lot of things that Cloud Code could do, and it really is up to your imagination.
But it's the single most important thing in my opinion if you wanna have a more
automated loop that, like, generates good code on, like, the first try. So going back to the slash models,
really just consider using Opus if you can afford it. It's just the best way. All of these are a little bit slower, but because the way I work is I have multiple cloud instances, obviously,
it's, like, very small, right, in here, but I have multiple cloud instances running at all times.
And then the way I work is basically just juggling these cloud instances. So even if one of them takes a long time, it doesn't matter because I'm
like,
I gave the command, and I go to the next one. I'm building the context. I give a command, and I go to the other one, and then I give a command.
So so, like, you end up, like, still
can get into the zone, but it's, a different style. So I talked a little bit about interrupting
earlier,
but you really want to,
like, look out for, like, assumptions
or the keywords are like, oh, I'm not really sure, or you'll see, like, errors happening.
I'm having a hard time, like, getting it to do this in this example, but
just just know that, like, when you
go and look for the
best ways to delete an app. I don't know.
I I'm just giving it a random prompt to try to make it go off course,
but if you see it going and making assumptions about certain things okay. This time, it didn't even because it's just new. But you should just interrupt it like that. You know? And then and then just course correct it. So don't worry about course correcting. Okay. So the next section is around power users. I I don't really like to say power users, but most people that I've talked to don't really know, like, the differences between a slash command or a skill. They're they're kinda interchangeable now. And MCPs, sub agents, you know, post hooks, pre hooks, like, these kind of primitives that ClockCode is, like, known for and kind of, like, invented. And we're gonna cover some of that and and how this
these are all, like, composable in nature. Okay. So I call it the composability framework, but it's I just really wanted to highlight that these are composable more than anything. But there's
four primitive, like, composable things. All the slash commands are technically composable with each other, not directly each other, but anyways.
So we're gonna just go over the fact that, like,
how these are composable.
Okay? So let's first talk about skills.
All a skill is is is, like, you do a workflow. So let's say that
I tell Claude, go and fetch Hacker News for latest iOS news.
So let's say I tell it to go and fetch Hacker News for the latest iOS news,
and then
and then I tell it to save that.
Okay.
And then save
a summary
to my
local
claud.md.
Claud directory.
Okay. I misspelled that. But, basically, let's say that it went and found some, and then it's
save it into my local directory. Let's say I wanted to build a skill around that. So you just saw me do two things. One is fetch something from a source like Hacker News and then save that thing to my local directory. That's technically a workflow.
So all you have to say do is save what we just did into a new skill called fetch hacker news. And that's basically it to create a skill.
It's basically a recurring workflow that you can
just tell Claude to remember. And behind the scenes,
it's actually just an MD file, as you can see right here. Oops. And as you can see here, it's literally just a system prompt. It's an MD file.
But Claude
has specific directories that is looking for skills, and it will be able to infer this next time I say, go fetch something from Hacker News or use my Hacker News skill to fetch articles.
Yeah. And then commands is basically now interchangeable.
It's it's a pretty recent change, but you can see that
skills
is written into the skills documentary,
and it there's also now a slash command called slash fetch hacker news. This is a very recent change from Anthropic where they kind of, like, combined
commands and skills. But yeah. So now you can just do slash hacker news, and then now it'll rerun that system prompt, for example. It added, like, an additional, like, assumption thing. That's pretty cool. It's not exactly what I did, but it kind of inferred that I would probably want that. So those are the little cool things. And and the thing is you could update these anytime you want. You know? You could just ask Claude to do do something else.
Alright. So like I said, you never wanna manually create these kind of stuff. You wanna get in the habit of
asking Claude to update and manage
these skills. So we could say, why don't you extend this fetch hacker news to fetch Twitter or Apple news, for example.
Now sometimes
it won't work 100%
exactly. Right? Okay. So you see this? It doesn't have Twitter authentication access,
so it's
trying to just do some other ways.
Yeah. Multiple sources. So you can see how it's all updating
that system problem that we wrote. Right? And then fetch hacker news
and so forth.
You you get the idea. Alright. So MCPs,
I think we covered it a little bit during the the rules, but, basically, MCPs,
you just wanna find MCPs
like this. Right? Like, they're just model contexts.
But kind of a hack is, like, you don't actually need to search the web for an MCP. You could just be like, find me a good Figma
MCP.
You could just ask Claude to find it for you, and then most of the time, it does a good job. The only thing is, like,
sometimes
it's outdated,
so it'll it'll, like, know of one that's was popular a little while ago rather than doing a web search. So you just have to be mindful. And that's why I'm saying, like, for certain actions, you wanna read
how what it's doing and look at the thinking and then cancel it if you want to. And you could have Claude also install the MCPs, so you don't have to, like, manage, like, the configs and stuff yourself
like you had to with cursor. Yeah. So you could ask Claude to install the MCPs.
So, like, right here, it says, go and do this. Right? But instead, I could just be like, why don't you just install this for me,
for example? And then it will just go and install it for you.
Alright. So in terms of sub agents, I don't know if I have one for this. I might have, like,
an iOS
I might have one, like, an iOS, like, context gathering
or, like, architecture
agent. Let me try it. So spawn a iOS architecture
agent
sub agent and do some investigation
on and on my code base and see if it's actually good or not.
So you can build subagents just like you can with
slash commands and skills. All you do is just ask it to make a subagent
after you do the work once.
The main reason why you want to create a subagent is really to do parallel work,
but also it's to protect your context window.
So like I said, one of the key features of Cloud Code is to manage your context and do context engineering,
and subagent is a huge way. And I think a lot of people are using subagents incorrectly
because they do things like this where you have, like, an iOS subagent. Right? By the way, it's not triggering the subagent. I'll just make one after it creates it and show you guys what it looks like. It, like, highlights it in, like, a different color.
But a lot of them have this, like, workflow where they'll tell it to go do something that does the context gathering,
and then they ask to, like, bring it back. But that part that portion of the context that's bring brings back from the sub agent, it's only, like, the output. It's not, like, how it got there, so it doesn't have the full context.
So for those kinda works, I usually just keep it within the context window because those are the things that are really good. Use what we just did to create
a iOS architecture sub agent. But yeah. So so oftentimes, people mistake that you wanna, like, have a
validator agent. You wanna have, like, a testing agent and all these kind of things, but I try to keep the all the things that need that context
to do its work within the same CloudCall session. Because, like, a good testing agent needs to know about the code that I wrote
most of the time,
in my opinion. Of course, sometimes things could live in isolation.
So what are really good things for
sub agents is really just, like, things that are atomic in nature that you wanna just have it run as side effects and just go and do. But, yeah, so that's what I use sub agents for. I don't use sub agents that often. I know some people, like, love using them. But one of the most common, like, clowny kinda use cases that I've seen is, like, CEO agent, product agent, design agent, and stuff like that, and I don't really believe in that particular workflow. Like, you really wanna have this concept of bringing the work to the context
rather than trying to spread out the context that gets created. Alright. So and this kinda ties into it. Like, you wanna avoid,
like, having a lot of instructions and overloading
the context all the time. You wanna keep your context condensed
and fresh.
So that watch my video on the second brain, and you like, that's it'll teach you a lot about, like, lazy loading and then having this, like, ongoing project domain thing that builds over time, and you wanna essentially
use that as your rag system
to build, like, a good context
and then be able to just have fresh and good context all the time for your AI to execute on. Alright. So here is some interesting, like,
advanced workflows,
and I really think that
the big game changer, in my opinion, for Cloud Code and why I think Cloud Code is just so amazing
is that you can do a lot of parallel development.
This is why I had to, like, fully change
how I work using, like, terminal and stuff because you could run multiple instances. And I already kinda showed you guys this,
but you could just swap between these and just have, like, multiple things running at the same time. So I could say, start working on my live
activities feature. So I could just have that. Obviously, I would do it in plan mode, but I'm just showing you guys. And then over here, I could just say,
alright. Let's test out this iOS architecture
and and then just spawn a sub agent. So as you can see, I'm doing some investigation on one side, and then I'm doing live code editing. But the thing is, I could always just create another one, go to, like, a different project like this,
and then now I could be saying, hey. I wanna work on a new newsletter,
for example.
So I could be doing a bunch of stuff all at the same time. So that's like a really so understanding how to juggle this and doing it effectively,
I think, is, like, the next step function change.
And I just wanna kinda shout out iTerms. I think it's, like, really good
because,
you know, you could do command d to create new instances like this. Right? And then you could juggle between
the terminals using command
the left bracket and right bracket. Like, ignore this, like, slash. It's like I'm just saying, oh, it's left bracket or
right bracket,
like slash. Right? But yeah. So and you could do that. You could also if you have multiple tabs like this, you can actually swap between it. And at work, what I do is I
rename,
like, what I'm doing in here. Like, I'll say local, and maybe here, I'll say, like, remote SSH or something like that. And then from the remote SSH, I could have Cloud, like, running like this, and I could spawn them more.
You know?
And then and then I could just be going back and forth here. So it really feels like I'm playing Starcraft to some degree.
Right? And all of these, I'm just doing with my keyboard. And when I'm home, I'll just, like, be in Whisper
using Whisper, which is, like, this voice little thing that you see right here, and it just translates
speech to text really quickly. Sometimes it's not that accurate, but so I'm just, like, switching, switching, and I'm just basically talking to it, you know, just literally working as in multiple projects all at the same time. I think my bottleneck right now is really how much context switching I can do in my head. So, yeah, another thing is enabling notifications.
You could tell Cloud Code to change the notifications.
Right?
You could just say, the notification to ring a little sound when you finish execution,
for example.
And then when it's now,
it'll basically
ring,
like, a little notification.
And and you could do a lot of things. At one point, I had, like,
text to speech
where it, like, reads a summary of
one of wherever it finishes, it will read the summary. So I could be like, okay. I gotta go back to tab two and then go do something.
But that was too much, so I disabled it. Gig Worktrees
is another way to do multiple code execution. So one of the bottlenecks that you'll see is if you have these kind of, like, bunch of multiple instances, you'll soon realize if you're doing local development, you won't be able to make code edits to the same project
unless you use Git work trees. And I'll add some descriptions on how to use git work trees, but, basically, it's it's a way to, like, clone multiple instances of your code base and have, like, different forking branches.
So you could have, like you could work on, like, code, like, executions in the same project.
Slash Chrome is actually a really cool tool in my opinion.
So the way you get to it is by just doing slash
Chrome like this, and then it'll go to, like, slash Chrome. And then it'll open this thing. You can't see it here, but there's, like, a little button. And it just opens it, and you could actually
navigate the browser. So
go to
tip number
46.
So what it does is it will look at the website, and it'll and you can approve the plan. You can allow the action. So, basically, it'll create the plan, and then it will, like,
do it. Okay. It doesn't it doesn't really know how to do it. So
I'll say
hit
let let's just try YouTube. I think YouTube might be easier.
Okay? So we'll we'll open YouTube and then say,
find a video
on
cooking,
for example.
Yep.
So you can see that it, like, takes a screenshot. It will, like, click. It'll type cooking,
and then it will, like,
find cooking videos, for example. And then so I use this whenever I don't have API access to certain things,
but I can get there via my web. And and because you could control it via slash Chrome, you can have it
as part like I mentioned, that all of these are composable,
you can have a command that goes to Chrome,
scrapes bunch of stuff, and comes back to you with the data. Okay. So moving on. Like I mentioned, it's really good for a power for, like, debugging. Right? You can navigate the web with it.
That's also part of the validation thing that I was talking about. You can fill out forms and stuff. Alright. Hooks and automation is really just, like, kind of the cherry on top, and this is very similar to, like,
GitHub's prehooks
and GitHub's, like, post,
like, commit stuff, like, recommit stuff. So,
basically, these are hooks. And as you can tell, it's just, like, something to do before
you start executing or after executing
and after executing fails. Like, there's all these things that you can do, and you shouldn't manually do this. You should just ask Claude to,
like, add these for you. You know? Like, go back to that principle that you're no longer main manually maintaining
your work environment. And a good example on what to put here for the post
tool use is, like, you know, things like
art like linting and and formatting your code and things like that. And I'm not really using this yet, but, basically,
uh, this is really good if you wanna block, like,
removing your entire, like, database or something like that. It's it's just, like, good good to prevent
very disruptive things.
I haven't really set it up because, you know, I have, like, remote backups, and, also, this is, like, side projects. But for real world, you probably want something. And finally, with that, I think you got the vast majority of, like, the best tips that I know for ClockCode.
The last thing I'll leave with you is to explore the, like, the plug in ecosystem.
All a plug in is is a just a combination
of any of these composable things that I talked about, like a skill that triggers an MCP that triggers, like, sub agents or something like that, or maybe there's, like, a bash script that's attached to a skill,
that can all be turned into a plug in. And then a lot of people share their plug ins online.
So this is, like, a really good example. You know, Anthropic has their own, like, plug ins, like, structure,
and they have a bunch of plugins here that you could download, for example,
um,
like, colon ISP and things like that. So that's basically it. And the last thing I wanna say is context is king.
You gotta keep it fresh, keep it relevant.
You essentially need to give Claude
the context that it needs and nothing more.
But yeah. So
go and build something amazing. I hope this was valuable to you. I hope you learned something. Go and build something amazing.
And if you're interested in this kind of video on CloudClode,
I did a whole video on, like, kind of the high level thought process
of, like, AI coding
and and also talked a little bit about my second brain thing. Those two videos are right here, so go and check it out. But, yeah, until I see you guys on the next video.