Add Examples of Using Spec-Kit for Refactoring Existing Projects

[vasja34]

I think it would be very helpful if spec-kit included practical examples with a YouTube video that show how it can be used to refactor existing projects, not just for new setups.

Such examples could demonstrate:

• How to integrate spec-kit into a legacy codebase
• How it simplifies restructuring or modernizing older projects
• Concrete scenarios where developers can see the before → after benefits

This would make it easier for teams to understand the real-world value of spec-kit, especially when they are deciding whether it’s worth adopting.

YouTube demo video showing the refactoring process in action.
Seeing spec-kit applied step by step would make the learning curve much smoother for new users.

[pluggy]

I fully agree. Not all of us are starting from scratch. Spec-Kit looks very interesting, but I am not sure if it is suitable for extending existing enterprise projects that do not have the same specification style, structure or verbosity. Many legacy projects do not even have any spec at all...

[Santahehehe]

True!! I am currently refactoring an existing monolithic system into a fully decoupled frontend–backend architecture.
However, the project does not yet have a clearly defined process or guideline to follow how to use speckit for this transformation.

[anchildress1]

If anyone has a great YouTube reference, post it here! I can add something to the docs, assuming we get maintainer ok 😁

[chdwangjing]

I urgently need to solve this problem!

[BrianBNeal]

TLDR; be prepared to take your time getting things set up with a legacy system.

Our team is setting this up at work in a legacy enterprise architecture. So far we're doing it in one project, with the hopes of using it in 4 others, all of which interact. It's only been a few days, but I would say prepare to take your time with each step. Set up a constitution, and try creating a spec for one item on your devops board. Notice the places it has made assumptions that you didn't want it to make and go back and use the /constitution command along with the change you want and it will do a pretty good job of tweaking everything. For example, the second time around we added this to the constitution so it would take more time looking at existing types and services:

Reuse Before Creation
New features **must** prefer leveraging existing Types, Services, and Repositories before introducing new ones. When existing abstractions partially fit, contributors should extend or compose them rather than duplicating functionality in new constructs.
New Types, Services, or Repositories should only be created when:
- No existing abstraction covers the required domain concept
- Extending an existing abstraction would violate its single responsibility
- The new construct represents a genuinely distinct domain boundary
**Rationale**: Enterprise codebases accumulate complexity quickly. Reusing established, well-tested abstractions reduces duplication, minimizes future technical debt, and keeps the codebase readable and consistent. Every new type or service introduced is a long-term maintenance commitment.

After tweaking the constitution, try creating a spec again for the same devops item from before, but this time make sure to have a well defined PRD to provide with the /spec command. The key with existing systems is to do a LOT of human-led proof reading, verification, and editing. Use your preferred AI assistant, but read, verify, and modify everything it generates. As you move along, you'll find that you're having to do less and less. I can see how this is going to be an amazing tool for us, but there's definitely a ramp-up period as you get your documentation set up properly. You'll probably also gradually make additional documents that aren't explicitly part of the speckit workflow, like a Database.md file to document your data schema and processes for adding/naming new tables, etc. Make sure to add those to the constitution so it will always compare new plans/tasks to your established patterns and methods of doing things.

[chdwangjing]

你好，已收到你的邮件，祝您生活愉快。