I’ve been experimenting with spec-driven development workflows for AI coding, and I ended up building a Claude Code plugin called CodeSpec.
What pushed me to build it wasn’t “how do we generate more specs?”
It was more practical stuff:
work often spans multiple sessions
brownfield projects need code exploration before planning
implementation often leads to small plan changes
interruptions shouldn’t force you to restart from scratch
So CodeSpec is built around a resumable workflow: spec → clarify → plan → tasks → implement → review, with state persisted after each stage.
A big part of the value for me is that it helps with some of the SDD issues that show up in practice:
treating specs as alignment artifacts, not permanent docs humans must maintain forever
supporting iteration after implementation, instead of a one-way pipeline
handling existing codebases better, instead of assuming greenfield
resuming from checkpoints instead of rebuilding context every time
That last part also saves tokens in a pretty real way. If a session gets interrupted, I don’t need to re-feed the full requirement, design decisions, and task progress back into the model. I can just continue from the current stage. Less repeated context, less token burn, less mental overhead.
I’ve looked at projects like SpecKit and OpenSpec, and I think they helped push the SDD conversation forward. My goal here was just to focus more on the operational side of SDD: recovery, iteration, and making it usable for longer-running work.
GitHub: https://github.com/LucivHuang/CodeSpec
Would love to hear how other people are handling longer-running SDD workflows in Claude Code.
Top comments (0)