I spent over a hundred and fifty hours now inside Claw code, not just building with it, but studying every single major resource on it. I've broken down the creator Boris Cherni's post, tested real workflows from top builders, and watched every single master claw tutorial that I could find. And here's what most people miss. Even if you think you're using claw code well today, you're probably stuck at level two or level three. This video shows you what's beyond that. I'll walk you through all seven levels of claw code from beginner workflows
to fully autonomous systems so that you can skip the trial and error and start using it to its full potential today. And by the way, if you're looking for a full Claude code course that takes you from zero to expert, then check out the link in the description below. Now let's dive into level one. Let's quickly make sure it's set up in our environment. So we're gonna come into a fresh instance of Versus Code, open a folder, and open a new terminal. I'm just gonna open the the README here, and we're gonna run this native installer that doesn't require Node. Js. Gonna run that inside our terminal, and that's gonna make sure that Claude code is installed for us. And we're gonna start running it just by running Claude with the basic permissions. And once Claude opens, it's gonna look a little bit like this. Now level one is actually prompting but with intent. So most people just type and hope at the start. But the difference between somebody who's a beginner with claw code and someone who's gonna get real results is one single habit, and that is planning before building. So plan mode, which you can turn on by hitting shift and tab and cycle between the modes. You can see down here we've got accept edits, which is the default mode, and plan mode is a read only mode. It's designed to research your code base and propose a plan before you touch anything. So whether you've got an existing code base, it will go through and read those files. Or if we're starting from scratch and we're giving it some context brief, it's really critical that we start with planning mode. And Boris Cherny, the creator of Claude code, has strong opinions about using planning mode. If my goal is to write a pull request, I will use plan mode. And I'll go back and forth with Claude until I like its plan. So it does not take any execution actions until a plan is made. From there, I switch into auto accept edits mode, and Claude can usually one shot it. So it saves us going back and forth, and, actually, we only need to one shot prompt for the execution once we've got a clear plan. And the reason this mode is so powerful is because it leverages an inbuilt ask user questions tool inside Claude Code. Claude will literally come back to us with a series of questions to understand the underlying detail and the assumptions that we're making in our plan, therefore, building out a really comprehensive set of context
that you can use in the execution phase. So we're gonna look at an example today of a content creation system and how we can use Claude code to actually build us out a system that creates all of our content for us. So if I put in something vague during plan mode, like help me build out a social media content creation system, we know that that's not gonna execute very well, or it will veer off course and not meet our assumptions because we're not actually specifying that. So by doing this in plan mode, we can force Claude to give come back with the ask user questions tool, ask us a bunch of questions, build out a plan dot m d file, which then when it executes on, it will understand in detail exactly what we want to do. And then we can see down here which social media platforms do you wanna create content for. We click that. It will come up with the next set of questions in the calendar, then about the automation, the brand voice, and then we submit, and it will create a plan for us and ask us any additional questions or ask us for any additional assumptions before we start executing a thing. So level one users make sure that they're planning before they execute. So now that you've got a plan, you need to make sure that ClaudeCode isn't gonna put out generic slot within that plan, and it's gonna work in a way that actually saves you time and not cost you more time in the end. And that brings us to the Claude dot m d file and the importance of having one for your team. So Claude, like a coworker,
needs to actually understand your rules and the way you want to work with it. We use Claude dot m d to show that. It's a file that tells Claude how you work, and you can think of it like literally onboarding a new team member. You write down your tech stack, your preferences, the mistakes you don't want repeated,
and Claude reads the file every time you start a session. And this is how Boris himself uses it. So their team shares a single Claude dot m d file. They keep it version controlled on Git, and the whole team contributes lines to that file or edits lines to that file. Don't necessarily add more lines to that file every single week. And they'll even go to the point where they'll tag it on GitHub, and it will make the changes automatically
to tell it what mistakes it shouldn't make again. And there's lots of opinions on how you should write your claude.md file and what should be included. But the golden rule here is keep it short, keep it specific, and only include
what Claude can't figure out for itself. So we've got a very simple framework that you can follow to set up your Claude dot m d file for any project, and we're gonna talk about how we do that for building a social media content machine that sounds exactly like your brand voice. Now question one, what is this? Should just be a single line to tell Claude exactly what it's doing. It's not your brand manifesto.
For this social media content machine, this project generates daily social media content across various different platforms in a brand voice, pulling topics from a content calendar in Airtable. That's it. Claude is then able to understand exactly what its purpose is before we tell it how you're gonna run things, which brings us on to the second bit, and these should be the exact steps. So the content calendar lives in Notion. This should actually be Airtable. We're gonna pull topics
from the ready to write view. It's gonna put generated posts into a new folder inside this explorer, and we're gonna store any image assets in a separate folder. Now once it knows how, I e, the instructions it's gonna follow, we're gonna add things about brand voice, your rules, your nonnegotiables.
So what patterns do I follow? And you can use emphasis on words like important
where you need to make sure that actually it's really important that Claude follows those instructions. And we've got some example brand voice stuff in here, like write like you're talking to one person over coffee, not presenting to a boardroom. But actually, better thing to do here is not to write this directly in here. It's to separate a brand voice document and then reference it later on. And this brings us to the point, don't dump trick, which is actually keep claude.md
super lean, tell Claude where to find the details. So if you're saying, follow these brand voice guidelines, you would say for full brand voice guides with examples, see this folder slash docs slash brand voice dot m d. And this might be things about brand voice. And the what patterns do I follow might be things about platform formatting, like keep it under 200 characters. It might be content rules, so every post must teach something or share a real experience and be very, very practical. But, again, these rules can live separately in separate folders, and the Claude dot m d file needs to just reference where it understands and reads those rules from. Question four is where we ask the things about mistakes. So what are the things that's gonna trip Claude up because it's not counterintuitive?
Like, for example, our Airtable or Notion might have a status and post status column. Which one should it use? So these are the things that you'd put as your edge cases for an employee that you're training on this. And then the final part of the framework is how do we work? So every file is gonna be named in this convention.
We're never gonna publish or schedule anything. When repurposing,
we're gonna change the angle, not just shorten. So it's additional information that feeds into the instructions to make sure that it delivers the outcome that you expect. So this is your guide and your your set of rules. And down here, we've got a copy paste template, which you can grab that goes over all of these with an example and create your very own Claude dot m d file. And we would click on the tab over here and actually introduce our own Claude dot m d file. For For now, we're gonna keep it super simple and just give it the project instructions. This project generates daily social media content across LinkedIn x and Instagram in my brand voice, pulling topics from a content calendar in Airtable. It's important to add things like mistakes in here and how to reload that into your context. We're gonna say write a LinkedIn post about Google antigravity versus
Claude code for business use cases. And this is the equivalent of not telling a new employee how we want the outputs and just giving it this very generic project instruction. But as we understand how they work and how they perform, we add in rules that help clarify the direction that we're looking in as well. And it's come back with an okay LinkedIn post. It's had a first stab at it. This is the equivalent of putting something into ChatGrpT and just hoping for the best without telling it anything about brand voice, how you want the outputs, etcetera. So we're just gonna add some simple rules. Never use em dashes because we know that signifies that it's written by AI. Instead, regular dashes.
Always replace the word antigravity
with AG. Maybe we've got a specific rule in our company that we always write AG instead of antigravity.
And I also felt that it was a very, very technical output here. It talks about existing stacks.
Claude code is a CLI tool, command line interface tool, the full IDE, whereas actually, want to talk in business terms, never use technical jargon.
So what we need to do then is effectively add that to our project rules inside the Claude dot m d file. You can format these however you want, and we need to restart for these to take effect. So we're gonna hit clear or slash clear command. It's gonna basically effectively restart then. So we're gonna reask it again, write a LinkedIn post about antigravity versus claw code, and now it's gonna have these rules embedded into it. So, hopefully, it changes things like antigravity to AG. It talks about only business value and not such technical jargon and has no Emdashes inside. And we see it's been reloaded, AG versus Claw code. It's got no Emdashes inside. It talks about time to value, quality control, and scalability instead of previously talking about very technical content. So it's understood and ingested the rules that we've applied by reading that claude.md file. Now a bit of a sense check you can do is, can I read this Claude dot m d in sixty seconds? Am I under 30 instructions? So 20 to 30 is kind of the maximum. And, again, you can reference other files and folders where it can find things. Did I include specific examples,
not vague rules? Again, those can be elsewhere. And would a freelancer, a human freelancer taking over my content find this useful? If you're already inside a project and you wanna set up this Claude dot m d file, then you can run slash init, and it will actually go through your project repository
and create a Claude dot m d file for you that you can go back and rectify and remove lines from. But if you're starting from fresh, just copy the template and fill in the blanks as you build. Like Boris, fix mistakes in real time. And when something goes wrong mid session, you can just tell it, Claude, add this rule to my Claude dot MD file, and it will do it for you or you can add it directly into the lines. So at level two, Claude is now following your personalization and your rules. And Claude may be following your rules, but we're still having to start fresh every single time. We're typing the same things over and over like create me a LinkedIn post to get it to perform our actions in the way we want. So level three is all about slash commands and skills. Now you can just think of slash commands as saved prompts that you can reuse with one keystroke. So tasks that you're doing again and again that you can manually trigger at specific moments. So for example, we might say, write me three LinkedIn posts about this topic. And all we'd have to do is type in slash LinkedIn post.
And actually, the command, the prompt says, write me three LinkedIn posts about this topic. And then we actually pass in dynamically the topic name when we're prompting it or slash commanding it. So the way that we do this is actually just creating a new folder inside our explorer called dot Claude,
and we'll keep using this folder slash command. So it's a subfolder inside dot Claude. And then inside that, we would actually create a new command folder. Let's call it LinkedIn dash post dot m d. So it's a markdown file again. It's a folder inside of that command subfolder, and we've got an example command here for our social media system. Write three LinkedIn post variations about,
and then we've got this dollar arguments, which is where we're gonna pass in our dynamic values, which we'll show you in a second. And then we've got some rules. So pull my brand voice from /docs/brandvoice.nd.
Right now, we don't actually have that file, but we'll set that up next. Start with a hook, then have a line break, then the body. So this is specific context
for this specific command. So think of this as a prompt for this command. End each post with a question or CTA. Keep each post under 200 words. No hashtags.
And then save the drafts to a slash output slash drafts folder. And right now, that's not created, so it will automatically create that for us. Now if we just clear our memory here, this resets the Claude code instance. And I start typing in the name of the command, LinkedIn dash post, and for some reason, it doesn't show. So what we need to do is actually hit control c control c, close the session with Claude, and reopen it with Claude.
And now it should recognize
when it's restarting that we have this dot Claude slash commands folder with this new command thing. And as soon as we hit slash, you can see that we've got our new command linked in post in there. So we're gonna use the command linked in post
anti gravity versus Claude code, and it's gonna understand now and pass that link anti gravity versus Claude code as this argument. So it's gonna say write three LinkedIn post variations about this and follow these rules. So instead of typing this command every single time that I want to create a post, I'm just gonna use the slash command, pass my arguments, and now it's gonna add them to a draft folder. It's outputting our different variations in here, but we told it we also want it to output them as documents in an outputs folder so that we have them stored. So it's created this output folder. We've got the drafts, and we can click in the specific file. Open that up, and we've got the variations here. I've been using both a g and Claude code, and you can see it's now reading from our claude.md document, which said actually replace it with a g. Don't use technical jargon, but also it's followed the slash command perfectly to create three variations of LinkedIn posts and then given us a summary down here of the hooks, the angles, and the CTAs. Now we gave an example of writing three LinkedIn posts, but you can literally turn any task that you do on a daily, weekly, monthly basis into one of these slash commands. The importance here is you want to manually invoke or trigger it at certain moments. So it could be generate all posts for this week based on my Notion calendar. This is where skills come in, and skills are slightly different but still represented as these slash commands down here. You can think of skills as an upgraded version of slash commands. They're effectively background knowledge that's loaded in automatically
only when it's relevant. So you don't need to trigger these, although you can tell Claude to use that specific skill. Claude just knows from their project description and their skill description when it needs to use that skill specifically. And unlike commands, which are fairly basic, one single file like LinkedIn post dot m d, skills can include a whole folder of supporting files. So it can have, for example, for our content creation example posts, style guides, brand voice, reference docs. So it gives a richer set of context for which Claude code can actually work from. So skills are effectively repeatable actions with context. And guess what? You don't need to create all the skills yourself. You can actually get those skills from anywhere, and they're, again, gonna sit inside this dot Claude folder. So if I click on the dot Claude folder, create a new folder called skills, they're gonna sit under there with their skill dot m d file for specific skills. So you might have a brand voice folder, and inside that, we'd have a skill dot m d file with supporting files inside that brand voice as well. And we're gonna look for a humanizer skill on skills m p that takes our writing and creates more human like and less AI slop like written context. So we can go down and browse agent skills here, but it's easiest to browse by category. We're gonna go to content and media because we're creating social media content, and we will see very quickly we've got things like the ability to actually create images
using Nano Banana Pro, content creation, technical writers. But what we're gonna type in is human, and, hopefully, there's a humanizer we can grab from here. We'll click inside that, and this one removes signs of AI generated writing from text. Use it when editing or reviewing text to make it sound more natural and human written. This sounds exactly what we're looking for. We're gonna open up the GitHub repository by clicking that button. And what we're gonna do is grab this line here because we've already got our skills folder, and and we're gonna git clone into our own skills here. Now you have a choice. You can git clone it into your global directory using this
squiggly line and slash. Or if I just want to actually see the skill inside this directory, I'm gonna install it without the squiggly line and slash, and it's now gonna clone that repo and add it inside our skills
folder. And we'll be able to see exactly what files make up that humanizer skill. And if we go in the skill dot m d, this is effectively the context for this skill that when Claude code is understanding how to write a post, it's gonna always look, okay. I'm gonna create this in a human like way, and then it will absorb and read all the context only when relevant of this skill dot m d. So it's a way to segregate and isolate that context without bloating our main Claude dot m d file in case the task is not related to actually humanizing text, for example. And it talks about personality and soul, how to add voice, how to add opinions, and gives clear examples in this very comprehensive
file that we didn't need to create for ourselves to create human like writing very quickly. So here's the key thing with a skill. You effectively need a really, really precise
description
for Claude to understand exactly when to use that skill. So here we've got remove signs of AI generated writing from text, use when editing or reviewing text to make it sound more natural and human written. So Claude will understand when we ask for a human like article
to actually then use this skill in its process. And we don't need to say slash humanizer,
but we can do if we wanted to. So we can invoke it manually, but also automatically it will look to do that. But the way we ensure that in the Claude dot m d file instead, every time you write some content, make sure you use the humanizer skill in slash skills slash humanizer. So now it will understand because we've added it both globally and for this specific command that it's gonna use that skill when it tries to make human like writing. Now you could go and export entire libraries of content and media and have, you know, 14,000 skills within your directory, but I prefer to control exactly what skills I'm getting and actually just pull in these specific skills that I'm looking for so I know when I'm invoking certain things and not blending things too much. So you could do things like front end design, SEO review, email drafter, absolutely anything. People have turned into a skill, and you can go through and edit those skills to your requirements too. So we're gonna run our command again, LinkedIn post anti gravity versus claw code, and we should have more naturally written content. And we've not had to do a huge amount of work. We've just installed the skill, and already we should be getting some really good outputs from this. I stopped using AG last month. AG builds things fast. You describe what you want. It writes codes you ship. The problem is what happens six weeks later when something breaks and nobody on your team understands how it works. So this is a lot clearer, a lot less AI slot like. So it's gone through, written the post, humanized them, and then actually even given us a summary of the things that it's changed to make it sound more human. So for example, these tools aren't competitors. They're different answers to different questions.
It's it's actually changed it to the real question is, do you want to outsource your thinking or augment it? So we've got slash commands, which you want to manually invoke for certain tasks. We've got skills, which are automatically invoked based on their description and can have a huge amount of context in them. That brings us to the final part of level three, which are hooks. Now hooks don't require a brain. They don't require any LLM tokens specifically.
They're just automatic triggers, anything that you can do mechanically
that fire off when Claude code does something. And to use it, we're gonna need to create a dot Claude slash settings JSON
inside our project file. We're gonna create a new file, and it's gonna sit within our dot Claude file. And in our example for content creation, we might have a list of banned words that we're gonna check every single content post for, and it's gonna do that automatically. So it doesn't require any thinking at all. It's just check this text against these words. It's very programmatic,
and it's gonna do that every single time invoked after
we've created a LinkedIn post, for example. And therefore, we're not relying on the LLM to actually think through this step. It's just automatically
done. The things that we know should be true, like we're gonna check for banned words. We're gonna check for word count and flag if it's over our limit. We're gonna auto format into a certain specific format. Those things don't require thinking power, so we turn them into hooks. The way that we do that is just copy this into our settings dot JSON. We have this hooks
outer object.
It has a few commands, but to be honest, I never write these myself. I always get Claude to write the JSON object for me to say run this hook after this happens, and it will automatically do that. It can even add it to your settings dot JSON file. And now whenever we write a post, this is gonna run and make sure that no band words that no band words are in our
output variations variations here. And I can just say run the hook for band words on the output drafts to do it retrospectively.
But from now on, if we've got this in our settings dot JSON and we've restarted our instance, it will automatically run it on everything. And it would just appear like this. No band words found in the output draft. So it gives us peace of mind that it's actually running that hook. So the simple way to remember these three things are skills is how Claude thinks. So it's gonna load the skill with its context into its brain while working depending on the description of the skill. So hooks are what happens automatically after Claude code actually acts, And then commands are just stuff that we want to trigger manually
with a prompt that's fed into the context when it runs. Now for every piece of content we write, it's only right that we should have a brand voice skill in there. So I've gone ahead and created a brand voice skill with our band words and phrases. It talks about how I sound, words I never use, platform specific rules, and then we've also fed it a series of examples like best LinkedIn posts, best x posts, etcetera in this example's file. Okay. So we're getting faster at performing actions by leveraging our own slash commands, other people's skills, and running repeatable tests as hooks at the end of actions. Now up until this point, we're still doing everything inside of Claude code. So we're not actually taking actions using our day to day apps like Airtable or Notion. So level four is about connecting to everything using MCP servers. So an MCP server is a model context protocol server, which is effectively just a bridge between Claude code and an external app. So instead of copying data out of Airtable and then pasting it into Claude, say we have our content ideas stored in Airtable, we just get Claude to actually connect to our app automatically
via the MCP server, read our content calendar, and then create
posts based on our ideas in our content calendar. Let's bring it to life by showing you how to set this up with Airtable, and we have this MCP command inside here. And you don't even need to do this anymore. You can just ask for code to set up the Airtable MCP for you, but I'm gonna show you how to actually do this for a specific MCP server. And we can have a ton of MCP servers available, again, to connect to all your different apps at a repo like the one here, which is just a list of literally thousands of services that we can automatically connect to. So we just add it to the project root. We can literally create a new file dot m c p dot json, and we can paste that code in. And it's basically saying, pick up these MCP servers, and then we need to actually insert our Airtable API key, for example. But if you didn't want to do that, we could actually remove this and just use the command slash m c p, which is built in, add Airtable,
and it will start setting up this m c p dot json file for us. And then take in, for example, our Airtable
personal access token, which for Airtable we can get from airtable.com/create/token/new.
Give it a name, Claude Code, and we're gonna give it the scopes of reading records, writing records, and access to actually the bases, the Airtable bases too. So we need to actually give it access to a given base, and we've got one where we have our LinkedIn carousel ideas. So we're gonna create a token for that. We're gonna copy that token, and we're gonna bring it back and effectively feed that into either the dot m c p dot JSON file or just give it to Claude to add that for us. So it's created the dot m c p dot JSON format for us. We're gonna paste in our access token, and it says restart Claude code to confirm the setup. So we're gonna control c control c to shut down the Claude code instance. We're gonna hit Claude again, and we're gonna just test that we actually have that connection set up for our Airtable. So we're just gonna hit what Airtable bases
do I have.
And it should understand that it needs to use the Airtable MCP to actually make that request. And it's gonna return a list of bases that it has access to, which should just be that single, uh, LinkedIn carousel's
base. Would you like me to explore the tables within this base? Yes. Show me the tables.
So we're already reading access
from our tables, but we can also take actions with those tables. And if we open up the table, we've got a bunch of content ideas from mid Jan, and you can see it's pulled out all the different tables
and the key fields inside those tables as well. This looks like a content pipeline for LinkedIn carousels. Ideas flow into draft posts with a brand voice and design templates applied along the way. So it's nailed it from just that MCP
understanding of the fields and the descriptions that understands exactly the content it's looking at. So this is where things get really powerful because if we wanted to combine our content creation system a content pipeline that we're storing in Airtable, for example, we could say,
pull all ideas from after January 20, which was actually just one idea. It should be able to pull that specific record from the Airtable,
which is a transcript of a video
that I created. And what we're gonna do is actually push that into our slash command to create
a post or variations of posts for us. So we're gonna say take this idea, and we're gonna use our slash command slash LinkedIn post. And what it's gonna do is then take the idea, take the transcript of that idea, and turn it into three variations of LinkedIn posts, and we can then demonstrate that we can add it back into our field inside Airtable. So if we're managing our content pipeline in Airtable, we can still actually interact
and do things with Claude code, but actually then put those inputs or the outputs back into our table where we work every day. And that's the power of connecting to the data through an MCP server. So it says it's done the three variations, added them to here. Cool. So update
the record table
with just idea three. In the system message column, everyone's talking about AI coding tools. Most of the demos are underwhelming.
So now
we are giving it permission to actually go through and add that directly into our data where we work every day. So we have our content pipeline being updated
by our ClaudeCode instance, and it's saying it's now updated the record. We can go along, and we can see that it's just added to the system message. Everyone's talking about AI coding tools. Most of the demos are underwhelming. So it can work exactly where we're working, and it's updated that row perfectly. So at level four then, we're taking actions directly in our apps, reading the data, adding things back to the data, updating. It's gone through a full plan and execute loop so far. We're no longer needing to do manual updates in our apps directly,
and it's using the skills that we've given it as well. But so far, we're still having to contribute the majority of the thinking time to this and planning efforts for Claude. But why not leverage a framework like GSD
to plan in high detail and then move us to a supervisor role instead of somebody who's executing these things on a day to day? So GSD is all about removing us from the thinking home overhead, and it's a framework that takes skills
one step further. And what this framework is designed to do is break down huge projects into individual phases
and execute a loop of let's plan the phase first, let's execute the phase second, and let's verify using user acceptance testing methods that the phase has been completed successfully. So this is great for where you've not got a really defined scope and you have a larger project that you want to effectively build out in great detail so that it can be run on your behalf. And when we start planning the project, it's gonna leverage that ask user questions to actually come through and get a full understanding of all of the project scope, all the dependencies,
all of our assumptions, and exactly how we wanna build it out. And it's like planning on steroids. It's gonna break down individual to dos inside individual phases
that are gonna be marked as completed as it goes through and executes on that brief. And the reason that power users use a framework like this is because a huge problem with Claude during long sessions is that we actually fill up the context window. So you can see down here with this bar, we're at 50%
of the maximum context window that Claude code can take. As soon as we get towards 95%,
Claude is gonna automatically compress all that context into summaries, and we're not gonna be able to find it. This is something known as context rock, which is basically as we increase the number of input tokens, our reliability on the output gets less to the point where if we're actually putting in 10,000 tokens or around 7,500
words, we'd lose 50% of the context. Now a framework like GST helps tackle this because it actually keeps context in individual files. So we have overall project documents that are spun up like road map, requirements, and state, but we also have context that's kept in specific
phase level documents
with to do level tasks. And you can see this demonstrated in a previous video that I did that I'll link above where I built out an entire SaaS application,
so a large project using the GSD framework. So it takes planning to the next level. We have a dot planning folder with the project road map, which is gonna tell you exactly what the phases are about. We have foundation and authentication.
We have data management. We have the AI generation pipeline and things like payments.
We have the state, which is a document which tells us actually which plans have been executed and which need to be done. So it's a memory of what progress we've made against the given plan. And then we've got various other high level documents which feed in context at the relevant points and solve that contextual problem. Not to mention each phase is individually broken down into a series of waves
and tasks. So inside, for example, phase five Stripe Billing, we have a plan of what we're gonna do for the first part of Stripe Billing. We have a summary of what's been executed when we run the execute command, and then we also have a user acceptance testing file that runs through and automatically tells us what to test based on our Stripe Billing requirements in the first place. So at level five, we've taken planning to the next level by using the GSD framework, but we're still just supervising one agent whilst we get on with other tasks in the background. So why not instead run a team of agents that can verify each other's work? And that brings us to level six where instead of one Claude doing everything, researching, writing,
reviewing, you just split the jobs into separate sub agents. And, ultimately, we do this to increase our leverage. And it's summarized really well inside this Reddit thread by Saxapil and Kitay. So subagents are specialized personas
that you may want to offload specific types of work to. And, basically, each agent has a fresh context that is then able to be pulled into your main context window that's fed by your claws.md.
So use sub agents to keep your context clean, I e stop that context rot. But also,
it's about context isolation. The sub agent, therefore, is not gonna bloat your main agent's context. So it makes your responses much faster if you're executing it as a sub agent and also cheaper because you're using fewer tokens because you've given it less context or isolated context. And you do this particularly when you're working on a problem that requires a lot of expertise. So break down a bigger project into its components and let agents work on it in either sequence or parallel. So for our content creation system, this might be represented like a content research team. So we might have a researcher sub agent one,
which is in-depth research with access to additional tools that the main ClawCode instance doesn't have access to. We then have our main instance, which is here, which we've been using so far, which is our content writer. And then we might also have a reviewer, a second sub agent that can only suggest edits to things we've already written but not make edits. Now there are two main reasons
that you might run a team. The first is to improve our output quality. So if you think of a specialist versus generalist, we might have one Claude delegating to specialists like a researcher within the same session, and the main Claude agent that we've been using might call the researcher sub agent, receive the research brief back, and then use that research to write because the main instance is the writer. And this would all happen in one terminal window. Or if our main goal is actually to get things done faster and work on multiple nondependent tasks at once, then we might have parallel terminals opening up new terminal windows where we might, for example, have tab one working on writing LinkedIn posts, tab two working on writing Instagram posts, and tab three doing something else as well. So those two never interact, but the value we're getting from those sub agents in parallel is the speed, not that they're able to collaborate and specialize on certain things. And the master of this is Boris himself who runs five chords in parallel in his terminal. You can see the tabs where he switches between the different chords and get system notifications when it needs his input. But he also runs five to 10 chords on Claude dot a I slash code as well in parallel with the local. So he's getting a lot done by running sub agents. But he goes on to mention that he uses actually few sub agents regularly, just stuff that automates some of the most common workflows
that he goes through. So let's set up our agent team here to demonstrate.
So, again, it's gonna sit under dot Claude. Instead of this commands and skills, we're gonna create an agents folder. And inside that folder, we're creating a content researcher dot m d file, which is basically gonna be our agent with a prompt that's basically a research specialist for a social media content team. Now this is just a fairly basic agent and actually could be run as a skill or a command, but it just demonstrates how you would actually use this. And agents would often have a lot more context because they're doing a very specialized task. So we're gonna copy paste that in there. We've got the description. We've got the allowed tools that it's allowed to use, and it's going basically going out to find interesting angles on a given topic. So it's content researching for us. We're then gonna set up our content reviewer. Again, we don't have a specific folder for this, but we're gonna set up just as a dot m d file. And this is all about after it's been created, review the drafted social media post against the brand voice guidelines and platform rules. So we can demonstrate now with a single task how you can get them to work together in one terminal, and then the second task will be working two terminals in parallel. So we're gonna pull an idea from the Airtable content calendar. We're gonna use the content researcher sub agent to research angles
and then use that research to and then invoke the command LinkedIn post on that topic. So you can see how we're building every time on that. And then we're gonna use the content reviewer to review the drafts. And if I wanted multiple ideas to be processed at once, I could open up a new terminal. Whilst that runs in the background, we'd open up a new Claude instance. We can demonstrate
the speed of doing multiple in parallel now. So you've now got two terminals
actually open, and we're executing on both of those terminals. So we need to give this the go ahead on permissions here. And the first one is launching the content researcher.
The second one is starting to actually access the Airtable data as well. So we could launch multiple terminals and have them side by side in this view here to both get higher quality outputs,
but also run them faster. So if we need multiple of the same things doing at once, we can run multiple shells, multiple commands at once. And I can even open up multiple more instances if I have the capacity myself
to actually supervise these. Now if you only have to approve a few things, this is okay. But as soon as you start approving absolutely
every action you take, then you're gonna wanna use what's called clawed dangerously skip permissions, which as it sounds, basically says, I'm not gonna ask for any permission to access any file that you're giving me access to. I'm just gonna go ahead and do it. So if we start Claude with this dash dash dangerously skip permissions, it's gonna start and tell us, do you trust everything in this folder? Am I able to actually go ahead and skip permissions? So we're accepting liability for any actions it's gonna take, and you can see we've got this bypass permissions on here as well. And we could again feed this new instance the same task, and it will run-in parallel to everything we're doing so fast. We've got four three or four windows running in parallel, same sub agent doing the same thing, pulling a content idea, and actually creating new content drafts for us. And now we're really starting to get leverage because we have some drafts. We have some reviews coming in now as well. So we have, for example, this LinkedIn post about hiring somebody for traits instead of a degree. We have one about Stanford's free AI courses, and it's gone out and done the research on those actual courses as well. Whilst we've also got a third terminal running on the same task where it's pulled a topic from the Airtable and is scheduling our weekly content. So this ran for four minutes. This is running for five minutes, and the previous one ran for five minutes as well. So we can condense our potential fifteen minute end to end process
into five minutes and start reviewing those outputs as they come in rather than waiting fifteen minutes for them all to complete. We're able to run them in parallel like that. So now that we've got a team set up and we've got guardrails in place, why not just get it to run the whole show? And we're gonna talk about level seven now, is which what people are doing with fully autonomous pipelines.
So for our content creation system, this is where you set it up, you walk away, and you come back to a week's worth of content already drafted,
reviewed, and ready for your approval. So everything we've seen so far is implemented in what's called a Ralf loop, which is literally just three files. It's a bash script that tells it, do not stop working until you've met this condition. And the condition can either be the max number of iterations to stop us spending too many tokens or a done completion state. So we tell it exactly what done means in our PRD dot JSON file, which is just our product requirements document file, and it continues
to push that context back into a fresh context window for Claude. Every time it thinks it's done a task, it will say, have you completed or have you met the conditions of completion? If not, go again. And to use it, we're literally gonna install the plug in by using the command slash plug in install Ralph Wiggum. But the only thing that we need to create and make sure that we create here is a PRD dot JSON file. So for our weekly content, this would literally look like user stories. So it's a description of exactly the tasks that they need to do and tells the acceptance criteria for which it should assess against. So it'll create its own verification test when it runs the Ralf loop to say, have I met this acceptance criteria
for this user story? If I have, then update that to done or completed,
and then go through, feed it into a new context window to stop the context drop problem with the second task that we're gonna run, and it will see that the status of the first one is now done. So it's updating those statuses but feeding back in the original task, and it will move on to post two, post three, post five, whatever, until it meets that acceptance criteria. So we're just gonna set up a new file, PRD dot JSON, and we're gonna feed these content ideas into our PRD document.
And this is a task that's well scoped,
so it will find it hard to actually go off the rails and do something different. And all we need to do to run this is actually just run the Ralf loop command. So we hit slash Ralf loop, and I always recommend actually running this with max iterations because if you don't, it could potentially run on larger projects indefinitely
and cost you a lot of money in
spent tokens. So always try to run it with max iterations
as well as a completion promise as a safeguard too. So Ralph is very much an executor.
It works brilliantly when all of your tasks are really well defined, clear description, a clear acceptance criteria,
and a clear completion status.
And the content matching process that we've done is a perfect example of this. Like, write a LinkedIn post under 200 words with no banned words in it and write six of them and the these are the topics. So there's literally nothing it needs to figure out. It just needs to do the work. So compared to Ralph, GSD framework, which we saw earlier, is a planner and an executor. So when you need a larger project to be broken down into a really comprehensive plan, we use something like GSD because it helps us with the scoping out. So it might be, for example, I need a content strategy for q two rather than write these specific posts because we need to do the planning first. And if you know all of this, you can build out fully autonomous pipelines
for any business task that you want to do inside ClaudeCode and have it interact with any of your day to day apps. So there you have it. These are the top ways to get the most leverage from Claude Code. If you want to see a full project build using the GSD framework that I showed earlier that uses all of the elements we've talked about today, then check out the next video.