GSD + Claude Code, Antigravity: This Simple PLUGIN makes your Claude Code & Antigravity 2X BETTER!

Key Takeaways

[music] >> Hi. Welcome to another video. So, today I want to talk about one of the most interesting open source workflows for AI coding that I have seen in a while. And it is called Get Done, or GSD. The name is a bit aggressive, I know, but the repo has been blowing up for a reason. It already has tens of thousands of stars on GitHub, and this is not another flashy AI IDE, and it is not a new model, either. It is basically a workflow system you install on top of tools like Claude Code, CodeX, Gemini CLI, Open Code, Co-pilot, Cursor, and Antigravity. So, your agent can build larger projects without completely losing the plot halfway through. Now, the core problem GSD is trying to solve is something the repo calls context rot. And honestly, if you have used AI coding agents seriously, you already know what that means. You start with a clean prompt. The model is brilliant for the first few turns. Then, the context gets bloated. The answers get shorter. It forgets earlier decisions. It starts changing random things. And by the end, you are baby sitting it more than it is helping you. GSD tries to solve that with a very opinionated spec-driven workflow. And I think that is why so many people are excited about it. So, let's get right into it. First, what actually is GSD? The simplest way to think about it is this. It is a context engineering layer for coding agents. Instead of throwing one giant prompt at Claude Code or CodeX and hoping for the best, GSD gives you a repeatable process. You map the code base, create a project, discuss a phase, plan the phase, execute it in smaller pieces, verify the work, and then ship it. So, rather than one huge, messy session, you get smaller, more focused bursts of work with checkpoints in between, which is pretty amazing, to be honest. And this is also why it feels different from a lot of the other spec-driven tools out there. The author very clearly positions this against what he calls enterprise theater. So, this is not trying to turn your personal side project into Jira with extra steps. It is basically saying the model does better when the work is scoped properly. The research is separated, the plans are atomic, and the verification is explicit. If you have tried tools like SpecKit, Open Spec, BMAD, or Taskmaster, this is in that same family, but with a much more stripped-down solo builder mindset. Now, let's talk about installation, because this is one of the nicer parts. To install it, you basically open your terminal and run NPX get-shit-done-cc@latest. Then, the installer asks which runtime you want, and whether you want it globally or just for the current project. One installer now supports Claude Code, Open Code, Gemini CLI, CodeX, Co-pilot, Cursor, Antigravity, or all of them in one go. It also works on Mac, Windows, and Linux, which is obviously nice. If you're using Claude Code or Gemini CLI, you can verify it with {slash} GSD {colon} help. If you're using CodeX, use {dollar} GSD-help. And one small, but important detail here is that CodeX support is skills first. So, instead of custom prompts, it installs skill folders into your {dot} CodeX directory. I like that a lot, because it fits how CodeX already works, instead of awkwardly forcing a different model. Now, let me walk you through the actual workflow, because this is where GSD really makes its case. The first really smart command is {slash} GSD {colon} map-codebase. And if you already have an existing project, I think this is the right place to start. What it does is spawn parallel agents to analyze your architecture, conventions, stack, and pain points. So, later, when you ask for a new feature, the system already knows how your project is structured. This is huge, because one of the biggest problems with agentic coding is that the model often starts changing code before it truly understands the code base. GSD tries to front-load that understand. But before we get into that, I want to quickly talk about today's sponsor, On Demand. If you've been trying to build AI agents, you know the pain. You find one tool for summarization, another for web scraping, another for data analysis, and then you spend more time stitching them together than actually getting work done. On Demand solves this. On Demand is a platform where you can discover, assemble, and automate AI agents all in one place. They have an agent marketplace with over 400 agentic tools ready to go. So, instead of hunting for tools and figuring out APIs, you just browse, pick what you need, and deploy. That gives you over 1,200 possible agent combinations, which is insane. But the cool part is the playground. You take these agents and assemble them into a workflow for your exact use case. And once it works, you turn it into a full automation using their flow builder. It's visual, no code, and lets you chain multi-agent workflows that run repeatedly without you touching anything. You can also bring your own models, and it's privacy first with secure connectors. Sign up through my link in the description, and you'll get $5 in free credit. Go check it out. After that, you run {slash} GSD {colon} new-project. This kicks off the planning flow. It asks questions, does research, extracts requirements, and creates a roadmap. According to the repo, it generates files like project.md, requirements.md, roadmap.md, state.md, and a planning research folder. So, now you're not just chatting, you are building a persistent project memory before you start letting agents make a ton of implementation decisions. Then comes what I think is one of the most underrated parts of the whole system, and that is {slash} GSD {colon} discuss-phase. This is where the tool tries to surface all the gray areas before planning. So, if you're building a UI, it asks about layout, density, interactions, empty states, and all that. If you are building an API or a CLI, it asks about response format, flags, error handling, and verbosity. So, instead of the model silently making product decisions for you, GSD tries to drag those decisions into the open. A lot of the time, the model is not bad at coding. It is bad at guessing what you meant. So, this step is actually super important. After discussion, you go to {slash} GSD {colon} plan-phase. This is where GSD researches the phase, creates small atomic task plans, and then verifies those plans against the requirements. The repo describes these plans as being small enough to run inside fresh context windows. And that is the whole trick. You're no longer asking the agent to remember an entire product conversation while also implementing task number 12. You are chunking the work, so the agent can focus on one bounded unit at a time. Then, you run {slash} GSD {colon} execute-phase. And this is probably the coolest part for anyone who likes parallel agents. GSD groups plans into waves based on dependencies. Independent plans can run in parallel. Dependent plans wait for the earlier wave to finish. The repo even emphasizes that vertical slices parallelize better than horizontal layers, which is exactly right. If you split work into end-to-end slices, you reduce conflicts, and you keep each agent more grounded in a meaningful outcome. Chef's kiss. Really good stuff. Another very nice touch is that GSD aims to create an atomic git commit for each task. So, when execution is done, you do not just have a pile of mystery changes. You get cleaner history and cleaner rollback points, which is pretty great. Then comes {slash} GSD {colon} verify-work. And I genuinely think more of the tools should copy this. Most AI coding workflows stop once the code compiles or the tests pass, but we all know that is not enough. A feature can pass tests and still be wrong in obvious user-facing ways. So, GSD extracts testable deliverables and walks you through them one by one. Can the user log in? Does the onboarding flow work? Does the dashboard render the right state? If something fails, it can spawn debug agents and create fix plans for re-execution. So, the workflow does not just end at code generation. It actually tries to get you to working software. And if you do not want to manually think about which command comes next every time, there is also {slash} GSD {colon} next, which figures out the next logical step in the workflow for you. That might sound small, but it is actually nice for keeping momentum. Now, let me make this more concrete with a simple example. Let's say I already have a SaaS app, and I want to add billing plus a proper admin dashboard. Normally, if I dump that into a coding agent in one huge prompt, it will probably start fast and then drift. Maybe it adds Stripe, but ignores edge cases-phase one to run them, and finally {slash} GSD {colon} verify-work one to test the actual deliverables. That is a much saner workflow than hoping one giant prompt gets everything right. Now, that is really the whole value proposition here. GSD is a response to raw vibe coding. Instead of hoping one giant chat can handle architecture, edge cases, execution, and verification all at once, it separates discovery from planning, planning from execution, and execution from verification. For bigger projects, that is just a much saner way to work. Now, who is this actually for? I think GSD is for people who already believe AI can do serious coding work, but they are tired of the chaos. It is for solo developers, indie hackers, and power users who want more structure without pretending they work at a 50-person software company. If you are building medium to large features or multi-phase projects, this is a really good option, for sure. But I also want to be honest about the downsides, because there are some. First, this is not magic. The repo literally says something along the lines of, "If you know clearly what you want, this will build it for you." And that first part is important. If you do not know clearly what you want, no amount of workflow is going to save you completely. The plans might be cleaner, the context might be fresher, but vague product thinking still leads to vague output. So, I would not look at GSD as some kind of miracle fix for unclear requirements. Second, for small tasks, this can absolutely be overkill. If you just want to rename a function, fix a small bug, or tweak one component, you probably do not need a whole discuss, plan, execute, verify cycle. In those cases, just ask your coding agent directly. GSD makes the most sense when the task is big enough that context management becomes the main problem. Third, the repo recommends running Claude Code with the {dash}{dash} dangerously-skip-permissions flag for a frictionless workflow. And look, I understand why. Approving every tiny command is extremely annoying, and it does slow the agent down. But I would still be careful here. On a machine you trust, and a project you understand, maybe that is fine. But I would not tell a beginner to blindly enable that everywhere and forget about it. So, take that part with a grain of salt and use some common sense. Fourth, the whole thing is still very terminal first and workflow heavy. If you want to polish GUI with a bunch of visual dashboards and onboarding, this is not that. So, there's definitely a learning curve. And fifth, the tone of the project is very direct. Personally, I think it is refreshing. But if you work in a very buttoned-up enterprise environment, even the name alone might be a hard sell, which is kind of funny, but also true. Now, I do want to mention the cost angle because that is always important. It itself is open source and MIT licensed, which is great, but it does not magically make model costs disappear. If you're using expensive models and spawning parallel agents, you can still burn through tokens and money alike. Codex, Copilot, Cursor and Antigravity, that makes the idea much more valuable. I also think this project is part of a bigger shift we are seeing right now. The raw models keep getting better, yes, but better models alone are not enough. The real advantage increasingly comes from harness design, context engineering, verification loops, and how work gets decomposed. GSD leans heavily into that idea. It basically says the difference between a chaotic agent and a reliable one is not just the model. It is the workflow wrapped around the model, and I think that is exactly right. So, what's my verdict? I think Get Done is one of the most practical open source workflow layers for AI coding that I have seen recently. It is opinionated, but in useful ways. It understands that context management is the real bottleneck for larger agentic projects. It gives you a repeatable spec-driven process without drowning you in enterprise nonsense. And the support for multiple runtimes makes it even more compelling. It is not perfect. It can be overkill for small tasks. The skip permissions recommendation will not be for everybody. And if you hate terminals or structured workflows, you're probably not going to enjoy this. But if you're serious about building larger things with coding agents, I think this is absolutely worth trying. So, this is great for sure. If you want to check it out, the repo is github.com/gsd-build/get-shit-done. Install it with NPX get-shit-done-c c at latest. Pick your runtime and see if this workflow clicks for you. Overall, it's pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, consider donating through the Super Thanks option or becoming a member by clicking the join button. Also, give [music] this video a thumbs up and subscribe to my channel. I'll see you in the next one. Until then, bye. >> [music]