GStack + GSD + Superpowers Workflow Is Insane! — Transcript

Spec driven development here helps AI here to plan things before doing implementation.

And on this channel, we have reviewed tons of spec driven frameworks.

So, that's why in this video, we're going to take a look at the most popular spec driven frameworks that we have like Superpower, GStack, GSD, and we're going to take a look at how we can piece them all together into a single workflow that we're going to use to building applications with the highest accuracy.

And most importantly, we're going to take this one step further, we're going to introducing the Ralph Loop here to see how we can be able to build this applications completely autonomous, or we're going to have Claude here to using Claude headless, where we can spin up different iterations, and each iteration here can be able to call like Superpower, GStack, GSD, and all the skills, all the MCP servers that we have, and try to having it orchestrator here to loop through until we have the project is fully built.

So, we can do this completely autonomous using the Ralph Loop approach, and also achieve the highest accuracy extract by extracting all the best skills from each frameworks and piece it all together into our own workflows.

So, pretty much that's what we're going to cover in this video.

And if you're interested, let's get into the video.

Now, before we continue, I recently launched our school community.

Where I help you to master AI agents, automations, and so much more.

And that's all coming from someone who used to work as a senior AI software engineer.

At companies like Amazon and Microsoft.

And in this community, you're going to get over 100 plus video materials like templates and workflows that I personally built and sold over 100 plus times.

On top of that, you also going to get access to our weekly live calls.

And just to give you an idea, this week, we're actually running a Claude Code masterclass, where we're going to dive into how to improve Claude Code's accuracy.

We're going to use it to build the applications.

Plus, you're also going to get full community supports, where you're going to get a chance to ask questions and get direct answers back.

So, if you're ready to level up, make sure you drop right in.

And I'll see you in the community.

All right, so in order to understand how we can be able to piece all those workflows together, let's understand what spec driven development does, right?

So, for spec driven development here, it basically help you to or help AI here to plan things before doing executions, and we all know that.

But essentially, this is the workflow that most spec driven here follows, it doesn't matter if it's spec kit, the B map method, or, you know, any other XYZ framework.

It always goes with something like brainstorming, right, helping you to clarify what you're trying to build.

Then it's go down to like planning, right, how exactly we're going to execute this?

Maybe a task list, or maybe breaking this task into different phases.

And each phase has its own task list.

And then eventually it's get down to executions, and eventually here has review, has verifications.

Maybe having using Playwright here to spin up another browser agent here to verify everything, right?

So, you can see that this is the entire spec driven workflows that pretty much most frameworks here follows.

And essentially, how each framework here different is that for Superpower here, like you can see for each one.

What's special about each one is that for Superpower, it's really good at focusing on test driven developments.

Which is something that other workflow doesn't have.

It focusing on writing test first before it do the implementation.

And then for GStack, it's a little different.

It also follow that framework.

But the selling point here for GStack is that it focusing on role-based, which has like different CEO, designers, engineer managers, or maybe security manager here.

Try to iterate with different personalities here, try to help you to decide a best decision for your product.

Right, maybe you're still in the planning phase, or maybe brainstorming phase, it's going to help you to dive deep and try to help you to identify that, right?

And furthermore, we also have GSD.

Which will help us to avoid context rot.

And just to give you a quick TLDR what the context rot means.

If you ever interact with large language model, usually it will start to become pretty accurate at before 50% of the context window.

Right, maybe after you surpass like 50% of the context, it will start to become lower for the accuracy, right?

That's exactly what context rot means, is that the more you talk to the AI in the same context, the lower the accuracy it start to become.

And that's exactly what GSD is trying to solve, is that to make sure that each time when you interact with Claude Code or any other coding agents.

It's going to make sure that you stay under 50% for the context window.

And that's exactly what GSD does.

And you can see that with all the special power listed from each frameworks, we can now be able to take the best out of each frameworks and try to piece it all together into our own spec driven framework that will help you to build applications here much more accurate, right?

So, that's exactly how I would do it to take the best out of all three.

And try to place it into the right workflow, right?

So, you can see that this is the exact workflow that I use, I use GStack here to do better brainstorming for clarify my intent on exactly what I'm trying to build.

Because that's what GStack is really good for.

And I'll basically put this for the spec planning phase.

And then once we have our spec down, once we're using GStack here to clarify our intent, create our spec, then we're using GStack, sorry, GSD here.

To basically taking that spec and break it down into different phases.

And the reason why we do this is like I said, the context rot issue, right?

We don't want to put the entire spec into Claude Code and have it to execute everything.

We want to break it down into different phases.

And each phase will guarantee Claude here is going to stay under 50%.

And that's it.

And this will give us the highest accuracy when we delegate each phase to the Claude headless or Claude session to do the executions, right?

And eventually here you can see after we break it down different phases, we're going to using Superpower here to follow test driven developments here.

To doing the execution for each phase.

And that's exactly how I would do it if we were to, you know, want to have achieved the highest accuracy.

When building applications using this approach, right?

And that's exactly how I would do it.

Now, maybe for some of you guys, this will be like a really overkill, because this is huge, right?

You're, let's say if you're going to, you know, building something from scratch, it's a large applications.

I would definitely highly recommend you go with this approach.

Especially for a greenfield project, not a brownfield project.

If it is a brownfield project, I would highly recommend you to go with this approach.

And you can see here that because this is going to break it down different phases.

And let's say if there's like eight or seven phases, then you have to pass the prompts continuously.

Starting a new sessions to do it all over again, right?

That's going to be really time-taking.

And that's why I built a skill called build loop using the power of Ralph Loop here to basically do this autonomously.

Which means that if I were to, you know, breaking all the phases, like breaking the spec in different phases.

And each phase has its own prompt.

And we can be able to use that and store all those prompts into a single state or single file.

So, for example, we have our build loop here, which will basically triggered, and it's going to look look through our states on exactly what are the phases that have completed.

Then it's going to complete the one that's not completed, and basically by delegating that phase into a headless session.

So, basically, the way how it works here is that we if we were to do Claude hyphen P.

It's going to do this in a Claude headless way.

Which, for example, if I were to interact with Claude Code, I usually do something like this, right?

This will start a Claude session.

And I can be able to start interacting with this approach, right?

Interacting with Claude with this approach.

But if I don't want to do this, I want to have like Claude here to run in a terminal, for example.

I can do the Claude hyphen P.

So, if I were to do the hyphen P.

And I give the exact prompt.

I can still use, for example, if I were to do like one plus one, what is one plus one?

It will basically run in the background.

And it will basically try to execute that prompt, and that's it.

And the good thing about this is that I can still run the main Claude session as this is like the orchestrator.

And the orchestrator here can still running this command, right, inside of the orchestration.

To basically have it to be like this is going to be the running the phase one.

So, if I were to do like Claude hyphen P and just the prompt say like, hey, execute the phase one, it's going to do that.

After it's done, it's going to, you know, respond it just like how we responded for the answer for one plus one.

It's going to give us the answer here, once it will give us the answer here, it's going to do the next command, which is the Claude hyphen P for phase two.

It's going to do this for iteration after iterations.

Until everything's are all complete.

And like I said, the benefits of doing this is that we can have our orchestrator here to basically doing the phase by phase, right, for example, the orchestrator here is going to delegate the task to a background job, try to process phase one, and it's not going to take any context in the main orchestrator.

The only thing that it takes is the headless session.

It's going to run in the background, after it has completed the job in the background, it's going to exit, it's going to give you the outputs for the results for the summary.

And then it's going to split it back into phase two and try to pass it to a new Claude session here in this case in the background session and try to execute, right?

So, you can see that this way approach is going to give us the most highest accuracy because the Claude orchestrator here doesn't take any context for the exact work.

The only thing that it does is to delegate it into sub background job here to do so.

And for each background job here, or each background Claude session here.

It's basically going to, you know, using like Superpower or GStack, try to execute those one by one.

And if you want to take a step deeper on exactly, hey, how is each background session is going to work?

You can see that we have our Superpower here, right?

So, basically, we're using Superpower here for executions, and usually what it does here is that it may go through like planning, dispatching agents.

Following test driven development here and eventually going to do review and verifications, right?

And you can see that for Superpower here, if there's any times where there's like decision being made, what we can do here is that usually it will basically try to trigger back the orchestrator and try to ask those questions.

And what we can do is we can be able to actually delegate this task, right, for let's say if there's any design questions, we can we can delegate this to GStack.

And have GStack here to trigger like different personality here to answer the questions.

For example, if it delegate design patterns, we can trigger the GStack here to basically pass this questions to like different roles.

Like CEO, engineer manager, or designers.

And try to have them to vote on exactly what option they want.

And at the end of it, it's just going to take the most popular votes.

And coming back to the main flow and try to continue on going forward, right?

So, this way, you can see that we're not going to have any manual involvement.

We're just going to have each Claude headless session here to basically try to do the executions.

And have it to make its own decisions along the way.

And that's basically how it works.

So, you can see that for a deeper level, at the bottom level here, GStack is there for making decision if there's any questions.

Superpower here is the backbone for the execution.

And then for the upper level here, you can see we have our orchestrator here that delegate the task to each headless session, right?

And each headless session here has its own fresh context window.

And we're using Ralph Loop here to basically do this iteration after iterations.

And the way how we have these phases here is we use GSD to breaking them into different phases.

And each phase has its own prompt.

It has its own workflow here to basically do the executions.

And eventually here you can see, we're also using GStack here to basically create the spec.

And that's where the these phases here are coming from, which is from the spec, right?

That we have using the GStack here to clarify our intent.

And breaking our requirement here into different phases.

So, that's exactly how this works using the most popular spec driven frameworks.

Taking the best out of all three, and try to piece it all together into our own workflow inside of our app developments with the highest accuracy.

And also try to make this completely autonomous so that it can be able to build it by itself overnight.

And using the power of Ralph Loop to do this completely autonomous.

And finally, just to show you a live demo, here you can see that we have the entire build queue is all completed.

So, I basically spent up a Claude session in this terminal and have it to run build loop overnight.

And you can see that we have one session, which is, you know, the current session that we're in, which is the orchestrator.

And it has complete over 100 sessions in the background.

So, spin up Claude headless and try to complete phase by phase over in the background and try to get everything completed.

And you can see that the overall project here is 16 phases out of 16 is all completed.

And you can see we have the entire build queue here is all empty.

The entire spec is now codified.

And if we were to scroll all the way down.

I asked a simple question, you can see.

But if we scroll all the way down for the context, so for the context window, we only have spent 10% of it.

And that's why we delegate all the tasks into different headless sessions to basically complete the job for us.

And we're keeping all the things that we have in the current session here clean and simple.

And that's exactly how it work.

We take the specials from all the frameworks that we have like test driven developments, different roles for making better decisions, avoiding context rot here from GSD.

And eventually, piece them all all together into a single workflow that we can follow to have a highest accuracy for building applications following spec driven developments.

And eventually, we can be able to make this completely autonomous so that they can be able to build it by itself overnight.

And using the power of Ralph Loop to do this completely autonomous.