Spec-Driven Development Workflow for Claude Code: Decomposition & Context Clearing

A new open-source plugin called Spec Driven Development Workflow (SDDW) aims to improve Claude Code's performance on complex tasks through structured decomposition and context management. The approach, shared on Hacker News by developer sermakarevich, is designed for mid-to-large projects where Claude's built-in plan + code mode falls short.

Key Concepts

Two-dimensional decomposition: First, generate specs in multiple steps (requirements, code analysis, design). Then split the implementation into subtasks and execute them one by one.
Context clearing between every step: After spec generation and after each subtask implementation, the context is wiped. This keeps costs low and focused, boosting performance.
Specs written to disk: Persistent spec files maintain information across sessions, preventing loss when context is cleared.
Layer-by-layer delivery: Deliver specs incrementally to catch misunderstandings early.

When to Use It

According to the author, SDDW is not a replacement for Claude's plan + code mode when that works well. It's for scenarios where plan + code fails because the feature is too complicated. The double decomposition helps reduce confusion and improves success rates on complex tasks.

The author also notes that SDDW works well with a fleet of agents — you can insert the sequence of SDDW steps into a queue and let multiple agents handle subtasks.

Comparison to Other Tools

Compared to tools like GSD (Generalized Spec-Driven Development), SDDW is tailored for mid-size projects. GSD was great but token-heavy for smaller tasks. SDDW allows adjustments to typical project sizes.

Critiques from the Community

Some HN commenters raised concerns:

Agent adherence and laziness — even with a detailed spec, agents may still produce outputs that require significant sanding and polishing.
No formal benchmarks — the author acknowledges that measuring success is subjective, but claims that when plan + code fails and SDDW works, it's a net gain.
Specs as non-runnable code — a detailed enough spec is nearly equivalent to code, so the overhead may not always be justified.