[0:00]Hey friends, I am Dan Delimarsky. I'm one of the maintainers for Spec Kit, the new project from GitHub. It's that experiment you've been hearing all about on the YouTubes and the TikToks and the Instagrams and wherever else. But seriously, look at the numbers. Look at this. 16.3,000 stars. I was just celebrating yesterday that we hit 15,000 and it's 16.3,000 already a week after release. This is wild to me. Absolutely wild. Thank you, thank you to all of you who are trying this out, who are experimenting, who are filing issues, opening pull requests, it helps tremendously and boy do we have a lot of stuff in store for you, more around Spec Kit. But actually this is the point of the video. We're going to be talking about Spec Kit today. We're going to be talking and actually looking at how this works. And by the way, like I'm also one of those people that looks at these issues fairly regularly. So if you have any feedback, go and submit, go and submit your feedback right here in GitHub, open an issue. Do not open a pull request that rewrites the entire thing as an MCP server. I know I like MCP, I'm going to reject that request because you haven't talked to anybody about this. So if you have any big changes, make sure you talk about this first in the issue. And what is what is the the issues that I see sometimes are being opened like DRR? What is this? I mean seriously, yeah, do not open issues that just say DRR. give me some context for how we can improve this. But anyway, so Spec Kit, what it is is a toolkit that helps you get started with Spec Driven development. At Microsoft we are very big on Spec Driven development lately and one of the things that we decided to look at is how can we actually simplify the process of you using Spec Driven development to build real software. It's one of those important things that you don't really think about until you actually try it. One of the conversations that I had recently was around vibe coding, right? Like you hear all these people that talk about vibe coding some SAS app and there's a lot of this imprecision happening. You end up in these random rabbit holes where the code is not quite what you want, the implementation is not quite what you want, the design is not quite what you wanted. So Spec Driven development is something that can actually help you get out of that rabbit hole into a little bit more of a scalable solution for your software. So, uh, let's take a look here. It's, uh, again, it's a GitHub repo. It's all open source, it's free. You can take a look at stuff that we have here. And, uh, of course, one of the things that I did recently is push the Specify CLI reference. Spec Kit includes this wonderful thing, which is called Specify CLI. It actually scaffolds things for you. So if you're a developer and you're thinking like, wow, what do I need to get started with Spec Driven development? The CLI is right there. So you there's a reference for it now as well. And, uh, I use UVX and you can install it directly from the GitHub repo because I have not yet published this to, um, the Python package repository. It's coming. I'm working on it. I saw that people already filed issues on this, which is great. But, um, we're going to use it directly from the repo as is. So I'm just going to copy this command with UVX. Shout out to the folks at Astro. Uh, this is fantastic. UVX, I, I use UV and UVX all the freaking time. Um, also, if you do not want to use the CLI, that's totally fine. I understand, you don't want to install things, you don't want to install UVX. Shout out to Astro folks, your product is great. I love UVX. Um, this is not sponsored by them. But if you do not want to do that, you can go to the releases and just download the templates yourself. We support several agents and just today actually, I launched support for cursor. So if you're one of those people that uses cursor, you're in luck. You can use one of the releases here. So we have a bunch of them. Uh there's for example, for copilot, we have them for PowerShell and shell scripts. There's a bunch of them that you will see shortly in our demo. Uh depending on what operating system you're running in. So if you're running on Linux, you might use Bash scripts. If you're running on Windows, you might use PowerShell. No judgment here. Use whatever fits your scenario. But you can download these. We're going to say, grab the zip file for the PowerShell script for our copilot. And we're put it into downloads and we're going to save it here. And let's go and take a look at it. Let's open it. And you'll notice that I have the Specify folder that has some metadata for Specify, things like memory, scripts and templates. And scripts are, of course, PowerShell, because that's what we downloaded. These are helper scripts. We have some prompts in the.GitHub folder that will get to in a second. So you can just grab this, put it in your project. You do not need to use the CLI. I promise you. No installation required. But installation actually makes it much easier. So I do recommend using it. I just copied the command and I'm just going to go to the terminal, zoom it in and we're going to paste it here. And I'm going to bootstrap a new project. Let's see. What is a thing that we want to build today? And let's say I want to build a podcast website. I am big on podcasting. If you have not listened to The Work Item, check it out. But let's say I do not have a podcast website and I want to build one for myself. So, naturally, what I want to do is just bootstrap the Spec Driven development process for that website. I'm going to call it Podsite. And we're going to press enter and wait for Specify to launch. Now, here is where things get interesting. So we have different options. I can choose different agents for which I am bootstrapping these custom commands, custom prompts. Sometimes I use Copilot, sometimes I use Claude Code. I'm not that big on Gemini CLI on cursor, but I know that other people use them. So they're here. You can use them through the Specify CLI. And because it runs in a terminal, you can always just, you know, navigate with your arrows, use your keyboard. Be comfortable with your keyboard. And pick the agent that you want. I'm going to pick Copilot. Now, I'm also picking the type of scripts that I'm going to be using for my helper system, right? Because when we're running a bunch of these prompts, what they're also going to do is they're going to run a bunch of scripts that are going to bootstrap things like Git branches. And make sure that the JSON content that we use to kind of link metadata is the same. And for that, the easiest way to do this is with scripts because they're deterministic. You don't actually have to rely on the LLM, the large language model to go in and figure out how to piece things together. Things just work. So, it defaults smartly to the operating system that you're running in. In this case, I have PowerShell selected because I'm running this on a Windows terminal. It's Windows PowerShell, right? But if I so desire, I can switch to shell scripts. If you're running WSL2 or maybe you have an Ubuntu VM or a Fedora VM, you can use that there as well. And by the way, this just launched today. It's hot off the press. You can actually now support PowerShell. You don't need WSL2 on Windows to run this, you can just run it native Windows. I'm going to select PowerShell, right? Because that's that's what we want. We want to run this on Windows as is. PowerShell it is. And we'll see some status changes. This is basically the Specify CLI going and downloading a bunch of stuff and extracting the templates locally. As I mentioned before, like this is just a convenience layer. Like this is not something that you have to do. You can just download the zip yourself from the release for the agent and the shell script type that you want and extract it and put it in your project. Just as easy. So, now you'll notice that there are some instructions here for me. I can navigate to the folder. I can open in Visual Studio Code and use some slash commands. They're Specify, plan and tasks. These are going to help me to actually bootstrap my project. And I can update the constitution file. The constitution file is actually something that you probably have not heard about before because it's relatively new. The the the idea of the constitution is that it establishes a set of non-negotiable principles for your project. So if you have things like I always have to have tests, I always got to make sure that I'm running Next.js of a specific version. You encode that in the constitution. That's where the stuff goes. So this is where the constitution comes in and it becomes super, super helpful for any of your projects. Uh now, we're going to jump back here to our terminal and I'm going to launch VS Code because I'm going to be iterating on this project inside VS Code of course. And we'll notice that the Podsite here, and this is because I opened the wrong folder. And this is how I know. Notice that I have Podsite here and these are the GitHub folders. But if I go into agent mode and VS Code here. And if you see, if you start typing in slash Specify, oh, I can't type. slash Specify. Right? And you will not see the command there. That means you're in the wrong folder. You are one level too high up from where you need to be. To do this, we're going to close VS, go back to the terminal and we'll go to CD Podsite. That's why I put this instruction here in green that we you will see here in the terminal. It's called CD Podsite. Go to the folder to be able to use these commands. So we're going to go there. Right? And now we're going to launch code from here. Fantastic. Now we're in VS Code. Now we see the GitHub folder and Podsite is at the root, which is fantastic. That's exactly what I wanted. And now I see that there is the GitHub folder with a bunch of prompts. These are going to be our slash commands. And slash commands in VS Code is nothing other than custom prompts. That's that's all it is. It, if you look at any of them, it basically outlines a set of instructions for the LLM to follow to establish specific conventions around what we're building. So in our case, it requires running a specific script. We see some instructions for things to do, use absolute paths. It's nice. Same for Specify, same for tasks. And again, we'll see the purpose of these commands just just in a second here. And also have the dot Specify folder. Again, shout out to the community members who suggested this because before, if you have like memory and a bunch of these helper scripts and the templates, they would just land directly in the repository route, which is not super helpful if you already have a project. So, these simplified things a little bit. So you can just keep them inside this dot Specify folder. And if you so desire, you can even get ignore it, which I don't know why you would do that. But you can. So, now that we have these baseline pieces here, let's go ahead and use our slash commands. I'm going to maximize the chat box here. And I'm going to use GPT5, but you can also use different models. You can actually experiment with different models that exist in Copilot or any of the agents that you're using to see what output is better for the things that you're building. The output will vary. So, uh, for example, I like GPT5 and Claude Sonnet4 personally, but depending on what you're building and the scope of things that you're building, you might want to customize that. And as I mentioned, there's this constitution document. If you go to memory and there's constitution, right now it's just a blank template. But what we can do is establish this constitution with the help of the LLM. So I'm just going to do that. Uh, and we're going to ask the LLM to go in and fill this out for us. So, fill the constitution with the bare minimum requirements for a static web app based on the template.
[11:51]The constitution, if you also look at this, these principles and examples, it's all about making it easy for the LLM to go and fill this out for you. This can bootstrap it. It doesn't mean that you cannot do this manually. It's more of this bootstraps it for you and saves you some time. So, we're going to press enter here. Bare minimum requirements. And we'll see what it comes up. We're going to use GPT5. GPT5 is good, like for these kind of things. If you use things like Sonnet, I see it golf the rails sometimes and it does a bunch of stuff and it starts editing the constitution file and it starts creating more files that it's going to refer to. That's not what we want to do here. So, I'm just going to rely on the constitution. It's it's fine. And it's going to look at the existing content and existing template and I hope that it's going to fill this out in the way that I want to because if I'm going to be writing this out manually here, it's going to take us half an hour of this video and nobody wants to watch me type. So we're going to give it another second here. Um I've also noticed that GPT5 sometimes can take a little bit longer than Sonnet. So Sonnet in the context of Copilot is just going to start iterating on this and just kind of you will see the changes go gradually into the files. GPT5 is a little bit more, uh, I want to say, thoughtful where it's going to start thinking and thinking and thinking and then just spit out the whole thing for you, which again, can be nice, can be not so nice depending on the scenario you're trying to tackle. So, uh, pick your battles on the models you want to use and try them out. The only way to find out what produces the best results here is through experimentation. Just like Spec Kit. Spec Kit, Spec Driven development stuff that we're shipping here is an experiment. We are here to learn. I just want to remind you that this is not a production scenario. Like there's a lot for us to learn. We want your feedback. We want your input. So if something breaks, if something doesn't work, if something that it produces is garbage, let us know. I want to see that garbage. I want to understand what worked and what did not work because that will help us make it better. And by proxy, improve the product for everyone else that might be running in similar situations as you. So, uh, hopefully this is a great intro for you to see like how Spec Driven development works, what are the artifacts and how it produces them.
[39:26]And how you can then tweak them. I really, really hope that you go to Spec Kit, you try it out. You get it running on your box. You see what works and what doesn't, especially when you start compounding many, many different features and bug fixes and all these things for your projects. Let me know. Go to GitHub.com/github/spec-kit. Download it, use it, tell me what's wrong and then I will see you in the next video where we're going to talk about more complex things that are also being accomplished with the help of Spec Driven development. I hope you enjoyed this. I'll see you in the next one.
