Build a Claude Code plugin for SDD workflows that’s actually different – and it can survive interruptions, like, for real

Luciv Huang — Sun, 10 May 2026 08:30:29 +0000

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.

Forem: Luciv Huang

Build a Claude Code plugin for SDD workflows that’s actually different – and it can survive interruptions, like, for real