cross-posted from: https://programming.dev/post/51247328

I use speckit, and while I like the spec/clarify/plan/task/analyze/implement loop (although it can get a bit overwhelming at times), I don’t like that I have to start with writing a spec and implement it to begin with. I am looking for a more of a design phase before the spec phase, where I can talk about the overall application architecture, and then start writing specs for implementing pieces of it.

For instance, let’s say I want to build a github repo provisioner that 1. creates repos with desired setup, and 2. bulk edit repos with secret updates, yaml updates, etc. I don’t want to build both the features at the beginning. I want to first build only the create portion, and then do the bulk edit feature later on. With speckit, I can do this by only telling it to create the spec for the build portion, but later if I want to build the bulk edit portion, the whole application might need to be changed in important places, because it wasn’t a ‘planned’ feature when it was first designed. I want instead to have a design phase where I describe and maintain a doc with the whole application, and when I start the spec for the create portion, the agent can understand that this create portion is only part of a bigger application and can design/implement the create portion accordingly.

Have you come across a situation like this? how do you handle your big applications? Please advise.

  • doo@sh.itjust.worksEnglish
    2·
    6 days ago

    I’ve not used speckit and likely reinventing the bicycle, but here’s my process.

    Idea.md in the root with a pitch of the system Readme.md in the root with technical information

    Then I’m using moth (https://github.com/tailoredshapes/moth) to file ideas and track tasks. Those files are definitely not full specs, just several lines of the core of the issue.

    Then I have a command /moth that instructs to read current moth, brainstorm design with me and when agreed, implement. Also as the agent works it should keep an up to date spec under ./spec describing the scope (explicitly no code details) as it evolves, decisions taken and rejected (adr like). It underscores that the task is only done when I say so. Superpowers skill is essential here.

    Then there’s the back and forth on development and testing.

    Eventually another command /moth-done that instructs to run the full test suite and mark moth as done.

    So the essence is that I don’t expect to know the full specification beforehand, but I keep track of decisions and expect to refactor often and aggressively. Conveniently writing tests is now easy and I have plenty of both unit and e2e.