Initialize specify within existing project

[devfirexyz]

Do spec-kit supports initialisation within already working project ?

If yes can anyone please redirect me to the correct resources.

[wochagonnadu]

Yes, spec-kit does support initializing within an existing project. The documentation confirm that you can run specify init --here in a non-empty directory. The toolkit is designed to work with both greenfield (new) and brownfield (existing) projects, enabling gradual adoption of spec-driven development practices.

However, a warning is displayed:

Warning: Current directory is not empty (22 items)
Template files will be merged with existing content and may overwrite existing files
Do you want to continue? [y/N]:

My opinion & caution:
While spec-kit supports this option, you should be careful. The tool might overwrite or merge template files with files in your existing project, especially those with the same names (e.g., README.md, .gitignore, etc.). It's a good idea to create a git commit (or backup) before running the initialization. This way, if anything is accidentally overwritten, you can easily restore your original files.

[ilyavenger]

The risk of running over files should be mitigated by:

#38

[mmcguff]

This idea of using spec kit with existing projects is gaming changing. Please make this more clear in documentation that this tool can be used in existing projects.

I understand AI can overwrite existing code which is where it becomes risky but so long as you provide some warnings around this, the benefits outweigh the risks. Love this project.

[HichemTab-tech]

We can even enhance existing project guides/starters by incorporating the current structure, code, or state, enabling the LLM to understand how to continue or refactor :D

[mmcguff]

@HichemTab-tech Totally agree. Existing tools could introspectively look at the files and attempt to infer the core things needed for specify. From there a existing projects can quickly iterate and vibe away building out features aided by AI tooling with a decent contextual starting point.

[HenryThriver]

What is y'all perspective on best practices when starting brownfield in regards to "reverse compatibility" for specs?

Should we draft up specs for features that have already been implemented? Or just start where we are now and move forward?

[mmcguff]

@HenryThriver I think you should provide the option to do either option but the default should be looking at features that are already implemented. I really see this this support to brownfield being a means of onboarding existing projects. We should assume that some of these projects don't have great testing covering them. Generating specs for these items that are already implement or inferring what the features are positive refactoring steps for any project.

[HenryThriver]

@mmcguff agreed. I'm spinning this up in a relatively new project with a handful of features but not much. It already feels overwhelming to try and "manually" backfill.

Instead, I started on the feature that is most recently in PR just to start where I have some perspective / context, and it was certainly illuminating on how much more robust this methodology is than default. That said, I'm nervous to see what happens when it goes to "clean up" the past implementation and how it "nests" into existing code / features.

[mmcguff]

@HenryThriver, While the current approach addresses shortcomings in past implementations, its impact will be limited without a clear, pragmatic path for adoption in existing projects. Many enterprise codebases cannot justify the risk or cost of a full greenfield rebuild.
By defining a low-friction, incremental adoption strategy—one that allows teams to introduce spec-driven best practices with Spec Kit on the very next feature or workflow iteration—we can transform this from an opinionated prototyping paradigm into a practical bridge for real-world systems.
Such a path would enable AI to load and interpret the true context of an existing project, improving the quality, maintainability, and velocity of agentic development. This is not just about building better prototypes; it’s about empowering teams to evolve their systems without disruption, while unlocking AI’s full potential in complex, established environments.

[fergoid]

@mmcguff Do you think the key is being able to generate robust constitution files from existing corporate/institutional knowledge (not necessarily code)? I don't know about your environment but we are great at generating v1 of the standards/guidelines but then often fall back to tribal knowledge as things change. So new joiners read the docs and then get told about all of the deviations / conventions that are now being followed.

So I guess your experience here will depend a lot on how good you are at maintaining your constitution today. And I don't really think this problem is unique to Spec Kit, any tool that relies on instructions is open to this.