The ONLY guide you'll need for GitHub Spec Kit Transcript, AI Summary & Key Points

00:00 Hey friends, I am Dan Delamarski. I'm one of the maintainers for SpecKit, the new project from GitHub. It's that experiment that you've been hearing all about on the YouTubes and the Tik Toks and the Instagrams and wherever else. But seriously, look at the numbers. Look at this. 16.3,000 stars. I I was just celebrating yesterday that we hit 15,000 and it's 16.3,000 already a week after release.

00:28 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 specit. But actually, that's the point of the video. We're going to be talking about specit today.

00:48 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. Uh do not open a pull request that rewrites the entire thing as an MCP server. I know I like MCP.

01:11 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 open like Dr. D? What is this? I mean serious. Yeah, do not do not open issues. They just say DR like give me give me some context for how we can improve this.

01:33 But anyway, so specit what it is is a toolkit that helps you get started with specri development. At Microsoft, we are very big on spectrum development lately. And one of the things that we decided to look at is how can we actually simplify the process of you using spectrum development to build real software. It's one of those important things that you don't really think about until you actually try it.

02:00 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 wanted. The implementation is not quite what you wanted. The design is not quite what you wanted.

02:18 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 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.

02:44 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 Spectrum Development? 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.

03:05 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 Astral. Uh this is fantastic. UVX. I I use UV and UVX all all the freaking time. Um, also if you do not want to use a CLI, that's totally fine.

03:28 I understand you don't want to install things. You don't want to install UVX. Shout out to Astral 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.

03:48 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 copiloud, 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.

04:07 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 uh our copilot and 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.

04:34 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 we'll get to in a second. So, you can just grab this, put it in your project. You do not need to use a CLI. I promise you, no installation required. But installation actually makes it much easier. So I do recommend using it.

04:55 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 at 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.

05:18 So naturally what I want to do is just bootstrap the spectrum process for the website. I'm going to call it pod site 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 cloud code.

05:42 I'm not that big on Gemini CLI and 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?

06:09 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 get branches and make sure that the uh 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 it's deterministic.

06:28 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.

06:48 If you're running WSL 2 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 WSL 2 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.

07:06 We want to run this on Windows as is. PowerShell it is. And we'll see some status changes. This is basically the specified 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 in your project.

07:32 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. There are 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.

07:57 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 Nex.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.

08:20 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 /specify oh I can't type slsp specify right and you will not see the command there that means you're in the

08:58 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 pod site that's why I put this instruction here in green that you will see here in the terminal. It's called cd podside. Go to the folder to be able to use these commands. So, we're going to go there, right?

09:22 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.

09:44 That's that's all it is. It if you look at any of them, it basically outlines a set of instructions for the LM to follow to establish specific uh 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 we again we'll see the purpose of these commands just just in a second here.

10:08 and also have the 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 simplify things a little bit. So, you can just keep them inside this specify folder.

10:29 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. I'm going to use GPD5, 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.

10:57 The output will vary. So uh for example I like GPD5 and cloud sonnet 4 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 so if you go to memory and there's constitution right now is just a blank template but what we can do is establish this constitution with the help of the LLM.

11:20 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 a template because we want to follow the template. 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.

11:58 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 GPD5. I GBD5 is good like for these kind of things. If you use things like sonnet, I see it go off the rail sometimes and it does a bunch of stuff and it starts editing the constitution file and then it starts creating more files it's going to refer to.

12:23 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.

12:45 So we're going to give it another second here. Um I've also noticed that GP5 sometimes can take a little bit longer than sonnet. So sonnet this in the context of copout is just going to start iterating on this and just kind of you will see the changes go gradually into the files. GPD5 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

13:12 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, the spectrum 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.

13:34 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.

13:54 So it looks like GBD5 is still thinking. It's going to update the constitution file by updating by replacing the placeholders with concrete static site requirements. So, we're going to wait for it to finish this process >> a few moments later. >> All right, looks like it finished. So, I'm just going to keep the changes here and let's take a look at what it actually said.

14:16 You know, no static first delivery, no serverside execution. The site ships HTML, CSS,JS, and static assets via CDN. That makes sense. Simplicity over tooling. Prefer vanilla HTML, CSS,JS. I like that. I think that makes sense. Accessibility and SEO baseline also makes sense. Performance budget, you know, I I I I don't necessarily care for these things as we are prototyping right now.

14:42 For production scenarios, you absolutely should care about performance security for now. I just do not want to deal with that. Um, also things like requirements here, development workflow, quality gates. Um, yeah, this makes sense, but I think like again for for what we're trying to do right now, this a little bit a little bit too much. So, we're just going to remove these pieces.

15:04 And I think a lot of the the three principles, the three articles of our constitution make sense. Static first delivery, simplicity over tooling, and accessibility, and SEO baseline, which is good, right? So, now now we have a constitution. Um, now I can use the specify command that I talked about to define the baseline specification. So let's do that.

15:25 Let's use slashsp specify. And again, because I'm in the right folder now, I see slpspecify slash specify. And this is where I define like a true product manager the what and the why. We're not focusing on a technical requirements. We're not focusing on saying use Nex.js and this database and so on so forth. Like we we don't care about that at this point.

15:45 This is all about making sure that we are outlining the motivation for the product and what actually needs to be built. This is helpful because for somebody reading this, it is going to be completely detached from the implementation. This is important. The benefit of the spec here is that it is completely detached from the implementation. So if at some point, you know, we're going to be building this with Nex.js, but at some point you switch to Hugo or any other static side generator.

16:11 You use the same spec. The spec is written, the requirements are there. You just toss it into an LLM and ask it to write you three, four, five, six variants based on the same spec. So kind of neat. a side effect of what what this is about. So, we're going to go back here and use specify and this is where I'm going to say what my requirements are. So, I am building a modern podcast website to look sleek.

16:40 We want to use the term sleek. I I think the youths use this term these days, sleek. I wanted to be sleek. I um something that would stand out should have a landing page with one featured episode. There should be an episodes page, an about page, and a let's see an FAQ page. uh should have 20 episodes and the data is mocked. You do not need to pull anything from any real feed, right?

17:31 So, we're we're just establishing the requirements. We're detaching ourselves from the technical details. We're not thinking about any technical details. We're just saying like this is what you're building. So, I think this is good enough for me to start. Again, for a real production scenario, the more detailed the prompt, the better for us because we're looking at this very baseline context.

17:49 Uh, we're just going to use this and I'm going to use specify. And what's going to happen here is it's actually going to go ahead and use our prompt file, right? Like this is going to use file instructions and specify prompt MD because that's the prompt file that drives the slash command, right? It's going to read the script that is referenced there.

18:11 It's very important. It's going to read the spec template that is going to be used as a baseline because look, there's a templates folder. And it's going to ask us if it wants to run this PowerShell script. And uh yeah, let's actually enable auto approve yolo mode for the rescue. And because I'm running this inside a VM, I'm not really worried about this.

18:29 I'll just say allow run this command. It's going to run a PowerShell script, a helper script. Great. It switched to a new branch because, as I mentioned, this is git based. So as you're running this in your project is going to be using these custom branches to help you organize your work. That way you're not damaging anything in production and you can always roll back changes that you do not like.

18:51 Again side effect of the spectrum process the fact that it forces you to think about a lot of these things where as you're experimenting and as you're iterating you not want to interfere with the existing implementation. Right? So the spec establishes the baseline. You work through it, you experiment, and then you merge it into your main branch on an as needed basis.

19:12 So, looks like it's reading some of the information from the spec file that it helpfully created in the specs folder. Uh, the file right now is empty because it has not yet inserted the template, but we'll see GPT5 soon plug in all the required information, which is going to be nice. Wonderful. We now have a specification. I'm going to keep it because I just trust it that much.

19:42 I I really don't don't don't trust the LLM to do production software for you. Just check it. You have to verify it. Check the software statement that is being made in the spec. So, uh we're going to look at the spec here. It created things for a modern podcast website. Great. That's that's what I asked it to do. Um let's take a look here at quick guidelines which is you know again it is the guideline for the spec.

20:09 We have to respect them. The LLM has to respect them. Focus on what users need and why. Great. Um for AI generation all the stuff that's again helpful baselines that we need to maintain and respect. So user scenarios and testing. All right. There's some user stories and this if you're a PM this will sound mighty familiar. We have some acceptance scenarios.

20:31 We have some edge cases, right? Like it accounted for things like epsert ordering not specified and so on so forth. There's also a bunch of functional requirements that are also if you're a PM, you know, functional requirements, they go into the spec. This is, you know, it's done for you. Um, there's a bunch of things that are here, but also notice that there's a review and acceptance checklist.

20:52 This is key here. I cannot emphasize this enough. If you are having a specification, if you're writing a spec, you got to make sure that you have an acceptance checklist and you got to make sure that the acceptance checklist is actually filled out. So things like no implementation details, right? Like languages, frames, APIs because that's not what we're focusing on.

21:12 We are focusing on the what and the why, not on the how. Uh I also have details about, you know, nontechnical stakeholders, mandatory sections completed. One thing that is not checked is no needs clarification. And that is actually something that is missing here right now because if you look at there's items that needs clarification like episode list ordering should be reverse chronological newest first confirm order requirement.

21:36 Now because we're prototyping and because we're experimenting with this I can ask the LLM to take a best guess. So we're just going to do that for things that need clarification. Use the best guess you think is reasonable. Update acceptance checklist after. And we're going to have the LM basically fill this out for us because I do not want you to think about this prototype.

22:12 I just wanted to kind of vibe code, I guess, but it's not really vibe coding because I I am structuring this a little bit better than just vibe coding. So once the spec is established, mind you this is very easy to share with your team. So if somebody comes in and says how did you build this website, look at the spec, look at the rationale. You as a human in the loop can go in and edit this.

22:33 People make the mistake of thinking that oh the LM produced this. I can only manage this with ALM. No, it's a markdown file. Go in with your hands and start typing and entering requirements that you feel are, you know, required for your product. So if you feel strongly that the landing page should have a logo centered at the very very middle and some gradient that looks like a rainbow, you absolutely can do just go and add another functional requirement that you can do this manually.

23:03 You don't need to ask the LM to do this. Um again and this is especially important if you're running into you know enterprise environments or environments where it's more controlled where you need to actually add specific requirements. Sometimes the LLM cannot guess for you which it's fine. you know, manual work is still there and we as developers need to go in and do that from time to time.

23:21 So, we're just going to wait for GBD5 here to think a little bit and fill out our clarification items. We now have the updated checklist. uh allegedly. So let's scroll back here. So all right, looks like we're good. No needs clarification anywhere in the code, which is our spec. It's not actually code. It's a markdown file. We're going to look here.

23:57 It looks great. I think we're ready to go to the next step. The next step is we're going to be using the slash plan command. And this is where we actually specify the technical requirements. So I'm going to use next.js JS with static site configuration. No databases and what to make sure that the site is responsive and ready for mobile because 2025 we still have mobile phones.

24:39 we need them. So this is good. It gives us a baseline for what to think about. So we're going to use again the plan prompt. It's going to run some helper scripts as well. So we do need access to the terminal here in VS Code or whatever agent you're using. If you're using cloud code, we're just going to use cloud code because cloud code is very good about running things directly in your terminal.

24:57 So it's also going to bootstrap some additional content here that we'll see shortly in the repository. things like the plan, the contract and notice most importantly that it does consult the constitution like there is then read the spec constitution and plan template. So constitution is in play the the the set of non-negotiable things that we talked about earlier is still in play very important.

25:20 So, we're going to run the script. We're going to allow it. YOLO. Not quite yolo because I still had to approve it for some reason. But, um, we see the JSON here, which is the output of the script because if it's JSON, it's very easy for the LM to parse and understand it. Notice that it read the constitution because these are non-negotiable principles.

25:37 We got to respect them no matter what you're doing. So you have this plan step that's going to read it and then it's going to go ahead and fill out the actual plan and a bunch of additional metadata around it that's going to help us establish a good project baseline. Notice that because all the stuff also lives in a dedicated folder. So 001 I am building because it just picks up from your prompt and it generates a name for the for the feature.

26:02 All the stuff is grouped here. So later on if you decide to rebuild the entire feature like you see what it built and you're like you know what set 5 or sorry set 4 did not quite do the thing that it expected to do. I want to switch to GPT5 or I want to switch to uh maybe GPT41 and try out how this works for maybe Gemini Flash. You essentially have the spec.

26:25 You have all your artifacts. You can just delete the source. The spec is still there and then use a different model. So you use the model switcher here in the chat and just reimplement it. That's that's it. You can just rebuild it. You can add additional requirements. If you see that the logo is generated the wrong way or it's kind of the the layout of the page is funky.

26:45 There's no header and footer. Go and edit the spec and just rebuild the source. Once the source is created, of course, you can iterate on it differently. Like you can add another spec for another feature, for another component. you the the one spec that we have here in this what we refer to as green field project because we're creating a new thing is just that is just the bootstrap of the project.

27:06 You can do this exact same thing for any other features. If you want to add support for a Spotify player for example in your podcast page just use specify to essentially create a new feature right like that's kind of it. you use plan to go and create another set of technical details for that feature because that's what it's going to do. It's going to create new subfolders that you can then iterate on.

27:30 So here we're going to wait a little bit for GPD5 to go and think through. But notice that it actually started thinking about things like contracts because it's going to look at data contracts that exist within the pages. But uh I'm not going to disturb it. I'm going to let it think and do its job. And we're going to get back here once we see the actual outcome of the process.

27:54 >> No. God, no. God, please. No. No. No. No. >> All right. We now have the plan. The plan is good. We can take a look here. We see plan. I'm going to keep all of the changes. It created a bunch of other metadata here. So we can scroll through the plan. We can minimize the terminal just a little bit. We see that it has an execution flow for the plan.

28:21 Great. Uh technical context, language version, JavaScript, TypeScript, and Node.js. Great. Primary dependencies, Nex.js, static expert, SSG, right? Because we asked for a static site. It's great. It thinks about that. Testing Lighthouse and some other libraries. Target platform static hosting over CDN versify GitHub pages. Azure static web apps. That's that is right.

28:44 I actually made some good assumptions. I did not specify this. Uh keep in mind that if I wanted for example to host things on say Cloudflare or Azure, I can specify that in the constitution. I can say that everything that you do has to be oriented for Cloudflare or Azure or anything any any other provider whatever you want uh or any other technical requirements by the way.

29:06 So um we have the project types some constitution checks and there's a gate that again it must pass the constitutional check it must pass the requirements that we have established for things like use framework single data model avoiding patterns yep architecture static first dependencies minimal yep makes sense makes sense there's some outline for outline and research all right some research artifacts created and by the way copilot in this case did not do the actual research it used its training data to come up with

29:37 this research.mmd file. Other agents like copilot, sorry, like quad code can actually go and do research. So this you you'd get the the freshest information from the internet. Um but it actually made some pretty good assumptions here. So we have the context, we have some of the outline on the phases. Uh and now look, we're missing the task generated.

29:58 We're going to run the task command now. Uh but before we do that, let's take a look here. So there is a research file like I mentioned. So it looked through its training data because all this is generated by the LLM basically, right? Like it's all whatever is embedded in the training data. That's what it's used for its inspiration instead of actually going out into the web.

30:15 Uh we can use something like the beast mode from our good friend Burke Holland uh to force it to do certain things, but I just use standard agent mode here because I did not use custom modes now which which is fine for our prototype. It's okay. So we have this. We have some data model outline for you know fields for an episode which is again great. It has the context.

30:36 We're building a podcast website some details about the site some validation rules derived views. Um we still have our spec. We have our quick start that gives some idea of what the site is about and the prerequisites that are required for the site to actually run. Again super super nice to have this in one place. the spec and all the artifacts become that piece of executable context that you can pass to your team and have them work on it.

31:02 But uh we have the plan u now as the plan says we got to jump to our task. So we can use tasks and say break this down. Right? So once again, it's going to run some helper scripts that are going to guide it through and it's going to break the work down into manageable chunks that the agent can tackle one by one because that is super nice. That is kind of the ability of seeing exactly what it needs to do instead of it assuming that it needs to partake in certain actions.

31:39 Right? So if I want to build the testdriven developmentbased approach where I want to have tests first, all that stuff, you know, can be broken down into individual tasks. It's going to do that first. It's going to make sure the tests are passing and then jump to implementation of the data model and so on so forth. So uh we're going to uh have it do some more work here.

32:00 Going to check task prerequisites. All right. So it's going to use a test template. Going to set things up for us. And we're going to get another tasks.md file, another markdown file in our folder that we can use to actually browse through the task. Right now, because it's all marked down, it's all available to you as a developer. You can use the LLM here in this chat view and just guide it through all the things that you need.

32:24 Or you can just go into the markdown and start tinkering with it because it's so easily editable. It doesn't need a proprietary editor of any kind. You can just open this and you know anywhere else where you've integrated copilot you know it doesn't actually need to be VS code I just happen to use VS code right um and again specit and specify are compatible with many other agents and more agents are coming like I'm working right now on open AI codeex uh QN uh we're looking at adding that as well uh open code root code

32:53 like all those wonderful wonderful projects from the community are going to be coming in so uh again I'm going to let chat uh or GPD5 five in this case. Think a little bit and create our task list. Look at that. We have our task file. So, if I go here again, we're going to keep all the changes as is. And we see a bunch of t Let's Let's actually reduce the size here, right?

33:20 So, you can actually see a little bit. We're going to reduce the size of this as well. Um, and we see the the the sections here, right? like it it just chunk this into individual phases. We have setup initialize next.js app skeleton. Yep. Yep. That sounds good. Test first must fail before 33. All right. Yeah, because we do want to use test-driven development here.

33:42 Uh, okay, that sounds good. Core implementation only after tests are failing, right? Because we're setting up the test first. Makes sense. About page, so on so forth. Integration refinement, run lighthouse. And this is where I can, you know, you can you can tweak, you can remove things you don't like. You know, do you want to run Lighthouse on a prototype?

34:01 Maybe, maybe not. Uh, and of course, polish, responsive images, documentation, all good. Accessibility polish. Sounds good. I think we're ready. I think we're good to implement this. So, I'm just going to go ahead and switch my model to Cloud Sonnet 4 because I like this the most for code. GBD5 is good at setting up the the kind of the spec scaffolding for us, but for creative output, Sonnet 4 is still unbeatable to me.

34:27 So, I'm just going to say this and say implement the tasks for this project and update the task list as you go. And now we're going to let the agent run wild and go and implement our website. [Music] [Applause] Heat. [Music] Heat. [Music] Heat. Heat. [Music] Thank you. [Music] [Music] Tada. Looks like it did it. It It finished the work. It did the things that it was supposed to do.

36:31 Now, I have not seen the output. This is going to be a surprise. So, let's keep all the changes. Let's make sure that we keep it. It updated all the tasks. It failed on some Lighthouse test, but that is because I don't have Chrome installed. But we can actually run npm uh I like to run num npm run build. Let's build our static site and then we're going to run npm npm rundev to actually see it in action once it actually builds.

37:04 So we'll see we'll see what it looks like. All right. Selecting build traces being the most timeconuming thing apparently. All right. And then npm run dev. Okay. Localhost 3000. See, let's see what our podcast site looks like. It's loading. This can be horribly bad. But actually, like look, it's it's not bad. it, you know, master the art of podcasting.

37:40 Featured episode looking good. Has all the details. Pod side. I have my about page. If I go here, there's a nice description. All right. FAQ. Okay. Yeah, there's there's an FAQ. All right. Great. Episodes. Let's take a look here. We have individual podcast episodes with links to the podcast platform. And keep in mind that in this context, what I can also do is if I plug in MCP tools like Figma MCP, I can link to actual design.

38:13 So I can actually get it to build things that fit the design system of my organization. So I don't have to randomly assume that it's going to build the right thing. So this is kind of nice. Like it did create all this stuff. Now you might actually ask yourselves like, well, is is this really better than vibe coding? Like I could have vibe coded this entire pod side, right?

38:33 But the thing is is that now that I have the spec, now that I have the artifacts here in my spec implementation, I can easily customize it. I can now tweak it. I can add things like I want to make sure that the color is certain way. I want to make sure that a specific design decision is being made. And that makes it easier for me to then reimplement and rebuild things and additively add features in a structured way because that then can be used as context.

38:59 So something that my colleague and friend John Lamb is working on is optimizing some of these context acquisition strategies. So that's going to change in the future. But you can imagine that as I have more of this context in the memory of the system that is being built, it actually makes it easier to build consistent software. So uh hopefully this is a great intro for you to see like how spectra works, what are the artifacts and how it produces them and how you can then tweak them.

39:23 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 as 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 specd driven development.

39:56 I hope you enjoy this. I'll see you in the next