Show HN: I Made a Claude Skill for Spec-Driven Development (SDD) (opens in new tab)

I did some research after reading your and a discord comment i received and i agree that GSD is doing something more complete — full execution orchestration with context rotation. This skill is intentionally the spec layer only: interview → requirements.md + design.md + tasks.md + AI config files as I believe this is a more manageable as well as a core part of SDD to be tackled. I intend it to be composable with GSD rather than a replacement for it. After all even while using GSD one still needs a spec before execution begins and that is the gap I now want to fill.

Also thank you so much for your input, it is always good to have some proper references for a project in it's early stages to avoid redundancy.

It inspects my existing repo, and identified existing logic, then imported my existing functions, and created a checkpoint_manager.py.

The new function adds additional functions like: - update_started - update_completed - update_failed - install_shutdown_handlers - restore_shutdown_handlers - persist_checkpoint

Below points are generated in Implementation Tasks:

3. Implement checkpoint model: - typed checkpoint structure; - schema version validation; - bounds validation for next_url_index. 4. Implement atomic checkpoint writer: <- "atomic" - write temporary file beside final checkpoint; - flush and fsync; - atomic rename; - preserve old checkpoint on failure. 5. Implement checkpoint loader: - handle missing file; - reject malformed JSON; - reject unsupported schema version; - reject URL fingerprint mismatch.

I don't fully understand what "atomic checkpoint writer" means, but the LLM understands what it means. The functions are likely to implement "atomic checkpoint writer".

The key takeaway is that tokens generated by human usually not restrict enough. When I thought about "checkpoint", I wasn't thinking of any "atomic" shape of checkpointing. I was using my casual language model to generate first version of implementation first. Then using Spec-Driven-Development model, the generated spec has better understanding of what it is. There could be many mutated forms of real life implementation of "checkpoint", the LLM generated code is mostly restrictive one that I will never know in my whole life experience. The LLM training must have undergone very restrictive learning process that I never experienced.

First of all, you're right that one-shotting all three docs after the interview doesn't give you a proper review space between requirements, design and tasks. That's a real bummer. The intent was to minimize friction but it loses the ability to catch a bad requirements.md before design.md is built on top of it. I'll be taking this into account for v1.1.

About the interview, the 4-question minimum was a deliberate choice to avoid it from feeling like a form, but for a more detailed approach 4 questions clearly isn't enough. I believe that a follow-up round based on project type (API vs frontend vs data pipeline) would improve first-pass quality significantly but I'd appreciate to hear your thoughts on this matter.

Regarding the versioning, there's a changelog section in the generated templates but it's not prominent. Will make it more visible.

Taking you up on the email offer — will reach out.