Hi! I'm using spec-kit extensively as a spec-driven development tool.
The standard 4-step workflow works extremely well for medium to large changes. It forces structure, reduces ambiguity, and guides the implementation process in a predictable way.
However, this workflow behaves the same regardless of task complexity, and this becomes inefficient for very small tasks.
For trivial changes like adding a simple button (I'm exaggerating, but you got the point) the current workflow generates a large amount of scaffolding.
Example repo (adding one button):
Commit: alfonsograziano/kanban-board@068baef
→ 30 files changed, < 20 actual LOC.
This also results in significantly more token usage and compute cost than necessary, which makes spec-kit impractical for small tasks that developers perform multiple times per day.
One possible approach might be to introduce a new command. Something like speckit.tinySpec. I'm already doing something similar in my projects, and it's the right balance of spec completeness and speed of execution.
This would generate a single lightweight spec file that includes context, implementation plan, quick list of tasks.
All contained in one file, without branching into the standardstructure. This gives users a fast, minimal overhead workflow for small changes while still keeping spec-driven development principles.
A follow-up Improvement might even be having an automatic router (similar to what ChatGPT does for reasoning effort)
The spec-kit entry point could automatically detect task complexity and route accordingly:
Small tasks → speckit.tinySpec
Medium/large tasks → standard workflow
The complexity check could be an simple LLM-based classifier with an optimized prompt to analyze the user request.
This approach would be similar to what the BMad Quick Spec Flow works. I've used it in a few cases and it works so well! Then, of course, for big features, you will still rely on the normal spec-kit flow.
Are you already working in this direction? I'm not sure if I'm misusing spec-kit, or if having a lightweight alternative approach for simple tasks would make sense. If that's the case, I'd love to start working on a first PR to introduce a new command!
Hi! I'm using spec-kit extensively as a spec-driven development tool.
The standard 4-step workflow works extremely well for medium to large changes. It forces structure, reduces ambiguity, and guides the implementation process in a predictable way.
However, this workflow behaves the same regardless of task complexity, and this becomes inefficient for very small tasks.
For trivial changes like adding a simple button (I'm exaggerating, but you got the point) the current workflow generates a large amount of scaffolding.
Example repo (adding one button):
Commit: alfonsograziano/kanban-board@068baef
→ 30 files changed, < 20 actual LOC.
This also results in significantly more token usage and compute cost than necessary, which makes spec-kit impractical for small tasks that developers perform multiple times per day.
One possible approach might be to introduce a new command. Something like
speckit.tinySpec. I'm already doing something similar in my projects, and it's the right balance of spec completeness and speed of execution.This would generate a single lightweight spec file that includes context, implementation plan, quick list of tasks.
All contained in one file, without branching into the standardstructure. This gives users a fast, minimal overhead workflow for small changes while still keeping spec-driven development principles.
A follow-up Improvement might even be having an automatic router (similar to what ChatGPT does for reasoning effort)
The spec-kit entry point could automatically detect task complexity and route accordingly:
Small tasks → speckit.tinySpec
Medium/large tasks → standard workflow
The complexity check could be an simple LLM-based classifier with an optimized prompt to analyze the user request.
This approach would be similar to what the BMad Quick Spec Flow works. I've used it in a few cases and it works so well! Then, of course, for big features, you will still rely on the normal spec-kit flow.
Are you already working in this direction? I'm not sure if I'm misusing spec-kit, or if having a lightweight alternative approach for simple tasks would make sense. If that's the case, I'd love to start working on a first PR to introduce a new command!