Replace /plan and /tasks with one /spec prompt, instead

[rogadev]

Given that most users will /plan and then /tasks every single time, why are we requiring that they do both of these individually?

Would it not make more sense to provie a /spec that lets the user define their next feature, fix, or update? I would much rather prefer providing one detailed input that generates the plan and tasks. I wouldn't have to think about what should be in my plan prompt, or what should be in my tasks prompt - the /spec prompt should figure all that out from my initial detailed input.

Wouldn't one action not be better at extracting the detail required for both the plan and task building phases? It just seems painfully redundant and unecessary to have to burn more tokens over 2 separate prompt windows, when it could easily have been made to work with a single /spec prompt.

I'm not saying get rid of plan and task, but perhaps offering them as an optional path to creting our spec files, instead of forcing us to 2-shot every generation of these files.

Thoughts?

[jeremyeder]

spec-kit is a set of existing patterns, expressed via slash commands and enabled by LLMs, so I think if you're happy with the ability to customize it to your liking, then the defaults shouldn't matter too much. I doubt we take defaults for anything at all in our developer tool chains, haha!

btw -- off topic:

When you say burn tokens ... I struggle with this. It has always taken money to make apps. I know having /cost at your fingertips makes it obvious, but I've been looking at the cost it takes to build, ship, support enterprise apps for a long time and basically no matter how you slice it, LLMs will reduce overall engineering costs.

Where I have found us spending the most effiort lately is adding additional layers of constraint (better prompts, better models), validation (TDD, traditional QE) and checking (other LLMs check the work) to LLM-developed code. This is because generating code is the cheap part of selling software/running services.

Vibe coding for the enterprise has to be made cost-effective. It doesn't seem to be anywhere close atm.