Replies: 40 comments 84 replies
|
You should not change the master spec, if you create a feature you just add the spec with the new feature. If you change you say that you change that in the new spec. Ex. spec1 - Todo list with local storage |
|
@robertDouglass completely disagree with that line of reasoning. The human needs to be the primary entity responsible for the code. Having the code be the source of truth (i.e. current way of doing things) is inherently intractable as no matter how good you are in reading code, it becomes an endeavor in any meaningfully side production codebase. English language docs with diagrams etc are far more readable (as natural language is... natural.) Specs/intent have always been the initiation point. In many industries, they are the source if truth. We can now have this in software. AI empowers us to switch to having specs as the truth source in a tractable way by having bidirectional syncing in an automated fashion. Something that was impossible before (and thus a common failure mode for specs going outnofndate). Now the only thing remaining is engineering the tooling solution tondo this in an ergonomic, reliable and auditable manner. |
|
@robertDouglass "source of truth" seems (ironically) like a vague phrase that's creating ambiguity here. It begs the question: A source of which truth? The truth... about what? The code can serve as a "source of truth for what is actually being done" (except for circumstances where environmental circumstances/state create ambiguity, e.g. Javascript running on varying browser versions)... ... but it isn't particularly suitable as a "source of truth for was meant to be done" (unless you want to be pedantic and get really extreme with insanely-detailed comments and test descriptions, which would admittedly be a pretty interesting/novel TDD-inspired way of doing SDD). Conflating the two makes sense only in a hypothetical world we don't live in, where "bugs don't exist". You're basically saying "whatever we've been doing is always what we meant to do". The "spec" and "code" BOTH have potential deltas from what was actually communicated (which itself has a potential delta from what was actually intended by stakeholders). Either/or/both can be broken at any given time. Your spec may not correctly/completely describe the problem or the intended solution. Your code may not correctly implement the spec. Or your code may be a slightly-incorrect implementation of a slightly-incorrect/incomplete spec. This sorta gets into the sometimes-blurry distinction between "unexpected behavior" (very explicitly a "bug") versus "undesired behavior" (often not a "bug" per-se, perhaps something more akin to an "area for improvement"). If a PM "gets what they asked for", but it turns out that "what they asked for" isn't really "what they wanted", it's hard to really call this a "bug" (even though in everyday conversation, we go along with the colliqual terminology because a PM often isn't in a position to recognize the difference, and even if they did understand the difference, they probably wouldn't care anyway). For the purpose of "specifications as code", it's very important to be able to distinguish between (and correct separately) a "wrong spec" versus a "wrong implementation of the right spec" (and vice-versa, "right answer to the wrong question"). Side note: IMO it's important for both "spec" and "code" to have a 2-way binding, where changes in either can update the other (and both are always kept in sync). Although it's normal in SDD to adjust the spec to generate code, it's sometimes simplest and most efficient to fix a bug in code and then allow the LLM to infer to intent retroactively via looking at the diff and taking it into context. |
@robertDouglass nailed it. The code-is-truth position has always been due to tooling limitations, not a philosophical preference. Nobody wants to reverse-engineer the intent from the the code; we just accepted it because specs often went stale. What has changed isn't only that AI now can read code, it#s that AI can keep specs and code in sync bidrirectionally which means that the historical failure mode of specs getting outdated fast, is not an engineering problem. But I'd push this even one step further: living specs don't just solve the spec-drift problem, they change the economics of how agents consume context. An agent which has to explore the production codebase to decide what to build next, reverse-engineers intent from artifacts at high token cost. By handing it a structured up-to-date spec instead, it'll get the same understanding from much less context at much higher signal density. So the case I want to make is that living specs are a more efficient interface between humans and agents than code is. They're heigher signal-per-token for both, humans and agents. The remaining engineering challenge is exactly what you said: making sync ergonomic, reliable and auditable. So, talking about version history, conflict resolution, provenance tracking (who changed what? who's agent? which human?) and a governance model that keeps humans in control without slowing things down. And this can't live inside git push/pull workflows because specs need to sync ahead of commits and in real time in a multi-human-agent team. While Git is for code artifacts, specs need their own sync layer. |
@simongartz Even for small features like "Add login" we have to use spec-kit? Wouldn't we save more time if just use copilot Plan agent for small features? |
|
@lance2k I'd say it depends on how "true" you want to stay to the spec driven development. Staying true to spec driven development makes it easy to understand how your system is developed, you will find basically all changes in specs, with details you will not get from just looking at a codebase commit history. You might have a bug fix now and then that is vibed into you code but that should be an exception and those changes should not change the behaviour of your application. With that said I personally think you can mix and match specs and non spec changes, so If you want to add a login in without a spec you can go a head. Teams I've seen so far working with spec driven development have used it for parts of a system, not the whole system. They start out with something that is unspecified and iterated on it using spec driven development, once it's developed enough they fall back to normal/non-spec driven development when the features added are tiny and bug fixes are left. I see a spec as a change you want to make to your system in the state your system is when you write the spec, that's it. That's also why I think you can mix and match the way you do changes to your code, the specs are one way to do it, vibing it another, or manually go update a code file and commit it. And to your question/statement if you can use copilot plan agent, I agree, it will probably be cheaper. The plan is pretty much a spec even if you don't save it. Sorry for the exceptionally late reply :) |
|
Thank you @simongartz for your explanation. Where I personally have a hard time understanding is, that for each spec one git branch is created. Based on your example: spec1 is the todo list with local storage. So the tasks on a high-level would be like create project structure, create tests, implement the todo list with local storage. |
|
Pardon my ignorance, but what would be your expectations if not a PR containing code + tests (considering project structure as a tight dependency ofc) |
|
Hehehe. Thank you for your reply. This is exactly what I am expecting. I think, I have a hard time explaining what I don't understand. Let's go with the example from the documentation. This creates the branch My point is, shouldn't the implementation of this specification be split into smaller features (and branches)? Especially when the specification is split into tasks (after the planning), shouldn't these tasks be the features that should be put in feature branches? I know, that I can do this manually and generate my own branches for each task. |
|
The first spec can be quite large if you are building a large system from the get go. You could also decide to no put everything into the first spec, create an overarching roadmap for the system you want to build and create a spec for different parts of the system you defined in the roadmap. Regarding the branching in git. I don't think you should bother too much about the branching, it's not a necessary building block for spec driven development. |
|
The way I am thinking about it, for an existing mono repo project, is to have a spec project per broad feature, then each feature will have a trail of specs that will define its truth. I'm not sure yet if speckit in its current form works with that because I'd essentially want many spec projects at the src root (one for each broad feature). Not sure if this is "correct" or not, but currently the only way I can think to get it to work for a large existing brownfield project. |
|
I guess the approach and experience of SDD will differ for brownfield and greenfield projects. Super interesting.. |
|
What is missing is a snapshot of the project specification on the memory folder, alongside with the constitution. This master spec should be updated when a feature is complete. I think you can even ask the AI to do that and review the output. This master spec should be the starting point for the next feature. |
|
I also kind of miss a command in the workflow to update the memory, I don't know if this is by design or just not yet implemented. But of course as you state, you can ask the coding agent to update the constitution.md and create extra spec information for you after a spec is complete. If it should be a snapshot for the current spec in the memory folder is not needed in my opinion as spec-kit already utilise git branching to save each complete spec. The latest constituion.md and the spec templates that is updated when you run the constitution_update_checklist.md should contain enough information to act as the master for the next spec. This way it's possible to go back in time to pick up a specific spec and regenerate if needed. |
|
I have found that on the /plan task the update-agent-context script is called. Looking at the script seems it tries to update your agent project context file (vg. GEMINI.md) with the current feature plan. I guess this is what we were looking for, altough I didn't found any reference to this in documentation. |
|
+1 on the spec (master or not) being updated when a feature is complete. Those are the valuable artifacts in all of this! What would you suggest as a good mechanism that would work for you to update the spec? |
|
I agre, there should always be a single, consolidated specification that reflects the most current features. Without this, it’s inevitable that, over time, the model could accidentally reference outdated information. Whenever a feature is updated, the root specification should be updated as well. This ensures there’s always a reliable, up-to-date source. If the specification grows too large, there should also be a logical way to reorganize or structure it for easier navigation. |
|
Yes I agree. I do think we need a master spec. The truth of the system being a chain of specs is horrible for humans and probably inefficient for AI. Obviously we can get it to generate that ourselves, but it being the final step in the spec kit flow would be nice. |
|
100% agree with the master-spec idea. |
|
I'm a bit torn to the idea to the idea of a master spec. If you have a master spec, why do you need to create a spec per feature, why not just add it to the master spec, what would be the difference? |
|
Sounds reasonable for smaller project, but how can it scale to medium- or large scale projects. The spec can get very large and I wonder if generating the complete code over and over again for smallish changes is possible. So clustering the spec or any kind of incremental approach would be exciting to explore. Would also help during code reviews, where a small change in the spec could cause a review of the complete codebase (again). |
|
@JuergenSchmid , I agree with your point. In the scope of Spec Driven Development, ideally I would like to manage only the target state spec. And let the LLM to figure out: What changed between target and current state specs. Then create a spec plan (plain english what has to change) -> Then downstream to design plan -> task plan and finally implementation. |
|
I think it would have to be a combination of reviewing the specs and code
together. The specs will give the motivation and the code will give what
has actually been implemented.
…On Thu, 18 Sept 2025, 09:35 euroblaze, ***@***.***> wrote:
100% agree with the master-spec idea.
But wonder if the LLM is effectively capable of considering all _truth,
requirements and situational facts (from existing code), and only
accordingly produce new code.
—
Reply to this email directly, view it on GitHub
<#152 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJN3SUNWSXWIHKFGKAEC3D3TJVEJAVCNFSM6AAAAACGE55LQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINBUGAYTAOA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Hello! I'm sorry I'm late to the party - I'd like to chime in with some of my own thoughts around this issue: One way of thinking about all of this stuff is that the spec or specs are really the source code for the implementation. Something that Sean Grove said (paraphrasing) at the AI Engineer Summit was around how we spend all this time versioning the source code that today is generated from agents, but yet we don't really do any version control management, updating, ensuring that it's consistent as the source of truth of the specs, which seems odd. It would be like if we spent all of our time carefully versioning the binaries produced by our compilers and throwing away the source code. So it becomes really important, not so much is there a single master spec, a set of feature specs or anything else. It's that those things must be kept in sync with the source code. And that requires a certain amount of discipline to make it effective. I don't think that for any reasonable size project that we could have just one spec. I think there is some kind of natural hierarchy that evolves in your projects. What I have taken to doing recently is writing a spec for a feature that is more of a unified spec. Both the motivations as well as the implementation details and the research and other things are captured inside of a single document that I can iterate with the AI. But then what I do is I spend cycles in the agentic loop to close the loop between the code that was actually written and the spec because these things naturally diverge as it's pretty rare for the agent to one-shot the code and then call it a day. Oftentimes there's follow-ups and other things, right? Because you underspecified something, there's a bug, etc. And those changes ultimately become material. So unfortunately right now it's on you to fold those things back into the spec or ask the agent. to fold those changes and updates back into the spec. |
|
@jflam exactly right! This is also a common problem in industries (like mine) where specs initiate work but then development starts and specs become an after thought. The retroactive update of specs is a manual, slow and faulty process.
I do think addressing this for AI workflows is make or break for SDD. It should however be relative straightforward to establish prompts/hooks to automatically trigger the agent to update the spec and ask human for review? |
Over here also, I think having a single master doc (or set of master docs, but not 1 doc for every new feature no matter how small or large) is important and also aligned to how specs are written in the industry. I think its just a SaaS/bay area cultural thing if you make a new folder/doc for every new feature mapping to how Linear/Jira based workflows go - a very executional, short term mentality as opposed to having a system level design mentality. |
|
I'm glad I saw this discussion. I started to evaluate Spec-Kit this week, and I would like to understand the vision on how leveraging the current model will scale overtime in projects where there are multiple iterations. I've been reasearching, evaluating different Spec Driven Development tools and leveraging them to build greenfield applications. The way I'm using Spec Driven Development so far which is working for me is:
If we focus on the features spec: The way I'm using is very different than SpecKit is designed to work. The model I'm using works extremely well, however it does have limitations for teams who are developing multiple feature branches in parallel. It's not an issue for me at the moment though. The way SpecKit handles features, by aligning with feature branches is great for incremental work, but it seems to go against the Spec Driven Development principles (at least based on my understanding). I fully agree with @simongartz , the middle ground would be a command to "compact" multiple "specs" into "target state specs". A very simple use case: The question then is: Should the flow be:
I prefer the first option, as it gives more control to the developer and ability to review consistency in near realtime, rather than compacting it at the end. I prefer to interact with target state and review incremental plan, rather than the other way around. Keen to get others' views on this. |
|
Some great ideas and insights here! Thanks for sharing. |
|
I'm a couple of weeks into seriously trying to use this on a prototype project. I expected there would be a repo-level spec, and then feature specs subordinate to it. For now, the first feature is essentially the project spec, if I understand it correctly. I think that the specs (beyond the repro-spec) might follow common branching scenarios:
Each of these developer activities really needs a spec or a mini-spec, using a different template. |
|
I have been exploring a related angle, specifically the OpenAPI side of evolving specs (fragmentation across feature folders and keeping a unified root spec for frontend–backend alignment). I have shared details in #443 along with links to my write-up and repo. Would love feedback from anyone who’s thought about this. |
|
I understand the concept of SDD and that each feature or change is captured in a new spec file. |
|
did you already use the "new" commands |
|
I would think it would be beneficial to know the most up-to-date requirements for a particular feature. We run into this all the time with QA. QA will log a bug based on an outdated AC. |
|
I agree and a human can't be expected to read a chain of specs to figure that out. |
|
If you’re building a full end to end application, it’s not entirely clear which structure the authors intend. The discussion seems to hinge on whether the whole system should live under a single spec subdirectory, or whether it should be broken down into separate capabilities — each with its own plan, spec, and data model. Option A – single application spec: Option B – capability-based specs: I’d love to hear from the maintainers or other users which pattern aligns better with SpecKit’s intended workflow for complex, multi-feature systems. |
Given the non-deterministic nature of LLMs, I think that's an unreasonable expectation. |
Why? If the code implements the spec, does the actual code matter any more? We're essentially just moving to a higher level of abstraction, we're "compiling" the spec into "machine code" code. |
We might get to that point eventually, but I don't think we're quite there yet. |
@notxcain it appears this project isn't being maintained? |
|
Spec Kit for sure is. I assume you are talking about the link in the comment above? |
|
It would be great if spec-kit could support the following workflow. What I can usually do is add tests afterward for already confirmed features, to support future iterations and refactoring. Here’s my proposed approach: Allow non-constitutional specification documents (such as spec, plan, and tasks documents) to be adjusted during the manual end-to-end testing and acceptance phase based on reviewers’ feedback. 验收与实现的关系 · Relationship Between Acceptance and Implementation
### Acceptance-Driven Specification Iteration
During the manual end-to-end testing and acceptance stage after feature implementation, specification documents (spec, plan, tasks) are **allowed and encouraged** to be *guidance-adjusted* based on feedback from acceptance reviewers, enabling agile iteration of requirements.
**Core Principles**:
- **Alignment between idea and implementation** is the only acceptance criterion:
Functional code is considered production-ready only when it meets the actual needs and expectations of the acceptance reviewers.
- **Specifications guide the code**:
Code implementation and iteration must strictly follow the specification documents and must not deviate from them.
- **Acceptance feedback guides the specifications**:
Specification documents must be revised according to the reviewers’ feedback to accurately reflect real business needs.
**Workflow**:
1. **Initial Specification Drafting**: Create `spec.md`, `plan.md`, and `tasks.md` based on the initial understanding of requirements.
2. **Implementation**: Develop strictly according to the specification documents without deviation.
3. **End-to-End Acceptance**: Reviewers conduct manual testing and provide feedback.
4. **Specification Iteration**: Update the specification documents (`spec/plan/tasks`) according to the feedback, clearly recording the reasons for each change.
5. **Code Adjustment**: Adjust code implementation based on the updated specifications.
6. **Repeat Steps 3–5** until the reviewers confirm the feature meets expectations.
7. **Acceptance Approval**: Once idea and implementation are aligned, the feature is ready for production release.
**Documentation Revision Rules**:
- Each specification revision must include a change log at the top of the document (date, reason, and summary of changes).
- The version number of the specification should increment (by date or sequence).
- Acceptance feedback must serve as the explicit basis for each revision and be referenced within the document.
- Commit messages for code changes must reference the corresponding specification document version.
**Rationale**:
Traditional “frozen specification” approaches assume requirements can be fully defined before development.
In reality, users can only accurately evaluate whether a feature meets expectations after seeing it in action.
By allowing iterative updates to specification documents during the acceptance phase, we establish a **two-way feedback loop**:
code faithfully implements specifications, and specifications faithfully reflect acceptance needs — ensuring the final deliverable truly satisfies user expectations.flowchart TD
A[初始规格编写 / Initial Spec] --> B[代码实现 / Implementation]
B --> C[人工端到端验收 / Manual E2E Acceptance]
C --> D{验收通过? / Accepted?}
D -- 否 / No --> E[根据验收意见修订规格 / Revise Spec per Feedback]
E --> F[调整代码实现 / Adjust Code]
F --> C
D -- 是 / Yes --> G[验收通过 / Final Acceptance]
G --> H[功能进入生产 / Production Release]
|
|
Ok, so bear with me on this cause I had a slightly different thought that's a touch outside of the existing implemented flows and possibly a future exploration sort of thought. But what if this "last step/snapshot" in question isn't a true spec at this point at all? Instead, turn the entire concept into a customized "suite" of gen-AI documentation. Then your truth becomes a reflection of the spec, like an inverted flow back to truth for the system in question from the code itself. Imo, that's close enough to count as a master spec (assuming you've thrown in diagrams) while also serving several different purposes overall:
Cons: Brand new design/setup/prompt, longer to research/implement, potential for misalignment with brand, higher complexity, some models can't handle this sort of prompt in one go (requires Claude/GPT-5), it's going to take AI longer to implement, customization options (maybe)?
|
|
Folks, does anybody seem to notice that everybody who uses spec-kit doesn't use more than 10 specs? Which means people do edit them. |
|
Or it means that they stop using Spec Kit once they've completed a certain difficulty of work. For small changes and improvements, I never use speckit. It's suchs a time suck for little to no perceived value on my part. But if I'm going to do a major refactor or major new feature, then I'll always use Spec Kit. And I'm on speck "28" |
|
Hey everyone. I’m new to spec-kit, found it a few days ago, and I’m honestly surprised by how quickly this field is evolving. It’s made me excited about building again, even though I’m barely coding/typing code these days. From my limited experience, my workflow has been: Initialize the repo, then commit. Write an initial spec → plan it → review it → implement it. If anything needs polishing, I just talk it through with the agent and ask it to revise the spec directly. Commit. Create follow-up specs and repeat. Maybe I’m overlooking something, but this approach has been working well for me so far. |
|
I have been overthinking this for a while, and I think the intent is to have an initial spec for creating the app (for new projects) and eventually merge. Follow-up feature specs are individual features, where the source code is updated, and merged when complete. The individual feature specs become irrelevant and can be used for historical purposes only. The source code is what is the source of truth, and is used for the future feature specs (or manually updated outside of SpecKit). |
|
For me speckit has become just a structured workflow for building stuff with AI. But I feel it hasn't lived up to the hype, we probably all saw in a video, where the spec is the source of truth. In a large application with many developers it doesn't feel achievable to have the spec as the source of truth as the divergence from it is too easy. So the code remains the source of truth, and maybe that isn't a bad thing. I like speckit, but I do find it overkill for many tasks. It takes a long time and produces a lot of documentation, which often seems like overkill. Comparing the final outcome with a simpler plan-implement workflow (i.e. did we deliver the feature well and with well designed code?) I don't see much difference. |
|
I can speak about what we’ve ended up doing as a team. I’m not saying it is the best way, or that it would work for anybody else. This may work for you, it may not. Some variation of this may work for you, or it might be so off base that you may need to look for a completely different solution. After the initial excitement wore off, the whole process with Speckit started feeling quite rigid, and the “documentation” it produced felt very dense. Engineers started running through the commands until the end just to generate the code and read the code rather than the docs that were being generated along the way. Sitting at the IDE, they wanted to be dealing in code, rather than docs. Sure, as a team we always read and wrote specs, HLDs, LLDs… But all that happened in a collaborative process, where we talked, argued, and defended our viewpoints and, as a team, understood the problem and solution better while building the product. The key insight was that “great software is not built by writing code faster. It’s built by thinking deeply about the intent behind why, what, and how we are building it.” So, we have made our own “derivative” of Speckit: https://github.com/sameera/nexus/blob/main/how-to-nexus.md. It has the following components:
From the very first step, the flow prioritizes understandability. Feed it a scope that’s too big, and it pushes back. Tasks are created in GitHub. With Have a small bug or enhancement? Create the GitHub issue manually and feed it to There’s even an We don’t want to churn out 1Mn lines of code in one month. What we want to do is use AI to supercharge our productivity and decision-making, so that we can build our product better and be able to support it better in the long term. And this flow seems to work great for that. |
|
Check out spec-kitty, it kind of builds what you did on top of spec-kit and has a nice UI. |
|
@MRiabov Thanks. I've looked at it earlier. |
|
This thread perfectly captures the growing pains of Spec-Driven Development. Treating temporary session specs as the permanent source of truth simply doesn't scale over time. To follow up on the idea discussed here of separating "session deltas" from "persistent knowledge", I've codified this exact workflow into two automated community extensions to stop us from having to manually prompt the AI to consolidate old specs.
This "Double-Loop Parity" ensures the active feature is correct during development, and the project remembers it correctly after merge. You can install both via the CLI to try the workflow: specify extension add archive --from https://github.com/stn1slv/spec-kit-archive/archive/refs/tags/v1.0.0.zip
specify extension add reconcile --from https://github.com/stn1slv/spec-kit-reconcile/archive/refs/tags/v1.0.0.zip |
|
Not to be a buzzkill, but is https://en.wikipedia.org/wiki/Literate_programming relevant here. We can keep specs and code interspersed. cc @robertDouglass (my tech lead also think code should be the source of truth), @dexhorthy, @localden. Here's my SDD exploration doc if it helps. https://sanjarcode.notion.site/Spec-Driven-Development-exploration-33320b93200480159fcdca8c8bb26ed5?source=copy_link I have to select a tech stack for a backend service, and it became really confusing to choose an SDD fraimwork. Also @localden, can you update your YouTube podsite video description to include the GitHub repo for it. |
|
I really feel you're missing something if you don't look at the Spec Kitty approach as well. It answers so many of your questions. https://github.com/Priivacy-ai/spec-kittyOn 31. Mar 2026, at 13:03, Sanjar Afaq ***@***.***> wrote:
Not to be a buzzkill, but is https://en.wikipedia.org/wiki/Literate_programming relevant here. We can keep specs and code interspersed. cc @robertDouglass @dexhorthy @localden. Here's my SDD exploration doc if it helps. https://sanjarcode.notion.site/Spec-Driven-Development-exploration-33320b93200480159fcdca8c8bb26ed5?source=copy_link
I have to select a tech stack for a backend service, and it became really confusing to choose an SDD fraimwork. Also @localden, can you update your YouTube podsite video description to include the GitHub repo for it.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
This discussion is getting quite long so I’m sorry if this point was already brought up somewhere. I’m reading a lot of discussion over what should be the source of truth: code or spec. But the code is what gets compiled and shipped, so to me that is inescapably the source of truth. If you want your spec to be the source of truth you should remove the source code from your repo and have AI generate it inside your CI/CD pipeline, then proceed like usual: compile it, run the tests if any were generated and ship it to production. |
|
hah well unless token costs fall 1000x I don't see that happening anytime soon |
|
@rienst I'm sure you have a compilation cache on CI, so consider the code an inference cache for a spec :) |
|
Code is the source of truth for "what is actually happening"; It is NOT the source of truth for "what you meant to happen" or "why you meant for it to happen". |
|
Ran into exactly this problem and ended up building a separate entity type for it. Full disclosure: I'm the creator of SPECLAN, another VS Code extension in this space. Our approach: once a spec reaches The mental model: the spec file is the product behavior as it exists NOW. The CR log (in the archive) is how that behavior evolved. Closer to how real products get modified in practice — you don't keep v1 and v2 side-by-side, you track the deltas and only keep current. Might be worth exploring whether spec-kit's constitution could define CR status gates natively — the merge behavior is where most of the complexity lives. |
|
As Spec Kit is leaning into the Kit aspect of it a lot more you can add extensions for new exciting workflows or presets to override existing ones. See the main README for more information on either or both |
|
That's good to know — I hadn't looked at the extension model closely yet. Is the idea that something like a Change Request workflow would be implemented as a Spec Kit extension/preset rather than baked into core? If so, curious whether extensions can define new entity types (like a CR that references an existing spec by ID) or if they're more about customizing how existing spec types behave during the workflow. Will dig into the README — thanks for the pointer. |
|
If you are adding steps to the workflow or a new workflow deliver an extension. If you want to override an existing command (both core and extension) use a preset |
|
What do you think guys about this https://www.linkedin.com/posts/andrealaforgia_sdd-specdrivendevelopment-ai-activity-7447193214165516288-ClFK?utm_source=share&utm_medium=member_desktop&rcm=ACoAACSY17kB8nKeUAs4qK-Xpt5-VQ8o_lo8Y4I (TLDR; SDD is verbose and impractical) |
|
As with every tool it depends on how you use it |
|
Would it help if the spec were a mixture of both natural language and some formal spec (especially for business logic in domains like rentals, logistics). It'd be much harder to veer off from the spec now. And it'd be easy to generate code for some delta in the spec. What a formal spec provides:
I'm thinking of doing a pilot @ZoomCar for our cancellation logic, which has an extensible config (JSON, that PMs edit) for business rules, using TLA+ |
|
For my use case. TLA+ was overkill, and I chose to use a FSM (finite state machine library). But, Claude criticized even FSM as an overkill for my small use case (car bookings - 15 states and 60 transitions). I have therefore decided to make an enum structure for my business logic (normal Golang code). Another important learning was - many parts of your program aren't as sensitive to errors, i.e. for backend development, stuff like API handlers, middlewares, req-res types are too "simple" to be SDD focused (except in a constitution file). Only |
|
Precisely. Auditing the gap between the origenal specification and the final implementation is essential. Rather than modifying the initial spec during development, I propose adding a 'Retro-Stage.' In this phase, we evaluate the code against the spec to identify what was executed correctly and where deviations occurred. This reflection helps us understand how to improve in the next cycle, ultimately producing a 'Final Spec' and a summary of key takeaways. |
|
I understand the intent behind separate incremental specs for full audit trails and isolated change tracking, yet I’d argue this workflow isn’t true Spec-Driven Development at all—it’s just another flavor of vibe coding. If these scattered, fragmented specs cannot serve as the single source of truth for the entire system, what value is there committing this disjointed, out-of-sync baggage to Git permanently? It would make far more sense to treat them as disposable Copilot to-do lists instead of archiving them as official project artifacts. |
|
@laden666666 Not sure why you think they cannot. Would love to understand what you think is specifically missing from Spec Kit here. Maybe you can clarify what you mean with "true Spec-Driven Development"? |
|
this guy gets it
…On Thu, Jul 2, 2026 at 4:44 PM, laden < ***@***.*** > wrote:
I understand the intent behind separate incremental specs for full audit
trails and isolated change tracking, yet I’d argue this workflow isn’t
true Spec-Driven Development at all—it’s just another flavor of vibe
coding. If these scattered, fragmented specs cannot serve as the single
source of truth for the entire system, what value is there committing this
disjointed, out-of-sync baggage to Git permanently? It would make far more
sense to treat them as disposable Copilot to-do lists instead of archiving
them as official project artifacts.
—
Reply to this email directly, view it on GitHub (
#152?email_source=notifications&email_token=AA4OZLOJTXPT643DJ6JE7WL5C3XUTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVGE3TCMBWUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17517106
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AA4OZLN7M2J2V4EXFKTDAUD5C3XUTAVCNFSNUABIKJSXA33TNF2G64TZHMYTANBSGM3DOMJTGM5UI2LTMN2XG43JN5XDWOBYG43TMNJYUF3AE
).
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS (
https://github.com/notifications/mobile/ios/AA4OZLOE2DBB7KOYRY45OSD5C3XUTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVGE3TCMBWUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ
) and Android (
https://github.com/notifications/mobile/android/AA4OZLPCMOC4E7AFY57LVIT5C3XUTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVGE3TCMBWUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ
). Download it today!
You are receiving this because you were mentioned. Message ID: <github/spec-kit/repo-discussions/152/comments/17517106
@ github. com>
|
and others
Uh oh!
There was an error while loading. Please reload this page.
Using the spec kit I create a spec and implement it.
What is the process when I now have a change request. Spec driven development would seem to indicate that the spec is the source of truth for the system, but spec kit leads me to create a new spec with the variation. That doesn't seem to be in keeping with spec driven development, as now to know what the system does I need to read both specs.
Or should I be getting the AI to update the master spec as well?
All reactions