Replies: 4 comments 3 replies
|
Good point. Can't this be solved with constitution.md? tks |
1 reply
|
Very excited to see Spec-Kit as I’ve been working on something similar after disappointing experiments with prompt engineering. One key issue is recognizing that there will be always be existing code in various forms. It’s important that if something exists not to try and change it if it’s already working. Code analysis against the spec is key vs. just spitting out new code |
1 reply
|
I have had some good results using a combination of this update to my project's constitution.md` and Repomix. ## II. Brownfield Context via Repomix
For brownfield projects or projects with existing code, use the Repomix tool to gather context about the existing code and structure. Run Repomix during the planning phase at the repository root and store its output alongside planning artifacts (e.g., /docs/planning/repomix.md). The team must review this context to inform scope, risks, and architecture decisions before proposing changes. |
1 reply
|
Yea, I think this is a pretty critical use-case to be able to cover - the ability to bootstrap spec-kit on an existing project to not just implement new features but to refactor for specific outcomes. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I have a suggestion for Spec-Kit.
When someone specifies a requirement, the agent should first check for existing features or code. If it recognizes existing implementations, it would make more sense to generate tasks that improve or extend them, rather than creating entirely new ones. This approach would also help existing projects by addressing bugs more effectively. I hope this feedback helps.
Thanks
Waheed
All reactions