Spec Kit: How to Build Production-Ready Apps with AI Agents
Other VideosFresh📅 2025-10-01
Build Process
┌─────────────────────────────────────────────────────────────────────┐
│ BUILD AI AGENT WORKFLOW │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ PLANNING │
│ ──────── │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Define │───►│ Choose │───►│ Setup │ │
│ │ Scope │ │ Stack │ │ Project │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ DEVELOPMENT │
│ ─────────── │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Build │───►│ Add AI │───►│ Test & │ │
│ │ Features │ │ Logic │ │ Debug │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ DEPLOYMENT │
│ ────────── │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Deploy │───►│ AI Agent │ ◄── LIVE! │
│ │ to Cloud │ │ Running │ │
│ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘Key Components
- Project architecture
- Core features implementation
- Best practices
Transcript
[00:00] All right, so this is not just another VIP coding video. If you actually want to build production ready apps, not just stuff that breaks, then stick around. We've all been there, right? We have an awesome idea for an app, so we write the prompt, throw it at our coding agent, and you're like, "All right, let's go." And then you get the results back, and they're not quite right. Features are missing. There are bugs everywhere. The UX is kind of terrible. And the agent even added stuff you did not ask for. So
[00:31] here's the thing. Coding agents are incredibly powerful, but they need structure. They need the same kind of details that real developers use like edge cases, user stories, architectural decisions, that kind of stuff. And that's exactly where SpecKit comes in. It's this structured workflow from GitHub that gives your agent all the context it needs to build stable and production ready applications. So in this video you'll learn how to use spec kit with any coding agent whether that's
[01:02] claw code cursor windsurf codeex or whatever you use and we'll follow proper development practices too like using git for version control branching testing and a lot more. By the end of this, you'll consistently be able to build quality apps that actually match what you had in mind. So, let's jump into this. But first, what is SpecKit? In short, it's a workflow that executes scripts and very fine-tuned prompts to produce high quality context for your
[01:34] coding agent. And we will go through each of the steps in detail. It basically introduces or reintroduce specd driven development into your workflow. Specdriven development has been around for ages. It's basically how real software development teams figure out what they need to build. So they'll go through an analysis phase. So they'll plan out the changes, break everything up into individual tasks, maybe even split up the work between multiple developers, and finally go and implement
[02:05] and test those changes. And now we're finally seeing this proven methodology being used by coding agents as well. And since everything is documented and planned up front, the agent knows exactly what it needs to do. In fact, if you start a new conversation, the agent can simply pick up from where it left off. Let's have a look at all the core components of this workflow and we will cover each of these in detail when we actually use it in the system. First, we have the constitution step. This is usually set up at the very start of your
[02:35] project. And this is where you set all the project principles and standards. Usually, we'll only set this up once at the start of the project. And we'll only touch this if we ever want to add something to the text stack or change the agents behavior. Then for the main workflow, we have something called the feature life cycle. This is where we'll run all the actions needed to plan and implement our actual feature. And the first action is specify. This is where we tell the agent what we would like to build. This step excludes any technical
[03:07] information. It's purely the business requirements for this feature. After that, we have an optional action called clarify. This is where the agent can look at our requirements and ask any follow-up questions. Now that we have our requirements down, we can go into the planning phase. Now, the planning phase is really cool. This will create a plan, the data models, the service interfaces and even perform research. Then once we have an implementation plan, the next step is to take the plan and break it up
[03:39] into individual tasks. These are all the individual tasks like the actual code changes to implement this feature. Then we have another optional step called analyze. This will simply look at everything that's been produced before it to make sure that the documentation is complete and we've covered everything. Then finally, we have the implement step. This is where we tell the coding agent, hey, we have everything we need. So go ahead and implement all of these tasks. And after that, we should be able to test our changes in the system and ask the agent
[04:11] to make any fixes or any adjustments. But once we're happy, we can go ahead and create a pull request and merge our changes into the main branch. And if we ever wanted to add a new feature, we can simply start this entire process again. And this will create separate specs, separate plans, etc. Enough talk. Let's actually add specit to a project. And let's run through this workflow and all of these steps together. So for this demo, I'm actually going to create a new next.js project. So open up your terminal and run npx create next app at
[04:45] latest. And I'll just add period to install next.js JS in this current folder. I'll just say yes to all of these defaults. And we can verify that our installation is working by running npm or pnpm rundev. Then let's open up this URL. And we should see this next.js boilerplate. Cool. Now let's have a look at adding specit to our project. The first thing I want to point out is that specit is supported by pretty much any coding agent out there. You can see all the agents currently supported on their
[05:16] GitHub page and they're adding support for more agents all the time. But trust me, once you see how this works, you can pretty much use this with any agent out there. For this video though, I'll show you how to use claw code cursor as well as the codec. The easiest way to set up specit is by running this command. But you will need uvx installed on your machine. So to install UV, I'll link to this page in the description. You can simply run this command on either Mac O X, Linux or
[05:46] Windows. So simply copy this command and run it in PowerShell if you are using Windows. Afterwards, we can install SpecKit by copying this command. Then back in our project. I'm just going to open up a new terminal. Let's paste in that command. And what we'll do is remove project and just replace it with a dot. This will install Specit in its current working directory. All right, you should see this screen. So, let's say yes. And now you can select your AI agent. As I mentioned, I'll show you a
[06:17] couple of agents in this video. So, let's install it for Claude. And then for the script type, I'll select PowerShell as I'm using Windows. And that's really it. We get these next steps that says we can run constitution, specify, plan, etc. And we also have those optional commands like clarify and analyze. And if we jump back to our little diagram, it's all of these steps over here. Now, I'm also going to install this for other agents. So, I'll just run the same command again. And
[06:47] this time, let's add cursor. I'll select PowerShell again. And finally, let's run it again. And I'll set this up for codeex like so. Cool. So, what did these commands actually do? Well, in our project, we now have this specify folder and we can see changes to the cursor folder, codeex, and claude. When we expand this specify folder, we get this memory file which contains this constitution. By default, this is just a
[07:19] blank template containing all the main sections for this constitution file. Looking at our diagram, it's this step over here. So we'll run a command that will actually generate the constitution and then populate that file with all of our project principles and standards. Then we also have this scripts file and these are little helper scripts that the agent will use to set up certain things in our project and these scripts are actually fascinating. The agent will use these to do things like create new
[07:49] branches and anything else it needs during this workflow. Then we also have templates and the agent will reference these templates when creating the spec, the plan and the task files for our feature. Depending on which agent you set up for you, it might just be clawed, maybe just codeex, just cursor. But irrespective, these folders look very similar. We get these commands. In fact, if I open up codeex, you will see it looks exactly the same. Just instead of commands, it's called prompts. Or if we
[08:22] open up claude, we get those same commands as well. And each of these commands is simply a detailed list of instructions that the agent will follow during the spec kit workflow. So I think let's finally start going through this workflow. The very first step is to set up our constitution. So back in our editor, we can simply open up our coding agent. Whether that's cursor or claude code or codeex, it really doesn't matter. you will be able to follow along. And since sonnet 4.5 just came
[08:53] out, let's actually start with clawed code. So I'll just go into accept all edits mode and I'm actually going to run the init command. Now this is not part of specit, but it does give claw code context on what technologies are being used in this project and what the folder structure looks like. I'm also going to rename this node to claude code. So now that we have our project set up and we have specit installed, I'm actually going to create our first commit. I'll just call this
[09:24] initial. Let's commit this. And now we can continue with our project. The very first step we need to run is constitution. Technically, this is optional, but I highly recommend running this and it's really easy. In claude code or codeex or whatever agent you're using, the process is exactly the same. So in order to run these commands what you can do is start a new conversation and in cloud code enter front slash then go to constitution and now we can
[09:54] provide the rules and the standards for our project. Since I'm using nextjs I can keep this really simple by saying write clean and modular code and use nex.js15 best practices. Let's run this. All right, the constitution step is done and we can see that in the specify folder under memory, this constitution file was indeed changed. So if we have a look at this, we no longer have the template skeleton. It's been fleshed out with a lot of details like next.js15
[10:27] best practices, rationale, component organization and a lot more. Now, at this stage, I have to mention that this is a human in the loop process. Of course, you can blindly follow these steps and you'll most likely get very good results. But don't be afraid to make changes to these files. If you see something in here that you don't like, go ahead and remove it or add more stuff. So, personally, I'm happy with that file. So, again, I'll create another commit which I'll call
[11:00] constitution. Let's commit this. Before we continue to the next step, let me also show you how to use these commands in other coding agents. For example, if you're using cursor, all you have to do is press front slash and look for the constitution command. And then we can provide all of our rules like update the constitution with nextjs15 best practices. And that's it. It will work exactly the same as claw code. or if you were using something like codeex which we also installed earlier you will
[11:31] notice that if you enter front slash the specit commands are not there. However, we can still use specit simply by opening up the codeex folder and instead of them giving us commands we just get the prompts themselves. So we can just say just like we did earlier something like use next.js 15 best practices. Then all we have to do is grab the command file and add it to the chat. So that's why I said that it really doesn't matter what coding agent you use, whether or
[12:02] not they support slash commands. All you have to do is drag and drop the prompts into the chat and the agent will know exactly what to do. Right? Now that we have the basic project structure set up and we've created all of these files and the constitution, we can move on to building our very first feature, which is effectively the basic app. But before we do that, I personally like to deploy my project to GitHub at this stage. So I'll select publish branch. Then I'll just say create a private repository. And our project is now available on
[12:34] GitHub. Cool. Now I'm going to clear the chat. And we can finally start implementing our very first feature. The first thing we need to do is to run specify. This is where we tell the agent that we want to build a new feature and what that feature is about. And remember, we're not giving any technical information at this stage. It's purely the business requirements. So, back in our coding agent, we can type specify. And now, let's provide the details on the feature that we'd like to build. Like, I would like to build a basic
[13:06] expense tracking app. So, add, view, and delete expenses. Track personal expenses with amount, date, categories, and description. It's a simple dashboard showing recent expenses and basic totals. do not implement user or as this is just a personal tracker for myself. And that's actually it. Let's run this. And yes, this is a very simple app, but I really want to focus on the core concepts of using specit and not spend hours sitting here waiting for an agent to build a massive project. Now, I do
[13:36] want to show you something cool. After sending this prompt, the agent executed this script. And this script actually created a new branch. We can see that we've now moved away from the master branch and we're now on this 001 I would like branch. And I really like this behavior. We're not overwriting everything on the master branch. We are creating a separate branch where we create these changes in isolation. And only once we're happy with the results do we merge it back into the master branch, keeping the master branch clean
[14:06] and stable. Specit also created the specs folder where we can see a new folder matching the branch name. And within this folder, we also have a file called spec. And if we have a look at the spec file, it shows the initial user input. And we've got a lot of valuable stuff in here like the user scenarios and testing, acceptance scenarios, edge cases, functional requirements, and an acceptance checklist. If you're a project manager or ever used in software
[14:38] development, then this will all seem very familiar to you. Right now that we have our spec defined, I'm again going to create a new commit called specify. And I'm going to clear my chat. And the nice thing about this workflow is we don't have to repeat everything we did before. We can simply start a new conversation and the agent will know exactly where it was in the process. The second part of this workflow is clarify. So now that we have our spec file, we can run the clarify command and the
[15:10] agent will now look at that spec file and ask us any clarifying questions. So it says it's analyzed the specification and identified several critical ambiguities. So it's got five questions for us and this is really cool. I highly encourage you to try this yourself and it's really interesting how it's able to identify gaps and ask really good questions. Of course, we can also provide our own option if none of these work for us, but I'm just going to say B and move on to the next question. Then
[15:41] question two, should the system allow negative amounts to represent refunds or returns? That's interesting. I'm going to say A. And for option three, are both descriptions and categories required when adding an expense? And I'll just say A. They have a question four. What does recent expenses mean for the dashboard display? The last 10 expenses, all expenses for the last 30 days, all expenses ever recorded? I'll just say B.
[16:12] Then for the final question, what category should be available for expense clarification? Now, this time it's not giving us any options. So, I'm actually just going to say use your best guess. So, I'm not going to give it this list. I'll simply let the agent decide. And that's it. We can see that the spec file was now updated with all of this new information. And that really is the power of this workflow. It really forces you to think about what you're trying to build. And by asking clarifying
[16:42] questions, it's really fleshing out these requirements. Now that the spec is done, I'm going to create a new commit called clarify. And our agent is actually proposing the next step, which is to run the plan command. Again, I like to keep these conversations lean. So, I'm going to clear the conversation. Then, I'm going to run plan. But here's the thing about the plan step. Now, you could run the plan step by itself. But this is also where you have an opportunity to give the technical details that the agent needs to
[17:13] implement. For instance, for our app, we will not be using authentication and we'll simply use local storage to persist data. You could provide your entire text stack here. like maybe you're using a postgress database with drizzle OM maybe you're using an authentication library like better or maybe you're using something like shaden for the components this is really where you provide all of that information and rules so I'll simply say use nexjs with the app router route handlers and server
[17:44] actions add any backend serverside logic to a server folder in the source folder use local storage to persist data do not implement off. Then let's run this. I am going to jump ahead during these sections as it can take minutes for each of these steps to complete. But here you can see the agent came up with a detailed checklist of everything it needs to do during this planning phase. All right. And now that the planning phase is done, we can see it made a lot of changes to our project. It created
[18:15] this quick start file which is actually really useful. It describes what this feature is about and basically how to use it. So how do you start the app? How do you navigate it? It shows you all the test scenarios and exactly the steps to recreate it. So a lot of very useful info. You of course get this planning document again containing a summary of our feature, the tech stack and things like documentation, the source code structure for the project, all the contracts and a lot lot
[18:48] more. It really plans out all the phases and all the artifacts that make up this project. You can even see things like the data models. So if you were using a database, you would even see the proposed schema in this file as well. We also get things like research and under contracts, we can see all the interface definitions for things like APIs, file uploads, etc. This also updated our agents files. So we can see the claw. ND file and the agents MD file were updated
[19:18] to reflect all the features and the plan as well. So since this step is done, I'm actually going to create a new commit and call it /ash plan. So now that we're done with plan, we can move on to tasks. This will break the plan up into actionable steps. Let's run this and give us some time to cook. Cool. The task step is complete. So we can have a look at its file. Now this is really the crux of the solution. Here we can see the feature will be implemented in phases like phase 3.1 which includes all
[19:52] the setup and foundation. For phase 3.2 we have storage and utility. For phase 3.3 we have contract tests using testdriven development. We have phase 3.4 which includes the server action implementation as well as testdriven development. you have the component layer etc. And each of these tasks have a unique number like T001, T002 all the way down to T30. So if we want we can reference a specific task in the
[20:23] chat by just saying hey go and implement T001 or implement all the features from T001 to T00 as an example. So before we actually run the implement step, I'm just going to commit tasks and let's clear the chat. Now we could leave this blank and agent will simply run through all the tasks from the start to the end. But of course we have to keep context windows in mind as well. The longer the context gets, the worse the output will
[20:54] be. So I actually recommend implementing all of this in small chunks. So you could say implement T001 and maybe we can have a look at where it would make sense. So phase 3.1 actually ends at T005. So we could say implement T 01 to T005 or we can just say implement phase 3.1. Let's run this. And I'm going to fast forward through all of this. But basically, I'm just going to accept any
[21:25] commands and any changes that this agent wants to make. All right. So, the agent implemented everything in phase 3.1 and it also updated this actual tasks file. So, you can see each of these tasks have been marked with an X. So, to clear up the context, I'll run the clear command and let's call the implement command. And let's say please continue with phase 3.2. And while this is generating the code, I do want to show you something. In the source folder, we now have this server
[21:57] folder containing all the services logic. And that is because during the constitution or during the planning phase, we specifically said we wanted all the backend logic to be stored in the server folder. So this is really adhering to all the rules that we set out from the start. And another key feature of spec kit is it really loves testdriven development. So you should see this test folder somewhere in your project. And this is really following the principle of testdriven development where before you build any
[22:27] functionality, you actually build tests that you would run and all of those tests would fail up front and then you start implementing your actual functionality to get the test to pass and then you can start adding polish and exception handling, performance enhancements, etc. Cool. So phase 3.2 is done. I'm going to clear the chat. We can run the implement command again and let's say please implement phase 3.3 and send this. And we can see the agent
[22:58] updated all of the task for phase 3.2. I just like how structured this is. The agent knows exactly what it needs to do. If we close our editor right now and start it in another hour or so, the agent will know exactly where it needs to continue. Let me know down in the comments below which coding agent you use. I'm really a fan of the new Claude Code CLI, but I do tend to use Codeex quite a lot. Let me know what you prefer. Also, if you're enjoying this video, please consider leaving a like and subscribing to my channel. And this
[23:29] is cool. This is what I was referring to earlier where the agent will actually now run those testing scripts to make sure that everything actually fails. Then it will start to implement the actual functionality for our application. And if you're seeing all of this red stuff on the screen, this is totally valid. You can even see the agent saying, "Cool, the tests are failing as expected because we haven't built the actual app yet." And towards the end of the implementation, the agent will run all of these tests again. And that time, they will pass. And that is how the agent will know to sign off this
[24:01] feature. All right, cool. We're done with that phase. And this time, I'm actually just going to say implement as this is a relatively small feature to implement. And on the topic of the new cla code CLI, did you know you can actually see our usage limits as well? So if you go to claw.ai and to settings, so you can see exactly how much usage you have left in the current session. So what we see now is initially it executed those test scripts, right? And the scripts failed because we haven't actually implemented the logic yet. And now we can see all the backend logic of
[24:33] our app being built. So we can see the server action was added as well as client components. And just like that, everything was implemented. Now, this is so cool. The application is ready for manual testing via the quick start guide. You might remember this quick start file that we saw earlier. This shows us all the different test scenarios and the steps that we need to execute to perform this testing. All right, let's have a look. So, we get our personal expense tracker. Let's try to add an amount. We can change the date,
[25:04] select the category. So, let's try to add it. And this works. And if we look at local storage, you can see the expense is being stored in local storage. Let's try to add another like so. And cool, that works. It's also added to entertainment. And of course, we get the totals and the breakdown. Right. So now that this feature is working, what we can do is go ahead and commit this. So I'll say implement. And from my point of view, this feature is
[25:34] complete. So I'm actually going to publish this branch which will push this to GitHub. Then I can go ahead and create a pull request. If you are using the Git CLI, you can actually get the agent to create the pull request for you. But what I'll do is simply go to the GitHub repo, go to pull requests, create new pull request. Then we're going to merge this feature branch into our master branch. Let's create this pull request. And of course, we can give it a title and a proper description. So
[26:04] we could say create the base app. Click on create pull request. And there are no conflicts. So let's click on merge pull request. Let's click on confirm merge. And since the merge was successful, we can now delete this branch. So let's delete it. And that's it. We no longer see that feature branch in this list. And the master branch now contains all of those new changes. Back in our code editor, we can simply switch our branch back to master. And we can run this
[26:35] command to sync all the changes. So this will download all those new changes that we merged into master onto our own machine. And of course if we refresh the app, everything is still working. So what do we do if we want to add more features? Well, thankfully that's super easy. We don't have to execute constitution again and all we have to do is run specify again. So just as an example, let's say we wanted to add some budgeting feature to this. So, we could say, "Please add a budget tracking
[27:08] feature to this app." Now, watch what happens when I run specify again. First off, we can see down here that specit just created a new feature branch. So, we've left master and now we're working in an isolated branch which will only focus on these specific features again. And in the specs folder, we can see a subfolder containing the branch name. And now we can simply run through this entire workflow again and all of the files and artifacts generated by this
[27:39] will be added to this specific folder. And of course after we've tested the change and we're happy, all we have to do is create that pull request and merge it back into main. I'm really impressed by specit and I hope after seeing this video you are too. Definitely give this repo a star as I think these guys are on to something big. Thank you for watching and I'll see you in the next video. Bye-bye.