YT YouTube2Text

YouTube2Text → Transcripts → Answering Your GitHub Spec Kit Questions

Answering Your GitHub Spec Kit Questions — Transcript

by Den Delimarsky · 4,081 words · 594 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Hey friends, today instead of me
0:01rambling about more Spec It features and
0:03changes, I thought I'd instead focus on
0:05something that is much more important to
0:07me and that is answering your questions.
0:10The videos that I've been posting about
0:12the Spec It evolution have been gaining
0:14a lot of traction and there were a lot
0:17of comments that I thought it'd be much
0:18better for me to just address over video
0:20so that future developers, future PMs,
0:23designers, data scientists that are
0:24using this tooling can benefit from. So,
0:27the first question is from Bobby Wang
0:300120 and that is, "Thanks for the video
0:33on Spec It. Quick question, you add the
0:35learnings to the spec doc at the end.
0:37After several iterations, the plan tasks
0:39and other MD files can drift from what
0:41actually shipped. Do you also update
0:43those files or leave them as historical?
0:46In your view, should we update only the
0:48spec doc or all the docs when the work
0:49is done?" I'd say if I look back at my
0:53workflow, I try to keep the spec itself
0:56as the sole source of truth unless I am
1:00making changes to specific
1:02implementation details. So, for example,
1:03if I go through the process of designing
1:06a new landing page for my site, right?
1:09And I have made certain design
1:11decisions. I have made certain certain
1:12decisions around things like the layout
1:15of the page or what should be and
1:16shouldn't be included. And some of these
1:18decisions will pop in after the fact.
1:21Like you've already started specifying
1:23things, you've already started kind of
1:24working through the implementation and
1:25you realize, "Oh, I forgot that I want
1:28to include a list of testimonials forgot
1:30that I want to include a contact form or
1:32a box to subscribe to my newsletter."
1:34Right? So,
1:35you'll obviously ask the LM to go and
1:38get the functionality for you, but that
1:40was not in your initial spec. And what I
1:42usually do is knowing the fact that for
1:45a lot of these things, I will reuse them
1:47in the future. For example, as I
1:48mentioned in my previous video, like
1:50what if I decide to change my static
1:51site generator or if I decide to change
1:53the back end, I still want to have the
1:56specification that is the source of
1:57truth and reflecting what I meant with
2:00the actual final output. So, in this
2:02case, I just asked the LM to encode the
2:04learnings from the conversation, from
2:06the context that we have into the
2:08specification. And some of those
2:09learnings can also be encoded into the
2:11plan. Now, I personally consider the
2:13spec to be the more durable artifact of
2:16all of them, right? Because the plan
2:18changes. As I mentioned, the plan is
2:20much more flexible because the the the
2:22plan file is the technical spec. This is
2:25where I define the shape of the API.
2:27This is where I define the framework
2:28that I'm using, the database. And those
2:30can change. So, if you're not changing
2:32those, you can leave the plan as is and
2:34update just the spec. If you realize
2:37that actually the database that I chose
2:39is not really fitting, like I can't use
2:41SQLite, I actually need to use like a
2:43document DB hosted in the cloud, then of
2:45course update the plan as well. But I
2:47tend to update them and keep them
2:49updated as I go through the process
2:51because you're absolutely right. But
2:53there's going to be points that where a
2:54lot of these things will just be
2:56underspecified and I will realize after
2:58the fact that it drifted quite heavily
3:01from what I initially envisioned because
3:03I did not ask the questions that I
3:04thought I would ask. So, keeping them up
3:06to date is generally a good idea. But
3:08I'd say from a priority perspective, the
3:10spec document and the constitution
3:12probably be the most important and then
3:14obviously the implementation plan and
3:16tasks,
3:18I'd say it's generally a reflection of
3:19the implementation plan or the technical
3:21plan anyway. So, you can just delete
3:23tasks and just recreate it as you see
3:25fit. And another question is from Carlos
3:28Pravia 4967. "In our team, we tend to
3:30use different Git repos to develop
3:32different parts of the app. For example,
3:34one repo for implementing the required
3:36app logic and endpoints, another for
3:38handling the client side and UI and
3:39perhaps another for deploying GraphQL
3:42other types of data queries. In this
3:44type of scenario, would you recommend
3:46using one Spec It per repo to define,
3:48refine and test these components in a
3:50modular and safe way? Maybe with
3:52different team members focusing solely
3:53on that part of the app and then having
3:55another repo that maintains a high-level
3:57spec. How do you integrate and maintain
3:59coherence between these components?"
4:01That's actually an interesting question
4:02because in our samples so far, right?
4:05Like you've seen the videos, you've seen
4:06the demos, it's all about having one
4:09repository. And because when you operate
4:10in one repository, things are relatively
4:13constrained and easy to manage because
4:15if you work with the built-in Spec It
4:17templates, you'll notice that when you
4:19use the specify command, it's going to
4:21create a new branch within that
4:23repository, right? And that branch is
4:24going to have a version of the templates
4:29that sometimes are encoded based on the
4:31constitution. There's going to have
4:33a version of the spec, a version of
4:36anything else you might include in that
4:37particular iteration, right? So,
4:40if there is a shared spec repo, then
4:44somehow you need to cross-reference it
4:46from other repositories, right? So, if
4:47you have 7, 10, 15 different repos, then
4:51how is the core spec repo being
4:53included? Is it a submodule? Like you
4:56could do that, but then you're just
4:57increasing the complexity of actually
4:59managing that code. So, from my
5:01perspective and my experiments that I
5:03have done personally, again, take this
5:04with a boulder of salt because it might
5:06not be fitting for every single
5:07scenarios. But But what I've seen is
5:10using
5:11one Spec It deployment. And when I say
5:14that is basically like bootstrapping it
5:15for a specific project within one
5:17repository is the most helpful because
5:19then the the
5:21work is contained within that repo and
5:24managing becomes much much easier than
5:27using it across multiple repositories.
5:28Now, that being said, you can have
5:30content that is shared. So, for example,
5:32if you have a constitution that defines
5:34how web apps are built inside your
5:36organization, then that constitution can
5:37be pulled in through a Git submodule,
5:39for example, right? Like that's seems
5:42fairly trivial to set up and that is
5:44reusable. But there's other things that
5:46might not work as well, right? Because
5:49certain specs that you create for one
5:50repo are not really applicable to
5:52another one. If you have a repository
5:54that is for a mobile application and
5:55another one for a web app, then those
5:58spec templates or even the spec sets
6:00that already exist, they're
6:01very little value in probably matching
6:04them up unless you're talking about
6:05specific API design documents, right?
6:08So, I'd say like it it really depends on
6:10the workflow, but I've seen personally
6:12that per repo configurations of Spec It
6:15work better than having one shared
6:17unless you absolutely need that. And
6:20then you can use again tools like Git
6:21submodules to create this kind of
6:23infrastructure around the Git mechanisms
6:27to make sure that that content is
6:28actually shared across repositories.
6:29All right, the next one is a very
6:31interesting one. It's from SusieQ Codes.
6:33"Great video. I added to an existing
6:35project and use it to help refactor a
6:37monolithic page.tsx as a TypeScript
6:40component. It seemed to be going great,
6:42but when it made some changes, I noticed
6:43it had dropped some prior features. I'm
6:45using Cursor. I asked it a few questions
6:47and immediately began making more code
6:49changes even though we hadn't specked
6:51out the changes, which yeah, makes
6:52sense. So, if you overlook something and
6:54it starts creating new files which you
6:56then catch, what's the best process to
6:57capture the right specs, research tasks?
7:00I had to unwind and write a new spec
7:01even though spec one hadn't been
7:03completely implemented correctly or does
7:04spec two take care of updating what
7:06occurred in the first branch?"
7:09So, this is an interesting scenario. So,
7:11I think if I unwind
7:13kind of this explanation, it's
7:15essentially you have started a project,
7:18you have a specification, you went
7:20through that spec process, and then down
7:23the line you realize that, "Oh, Cursor
7:25started going off the rails a little bit
7:27and just creating things on its own that
7:29you did not ask for." And so, you need
7:31to now go and remove those files. What I
7:33started doing generally, and this is why
7:36it's so important to use Git here. It is
7:40it is so so important to use source
7:42control. Is my approach to this is
7:45when I start working on a new feature, I
7:47start working on a new component for
7:51something or a bug fix. And I use Spec
7:53It. So, when I use /specify, it of
7:55course creates a new branch. That makes
7:57it very easy. I also use a Git client. A
7:59Git client like GitHub Desktop or
8:01Sublime Merge or GitKraken, any of them
8:05really are great. You know, it's all
8:08like ice cream. It depends on your
8:09preference of what you actually like.
8:11But what I started doing is as I go
8:13through this iterative process and
8:14especially once you go into the
8:16implementation stages and that things
8:18can become a little bit murkier because
8:20there's things that you have not
8:21specified in the initial spec, initial
8:23prompt, and then you have to go and
8:24cover that. What happens is sometimes it
8:27does go off the rails. It starts
8:29creating new files and going building
8:31experiences you did not ask it for. And
8:32the easiest way for you to unwind that
8:36is to first of all, encode the
8:38requirements that you want. So, you spot
8:39it like, "Oh, I do not want to have a
8:41component for
8:43footer changes on my website." Right?
8:46So, that's fine. You encode it in the
8:47specification and then you go to the Git
8:50client that you have because you're
8:51already operating on a branch. You
8:53select the files that were not yet
8:55committed because we're because we're
8:57working on Git, we don't just
8:59automatically commit every single
9:00change, but we do it in batches. So, and
9:03you can just discard those changes. The
9:04spec can stay the same. The spec
9:06document is there. Make sure that that
9:08is actually checked into the branch and
9:09committed and pushed and then the code
9:12changes are flexible. So, if you see it
9:13go off the rails,
9:15just update the spec, discard the
9:17changes for the files, and then use the
9:19spec to re-essentially go through the
9:21process of creating things. So, that to
9:23me is the easiest way to do this is just
9:25lean heavily into the actual Git
9:28workflows. Super important. I think if
9:31there's one thing that I encourage
9:32people that are trying to use Spec It is
9:34get very familiar with how Git works,
9:37how branching works, and how you can
9:39stage changes and iterate on them
9:41without necessarily worrying about the
9:43fact that a uh you know, a rogue agent
9:46is going to go astray because it decided
9:48to, you know, design something
9:50differently and now you have to go and
9:51unfurl and figure out like what are all
9:53the things that went wrong and what are
9:55the code changes. Like
9:56use Git. Commit often for things that
9:59work.
10:00As you iterate, make sure that you track
10:02of that again with Git on a branch that
10:05we create for you by default and then
10:07use that to your advantage. That that
10:09would be my recipe for this. That's the
10:10easiest way to manage it. All right, the
10:12next question is from Griff.Ann and that
10:14is you mentioned the possibility of
10:15refactoring the website in the future
10:17and being able to simply reuse the spec
10:20because it did not include technical
10:21implementation details. How would a
10:23process like that work? Does the agent
10:26go back through each feature spec one by
10:28one including branching? If you were to
10:29create a new empty project with just the
10:31constitution and specs? So, that's an
10:34interesting one because I it's coming on
10:36the heels of the last video where I
10:37showed that I added a reading list to my
10:39website. And the challenge with this is
10:43that initially when I started my
10:45website, I of course did not use Spec
10:47Git. The website was started based on my
10:49own blogging habits, my own
10:51configuration. I actually wrote some
10:53custom templates on top of Comod as I
10:55called out in the video, it's all based
10:57on
10:58Hugo, the Hugo static site generator.
11:00Now,
11:01of course, in the context of this
11:03functionality, not everything would be
11:05recreated from scratch because this is
11:07not what's referred to as a greenfield
11:08project. This is not a project that I
11:10set it up from scratch from zero with
11:12all the artifacts being built with Spec
11:14Git. So, unless I go back and actually
11:16say, "Here's the structure of the
11:18landing page. Here's the structure of
11:19the about page. Here's the structure of
11:21the blog post page." All this stuff of
11:23course would not be recreated. But, for
11:25features that were built using Spec Git,
11:28for bug fixes that were built using Spec
11:30Git, for anything that is actually
11:33encoded in spec files, I can recreate
11:36this. So, you can imagine if I at some
11:37point decide instead of using Hugo to
11:39move to, let's say, Jekyll and Jekyll
11:41uses a different templating engine and I
11:44don't have the same ability to just have
11:46a built-in reading list page, I can just
11:49ask my coding agent, whatever I use at
11:51the time, to go in and rebuild based on
11:55that spec, right? So, in the context of
11:57the code base I'm operating in, it's
11:59going to go ahead and rebuild that. Now,
12:00of course, it's not going to rebuild
12:01everything. And of course, there's going
12:03to be a lot of variability, but it is
12:06the approach here. So, you can you can
12:08essentially detach the implementation
12:10from the spec and that that's where the
12:12value of the specification comes from,
12:13right? Because the spec itself is the I
12:17want to call it like the executable
12:19artifact. This the spec becomes the code
12:21because I can just toss it into an LLM
12:23and say, "Go build this in the context
12:25of what I'm operating." If you're
12:26building a project from scratch, that is
12:28a brand new app, you're building, I
12:30don't know, a SaaS business, it's a SaaS
12:32application, and then you encode
12:34everything in specs and every feature is
12:36spec, you know, your landing page, your
12:39checkout page, your user profile page,
12:41then of course, like because you have
12:43those artifacts, down the line, you can
12:45go on and recreate that with a different
12:47framework, with a different tool set, on
12:49different databases, and so on and so
12:51forth. But, it depends on the project
12:52and if it's a brownfield project, then
12:54of course, it will depend on having
12:56prior information encoded in specs. The
12:59next question is from Alpataminalp2933
13:03and that is, "Thanks for the great
13:04effort. The main problem with Spec Git
13:06is TDD or test-driven development. I
13:08think if you put a non-TDD approach in
13:10the constitution, it will shine. I don't
13:11have anything as TDD but intelligence,
13:13context, Linux, intensive credits, etc.
13:15Vi- wise, we're not there yet." Uh yes,
13:19I know and I'm practically working on
13:21this. So, for folks that don't know, if
13:23you use the built-in templates, one of
13:24the things that we encoded in them is
13:28test-driven development approaches. So,
13:29any new project, any new feature you
13:31start, it actually goes in and says,
13:32"Oh, you need to create tests." And as
13:34you saw in my last video where I talked
13:37about the possibility of using this with
13:40my own site, like I don't need tests.
13:43I'm just creating something that is
13:45based on the existing project. I just
13:47want a new page for for the site, right?
13:50So, tests can be very very heavy and
13:52very time-consuming, context-consuming
13:54as well because building that out is
13:56just a massive massive pain in the
13:58behind. So, yes, fully acknowledge that
14:01this is a problem. It's coming. We're
14:03going to have a TDD-less option for this
14:06and then you can add test-driven as you
14:08need, but it's not going to be baked in
14:10by default because, yeah, I agree. It's
14:12it's it's a little heavy and it's not
14:14really appropriate for every single
14:16scenario. I'd say like even actually for
14:17most very quick prototypy iterative
14:20scenarios, like I don't I don't need
14:21tests. Just give me the product. I want
14:23to see it. I want to I want to see it on
14:25my screen. I want to be able to interact
14:27with it and not worry about which tests
14:29were created because all that stuff can
14:30come in later for more serious
14:33enterprise projects. So, point taken.
14:35Thank you so much for the feedback. Now,
14:37another question comes from Ninjatronics
14:39and that is, "So, what will be the
14:40proper way of adding features to my
14:42current website that I didn't start with
14:44Spec Git?" Hmm.
14:46It's exactly the same thing that I did
14:48in my previous video. The site that you
14:50saw, the blog that I maintain, my own
14:53blog is not actually built with Spec
14:55Git. I had it for since I want to say
14:57like 2017 in the current shape with Hugo
15:00and for like
15:01more than a decade because I used
15:03WordPress before, right? Like it was not
15:04built with Spec Git. It's a custom theme
15:07and I used Spec Git to build on top of
15:09it. So, you can use different techniques
15:11to actually build out the context of the
15:14code base, right? So, like folks have
15:16been using Cloud.md to provide that
15:18context and by the way, when you use
15:19Spec Git and specifically one of the
15:22commands is going to bootstrap that
15:24agent file if it does not exist to
15:25encode some of the decisions. But, if
15:27you already have one, then you can use
15:29that to provide context as to how your
15:31project is structured, what are the
15:33components, how it operates, how it's
15:35being built, and that will allow the LLM
15:37that as you're creating new features to
15:39use that context to actually understand
15:42the relationships and know like, "Oh, if
15:43I'm going to create a new footer, I need
15:46to look in the components folder here
15:48for this TSX file that's going to be my
15:50footer." Right? So, the process is not
15:52that different from one any greenfield
15:54projects. So, your biggest bottleneck is
15:56really going to be to provide as much
15:58context to the LLM as possible about
16:01your project, about what you're building
16:03and how you built it previously so that
16:05when you start specking new things, it
16:07has that context and then it can operate
16:10with it and say, "Oh, I know where to
16:11look for components." That being said,
16:13in my experience, depending on the
16:15complexity of the project, the LLMs, the
16:17modern models especially, are very good
16:20about kind of sussing out this context
16:22dynamically. So, I as an experiment, you
16:24know, I showed you the reading page in
16:26my previous video. But, something that
16:27I've also done before is asking it to go
16:30and build me a new component that I can
16:32embed like a podcast player in specific
16:35page types and you can modify it, right?
16:37And it would actually scan the
16:40component definitions within the folder
16:41and say, "Okay, let me take a look at
16:42how all these components are defined.
16:44Let me take a look at where the podcast
16:46component might live." And it created
16:47relatively well. Like I'd say like there
16:49there is of course gaps and you as an
16:51engineer are going to be in control and
16:53saying like, "Oh, you actually looked at
16:54the wrong folder because this is the
16:56compiled components, not the actual
16:58defined components." So, you still have
17:00to be aware of those things, but I I I
17:01noticed that that gets better. But, I'd
17:02say like if you provide proactive
17:04context ahead of time, that usually
17:07works much much better uh on any new
17:09feature iterations. And the last
17:11question for today is going from AOUsef.
17:15I think that's how I pronounce that
17:16name. Yep, A A Y 0 U S E F. For the
17:20simple use case most web devs would have
17:22spent much less time building with no AI
17:24or simple AI assistants. For complex use
17:26cases, not sure how the constitution
17:28will fit in a single repo with back and
17:29front and DB files and other docs. You
17:32are absolutely correct. So, the the
17:34sample that I showed you and again for
17:35folks that have missed the previous
17:36video, just go check it out. It's me
17:38adding a reading list page to my blog.
17:41Um it is a relatively simple use case
17:44and I'd say like if you're somebody that
17:46is comfortable with CSS, JavaScript, and
17:48templating in Hugo like I am, like sure.
17:50Yeah, I could have created this with no
17:52AI and this is just like a demo. But, at
17:54the same time, I'd say it's
17:55demonstrating how that process can work.
17:58For complex use cases you called out
18:00where, you know, you have a repository
18:02like a mono repo that contains a whole
18:03bunch of other things that are not
18:05necessarily tied together, this does
18:08become a little bit trickier, right?
18:09Because you have one specified folder
18:12with the kind of the the templates and
18:14everything else that are usually like if
18:16you define a constitution, like the
18:17constitution becomes bound to the
18:19specified folder and that specified
18:22folder is now embedded directly into the
18:24context of where you're operating.
18:27What we're looking at right now is how
18:29to properly split that up so that you
18:31can have a dot specify folder for your
18:33backend, a dot specify folder for your
18:35front end, a dot specify folder for your
18:37API,
18:38like monitoring solutions, and so on and
18:40so forth. So, basically give you the
18:41granularity so that
18:43you're still encoding the commands, the
18:44custom slash commands inside whatever
18:46agent folder you have as you should,
18:48right? Because they're they're generic.
18:50Like the slash specify is the same. If
18:53you're using slash clarify, it's the
18:55same. It doesn't matter which project
18:57you're using. The command itself is
18:59exactly the same as it would be for any
19:01other project. But, what changes is the
19:04format of the constitution, the format
19:06of the specs, the requirements. Like
19:07some things, as we just talked about
19:09like test-driven development, some of
19:10them require tests, some of them don't.
19:11So, you could have multiple specify
19:14folders in these different projects and
19:17then use
19:19the prompts from from the project as is
19:21within those folders. So, we're we're
19:23kind of testing this out right now and
19:25there's going to be a documented
19:26approach to make it a little bit easier
19:27because mono repos are a thing.
19:30We know it's a thing and we know we have
19:32to actually cover it. So, not yeah, not
19:34every scenario is going to be uh this
19:36vanilla very much constrained Git up
19:40environments like a one repo one
19:41project. So, yeah, uh we know it's
19:43coming. It's going to be documented.
19:45You're going to receive this in one of
19:47the next videos. I'm excited to show you
19:49our progress. And that's it. That's it
19:51for the questions for today's video.
19:53Stay tuned for the next one. I have way
19:55more coming. There's way more updates
19:57coming to SpecKit. I'm excited to see
20:00all of you testing it out and pushing it
20:02to its limits, providing so much
20:03feedback. And please go to
20:05github.com/github/spec-kit,
20:08provide your feedback, participate in
20:10discussions. And I'm excited.
20:13I use the word not likely at all. I am
20:15excited to bring you more SpecKit
20:18goodness very, very soon. See you then.

About this transcript

This page contains the full transcript of Answering Your GitHub Spec Kit Questions by Den Delimarsky, generated from the public captions YouTube serves with the video. The transcript has 4,081 words across 594 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.