If you think your approaches to agentic development are somewhat impostor-ish and somewhere out there someone is doing real beauty, that's partly true, of course, but not completely. They're also doing completely random things there and hoping it will get better.
In a nutshell: Spec-Driven Development is when you first make (generate) a spec with requirements, and then the agent writes code based on it. The end.
You've probably been doing this for a long time already, right? Even this post of mine about a working folder for the agent covered this case. So we have SDD with you. No more, no less.
Further - there are several opinionated implementations of this idea. Github Spec Kit for example, or the one built into Kiro from Amazon. Or, there's about the same kit from every other person who's already on familiar terms with agents. Maybe already formalized, or as concepts in the head. I've just gotten to formalizing mine, looking around.
Moreover, when I say that Spec Kit is an implementation of this idea - I mean literally that it just puts several custom commands in Claude Code for you. This isn't some special software, not a framework, but just several prompts that the GitHub team apparently generated themselves. And the content there is an acquired taste.
It very much assumes that you had nothing like this at all. It describes quite specific folders for you, and its own naming rules, and adds some new concepts that overlap with everything existing on the project. There's also an amazingly strange idea embedded in the concept - that the spec can now lie in your repo and this is supposedly useful.
I looked at all this, borrowed ideas, and rewrote the Claude Code content for myself, looking at the current project context. As a result, custom commands:
/spec:specify- meta-prompting that translates your prompt into a spec with business use cases, asks clarifying questions;/spec:plan- translates business use cases into technical language;/spec:tasks- decomposes technical requirements and says how subtasks depend on each other. Can be combined with the previous two if you really want;/spec:implement- takes these subtasks and does as it sees fit.
Well, and everything related to the feature is now generated with a more understandable structure:
- ai/
- feature/
- 20251201_1146_webview_permissions/
- spec.md
- plan.md
- tasks.md
The idea is that we have a fixed pipeline of several sequential commands, each generates an artifact that we read, edit, and go to the next.
And to my taste, artifacts after completing the task can be deleted without regret, no one needs them anymore. I think it's an incredibly naive idea that these generated specs will be needed by you sometime and they'll be just as relevant at that moment. The author gives an example like "what if I want in 5 years to rewrite this from technology X to technology Y". Well, that's naive.
And yes, this all looks like bureaucracy bred out of nowhere and works well (really well) only for medium-complexity tasks that you want to one-shot. There's no point in deploying this machinery in other cases. You can run specify and implement without the rest if you really want to use this kit.
If the task is fairly clear as a whole or not about writing code at all, then forget it and prompt as usual.
In short, the idea is good, but you almost certainly don't need a ready-made kit. Generate your own, it's a matter of five minutes. It's important to remember that this is just an attempt to simplify requirements gathering and prompt writing, so that by the time of task execution all this is ready.