Replies: 2 comments
-
|
Thinking about this a little further, perhaps it could be implemented as simply as something like "references.md". This document could hold local and remote references Spec Kit could use when forming things like Constitution, Spec, Plan and Tasks. It's similar to these, but different because it codifies things outside of the project / core spec. You could add a /speckit.reference to add new references, too. Kind of like a living repo of useful information from outside the project. |
Beta Was this translation helpful? Give feedback.
-
|
I also need this feature, as my project is developed in a componentized manner. The project consists of multiple components, and I want each component to have its own Speckit context and Git repository. I hope to be able to switch between Speckit contexts to develop different components. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi there,
I'm pretty new to Spec Kit, but I'm loving what I'm seeing so far.
However, it strikes me that we have to manually specify some things that might be either pre-defined by our organisation or personal preferences. Granted, the AI can help, but it would be good to be able to provide some grounding.
Not sure if this is already possible, but it would be great to be able to point Spec Kit at a file or folder of files that already codify the things we want and say something like "Using the components library, build a Constitution for an app that does X using tech stack Y".
This would enable people to share common best-practices for different design patterns and tech stacks that could be "bootstrapped" into Spec Kit easily.
So, if I wanted to build something with TypeScript, Electron, Tailwind and React (for example), I could just load in in those components and these would be .md files for each that would just be used as reference (or even incorporated) by Spec Kit into the environment.
Alternatively, if I am building a User Login pattern, I could provide a Best Practice document for that. Meta specs if you will. With each one being a component.
It probably would be best to have components based on the phase (constitution, spec, plan, tasks, etc) ... so perhaps they could go in a folder based on that?
I don't have a strong opinion about the implementation, but I do think this would make it considerably easier to develop specs by using open source components, or to develop some components within an organisation that can be managed in a shared repo.
Thanks again for developing and sharing Spec Kit!
Beta Was this translation helpful? Give feedback.
All reactions