HN Explorer

Show HN: Spec-Driven Development Workflow for Claude Code

20 points by sermakarevich ↗ HN
Spec Driven Development approach allows to squeeze more from coding agents thanks to few strong concepts: - decomposition across two dimensions. first you generate specs in multiple steps (requirements, code analysis, design), than you split task into multiple subtasks and implement them one by one - you clear context between every step - after spec generation and after subtask implementation. this helps keep cost low and context clear and focused which boost performance - specs written to disk help with information persistency - delivering specs layer by layer help to catch early when agent got you wrong

Repo with claude plugin for spec driven development: https://github.com/sermakarevich/sddw

10 comments

[ 2.9 ms ] story [ 24.5 ms ] thread
siliconc0w
I've been using agent flywheel workflow which is similar. Still not completely sold - it feels a bit like using power tools to shape wood but the final product needs a lot of sanding and polishing.

I thought initially this meant that the spec wasn't detailed enough but the problem is more agent adherence and laziness.

sermakarevich
I am trying to simplify and decompose task, keep my context clean/focused and validate my instructions in this case.

I look at this as if there is a boundary of complexity behind which agents become behaving funky - we just need to find it. Its obvious that with simple tasks and clear instructions, agents don't have issues with adherence. This starts happening at some point when complexity is too high. We need to find this boundary and try to push it with approaches available on our side

aaronbrethorst
I'd love to see a comparison with other spec-driven development tools for Claude, like OpenSpec and Superpowers. How does this compare and contrast with them?
zihotki
Are there any benchmarks/evals to see if this particular one is doing anything good comparing to, let's say, plan mode? How do you measure it actually works and you don't waste tokens and your personal time?

I fail to see any backing for claims 'boosting performance' and 'keeping costs low'

NBenkovich
Decomposition is definitely needed as tasks become more complicated. I’d prefer to define the desired state, get a decomposed breakdown of the gap between the current and desired states, and let agents figure out how to close it themselves, rather than manually operating each intermediate task. As a project owner, I’d love to work at the desired-state level.
sermakarevich
I started using sddw with fleet - another app I wrote to orchestrate a fleet of coding agents https://news.ycombinator.com/item?id=48256389. I just submit a sequence of tasks chained into a sequential exectuion:

- fleet config set model=sonnet coder=claude

- fleet bd create --title "/sddw:requirements <task-name> task description is in TASK.md --auto"

- fleet bd create --title "/sddw:code_analysis <task-name> --auto" --deps <prev task id>

- fleet bd create --title "/sddw:design <task-name> --auto" --deps <prev task id>

- fleet bd create --title "/sddw:implement <task-name> --task 1 --auto" --deps <prev task id>