You need to stop using Ralf loops. The Ralf loop hype is everywhere right now, and that's not without good reason. The actual Ralf loop fundamentals
are actually really solid.
Things like context window management, atomic tasks, and persistence until completion
are all things we should be trying to incorporate
into our Cloud Code workflows. But there are a lot of things people aren't telling you about Ralph loops. I'm in danger. First of all, most people aren't even using the correct type of Ralph loops. That Ralph Wiggum plugin you have in Cloud Code? Yeah. That's not a real Ralph loop, and I actually did a whole video on that topic. Secondly, as the creator of the Ralph loop stated himself,
Ralph loops are simply a technique. At its most base form, it's just a bash loop and it's one piece of a larger puzzle
when you are trying to create projects.
And importantly, that piece, the loops is entirely dependent on everything that comes before it. How good is your product requirements document? How tight did you define your features? How do you know what done actually looks like? If the answers to those questions aren't exact and correct,
then you're just gonna get stuck in a garbage in garbage out scenario no matter how many times your loop runs. The RALF loop is an extremely powerful weapon,
but most of us don't need a weapon. We need the entire armory,
and that's where GSD
comes in. While Ralph loops assume you show up to the session with your entire blueprint ready to go, GSD actually helps you build it. GSD takes your half baked idea, asks you deep questions about it, does research on your behalf, fleshes out a full blown PRD,
turns that PRD into atomic tasks for the AI to execute,
and then completes the project from end to end. And while it's executing the code, it's using many of the same fundamentals
that makes the Ralph loops as strong as they are, Namely, context window management using sub agents
and the idea of giving AI as small and discrete of tasks as possible so we always get the best output. So in this video, we're gonna dive into GSD. I'm gonna show you how to set it up. I'm gonna show you what this framework actually buys you. So hopefully, you can give it a test run-in your next Claude code session. So here we are inside of the GSD GitHub repo. What we're gonna do now is we're gonna run through the repo so I can quickly explain big picture how the system works in conjunction with Claude code, and then we'll actually hop in the Claude code and play around with it for real. So first of all, how do we install this thing? Really easy. Just this one line of code in the terminal, m p x get shit done CC.
Next question should be, well, how do I actually interact with this guy? Well, it uses slash commands. So for example, if I wanted to start a new project with GSD, I would just do forward slash GSD new project.
Or if I already had code that I wanted it to work on, I could do something like forward slash GSD,
map code base, and it would take a look at all the code already in there. So that's how you interact with it inside of Cloud Code. Now you're probably asking, okay. How does it actually
execute code? How does it take my idea and create a working application?
Well, Tash, the creative GSD, breaks it down into six steps. Now the first three steps are initialize project,
discuss phase, and then the plan phase. Think of these first three steps as essentially
your standard Claude plan mode on steroids.
So at the beginning, what do you do in the initialized project stage? Well, you just give it your idea. It's gonna ask you questions. It's gonna do research on your behalf. And this is where you're getting your, like,
PRD, right, your product requirements document. What is it you're actually trying to build big picture?
And in this space, it creates four documents that have to do with sort of context. So Claude always knows what you wanna build, what the technical requirements are, and then what has it created and what still needs to be created. And I will show these in action
in a little bit.
After that, you move into the discuss phase and the plan phase. And this is where you go from your general PRD,
and you get really, really detailed with, okay. But what do you actually
want? And this is where you have the ability to go from just sort of your random or your average,
quote, unquote, AI slop and really,
as Tash states it, shape the implementation.
And so you continue to have this back and forth with GSD,
and it continues to do research on your behalf to marry your idea with the technical requirements with what is actually possible.
So as you can see,
there's really half of the steps here are all about just making sure your idea makes sense because the idea a needs to make sense and b needs to get broken down all the way to
a handful of atomic
tasks.
Right? Very, very small discrete tasks that the AI can execute on your behalf.
And it also verifies all this. So it's gonna check the plan against the requirements in loop until they pass. Right? Starting to see some Ralflu fundamentals at work there. And so once we've planned everything out, then we go into the execution phase. Now this is where again we see a lot of Ralph Lew fundamentals because what's gonna be happening here? Well, it's gonna run plans in waves in parallel when possible,
but really what you see is a fresh context per
plan.
Now you should probably understand at this point what context rot is. It's the idea that as a context window fills up, right, the more we interact with clogged code, the worse the outputs get,
and auto compact only solves that so much. So what this does, and what also RalphLoop does, is it starts a new session in the form of a sub agent in GSD's case to actually
execute the code, to create the code. So for
atomic task one, it's gonna spawn a new sub agent. That sub agent's gonna have fresh context to do it so we get the best output possible. And it does this for every single task,
and each task also gets its own commit. From there, it moves on to step five where it's going to test to make sure the code actually works. And oftentimes, it's gonna bring you in, the user, to actually go in and say, hey. Is this working
as expected?
And lastly,
step six, we just repeat this process over and over until we get what we want. And so the GSD loop essentially becomes discuss,
plan, execute,
and verify.
And all along the way, we're bringing in the idea of fresh context windows and very small tasks to make sure the best output is brought to us. Now I suggest hopping in here and taking a look at this GitHub. It talks about a lot of other cool features like quick mode if we're trying to execute something that's small and isn't like a really heavy lift. And then it also goes into, like, all the different slash commands at your disposal. So I'll put a link to that down below. So now let's go through a quick demo. So to install it, you'll spin up a terminal and you'll just do n p x get shit done cc.
Now what you'll wanna do almost every time you use this is to update it after you've installed. So it's the same thing and then it's at latest
because
this guy is kind of a maniac and does like a 100 commits
a day. So he has to proceed.
And then would you like to install this globally or locally? You most likely will wanna install it globally so you can use it in any project.
And there you go.
What what is the new one? You're current to to do.
Yep.
Let's replace it with the new status line. So here we go. Then once you install it, all you're gonna do is start up Claude like you normally would. In my case, I'll be doing the skip permissions. So now we're zoomed in so you can hopefully see this a little bit better. So if I do forward slash,
you will notice I then get, you know, a ton of these GSD things pop up. So let's say we're starting a new project, so it's just going to be GSD
colon
new project.
Hit enter. So it's then gonna start asking you some questions. So what do you wanna build? I just told it I wanna create a content creation remixer.
So I give it some idea or an article, and then it turns it into a thirty to sixty second content script.
Simple enough. Now depending on how thorough your first answer was or as vague it was like our first one, it's gonna continue to ask you more questions to get a better idea of what it actually needs to build. Once you get through the initial project scope questions, you'll be hit with a question that says, how do you wanna work? Whether it's YOLO or interactive. I suggest YOLO is gonna make it way quicker.
And then it's also gonna ask you, hey. How thorough should the planning be?
Standard is just fine. You can always add more plans later if you want to. When it asks you, do you want it to run plans in parallel? Understand, it's only gonna run plans in parallel if that makes sense because certain things do have to be sequential. But for the most part, having it execute in parallel is just gonna save you time. And then in do you wanna commit planning docs to git? Again, this just depends on what sort of version control you want. Now one of the last questions that we'll ask before it actually starts ginning up some of these documents is which AI models do you wanna use for planning agents?
So this kinda depends on your Claude code plan. I suggest quality if you're on a max plan. That way you're using Opus for everything.
But understand there's a balance and a budget if you're on the pro version or if you're really,
um, conscious about bumping up against your limits. Next, what you'll see after answering all those questions is the proposed
road map. So you can see right here, it broke it down into five phases and eight requirements.
So in phase one is the foundation, and this is where we sort of do the full stack skeleton.
From there is the input pipeline with URL scraping and text inputs,
etcetera,
etcetera. Then it gets a little more detailed in terms of how it breaks down those phases, and you can see here it breaks out the success criteria
and the goals. So now I've zoomed out a little bit. And over here on the left, you can see that it's now created those four documents that were referenced in the GitHub repo,
project, requirements, road map, and state. Now the project document is pretty much a product requirements document, right, a pretty broad overview of what it is we're building.
The requirements gets a little bit more technical in terms of, like, the actual features. So for example, if we look at the input requirements,
what sort of inputs do we need to give this content remixer for it to be able to remix said content? So for there, I should be able to paste the URL. I should be able to enter a raw idea, and I also wanna be able to select from template presets.
The road map again is a little more detailed because now we're going into the exact phases. Right? We have this into, I believe, five phases, and it also shows the explicit success criteria.
And then we have the state document, and this is a living document where you can always reference as you're building what has been built so far and what we should expect to be built down the road. Now it transitions into the phase by phase execution. So it's going to discuss the phase, right, really make sure we're on the same page with what is gonna be built here, in this case, in the foundation, And then it's actually going to create the code. So it tells you exactly what to do. So it's going to be forward slash GSD discuss phase one. But first,
right, it's saying, hey. Clear it so we can actually run it. So I'm just gonna go clear,
paste it in,
and it's gonna start executing. After the discuss phase, you move to the plan phase. And this is where it's actually going to set
the tasks AI is gonna complete because everything you've done before this is all about making sure you and the AI are on the same page and that it's gonna build what you want. So it gives you a few options. Either you can do a normal plan phase, in which case, if it makes sense, it will do some additional research,
or you can also just skip the research if it's something very basic. So after it completes that step, we're then going to finally make it to the execution phase of GSD.
So you'll see something that says, like, next up, execute phase one, and then it will give you these commands.
Now what you will also see over here on the left is we now have phases. And in this case, you can see phase zero one foundation.
And over here, have plan o one, o one, and o one zero two. So it's broken down phase one into two sub phases. And if I click into each plan, I can see what it's actually going to do. For all intents and purposes, these plans are like the prompt that it's going to be giving Claude code so we can actually build what we need to build. So if we look through this, it's an XML. It's about 200 lines of code. And you can see right here, what is the objective
of this particular plan? Right? Well, we wanna bootstrap the content remixer project with Next JS 15
and establish a database. Right? We're creating the foundational infrastructure
that all subsequent phases will build upon, and we have a clear output that we're trying to get to. It includes the specific context of other files it needs to be looking at as it executes this phase. And then we can see here in the task section,
the specific atomic task that we keep talking about that it's gonna go ahead and do. Right? We're not just telling it, hey. Create this whole app for us. We're saying, hey. Task one, create the NextJS project with dependencies, and it goes all the way down the list doing it. And I definitely recommend that even if you consider yourself a a quote unquote vibe coder that you go through these plans and sort of familiar familiarize yourself with what it's building and ask Claude code questions if you are confused at any one point.
But at this point of the video, you should start to see, like, how methodical
this entire GSD process is to get us to this point over and over and over. And the next step that we're gonna do, it's actually gonna create the code based on this. But it's a lot of steps before you get to this point, and that's what I am sort of referencing when we compare this to Ralph flute being a weapon and GSD being the whole dang armoring, all this scaffolding to handhold you to get you to this place where it's gonna execute something well. And so we're gonna go to execute phase one.
We'll clear this
and we'll come back once it's complete so you can see what a finished phase looks like.
Okay. So it executed phase one and here's the sort of messaging we see. It says it did wave one and wave two complete. So those were essentially the sub phases within phase one, which was the Bootstrap Next. Js project with the database as well as the OpenAI integration so it can actually in, uh, actually remix our content with AI.
So now it will verify if the goals were met on its own. But what it's also gonna have you do is actual human verification checklist. So it's telling me, open up new terminal,
do NPM run dev, make sure it actually works, do the database migration, and then actually check the OpenAI end to end testing. Now this part I really like, and this is where it differentiates a little bit with the Ralph loop. The Ralph loop is very, like, hands off a AFK. Like, it's gonna just go forth and conquer versus this. After every single phase. There's pretty much some element of human verification.
So you can actually see it with your own two eyes and then make adjustments accordingly.
And this, as I stated before, methodical way
of implementing tasks is where GSD shines. So in terms of end to end stuff, complicated projects, I'm starting from, you know, zero and wanna go all the way to the end. I think this is the perfect place for GSD. I think when you compare that to, again, Ralph loop, which is what we sort of been contrasting with it. Right? Ralph loop is a technique. So there are instances, especially I think if you're a little more advanced and maybe the scaffolding and structuring of something like this framework is a little too much for you, I think that's
where it really, really shines, where you're already at the place where, like, I know exactly what I want, and I know exactly what needs to be done. I think RalphLip is great for that. I think for other cases, and I think for most people in the space, something like GSD just makes a bit more sense. Now there are some cons, right, and something you probably notice right here, like twenty two minutes and eighteen seconds. This is, as I keep saying, methodical.
It takes a little bit of time. We are not in the game of just trying to one shot things as quick as possible.
Also, in terms of sub agents, that does use a bit of tokens. The argument for that is is that in the long run, you're actually saving tokens because you're doing, you know, a plan twice, prompt once thing versus just prompting, going, and then having to fix things on the back end. So just know that going in. So at this point, you would just repeat this process for every single phase until your project was complete. So that's where I'm gonna leave you today. I hope I was able to introduce you to a pretty cool and up and coming Cloud Code framework in GSD. I've really enjoyed it. I think it's perfect for people who don't come from a technical background but still wanna make projects
end to end inside of Cloud Code in a way that's sustainable and repeatable and really checks all the boxes.
So as always, let me know in the comments what you thought,
and I'll see you around.