HN Explorer

Show HN: I Made a Claude Skill for Spec-Driven Development (SDD) (github.com)

40 points by NTRIXLM ↗ HN
At my work they provided a single Claude subscription for everyone on the team. To be honest I like kiro better as it provides a way better SDD management. But the company can't provide it and I can't afford it yet. Turns out I had the skill creator skill in my claude instance so I made use of it to create this Skill. I made it fully by using Claude but I wanted to make it open source, so I asked it to help me make tests and preparations for it, even a CI to run python tests.

Well, we got this results with it:

- Phase 2A: 67 static assertions (Python script, runs in CI)

- Phase 2B: 15 behavioral tests (live Claude Code session)

- Phase 2C: 53 generation quality checks across 3 end-to-end flows

All of these passed and the CI also passed (after a few tries).

I made it to suit my way of prompting and coding and based it off kiro's SDD management, but I want it to be publicly available and used by many people. According to claude some of the testers need to fit the following criteria:

1. Developer starting a real new project from scratch

2. Solo dev with an active side project (greenfield or partial codebase)

3. Team lead whose team uses multiple AI tools

4. Developer with an existing codebase and no written specs

5. Developer who actively uses 3+ AI coding tools

It's actually a blind test, no guiding, just try it if you can, I'd really appreciate your help.

The repo is here: https://github.com/FredAntB/Spec-Driven-Development

15 comments

[ 5.1 ms ] story [ 44.6 ms ] thread
jfim
Sure, I'll take a stab at it, that looks interesting. I'll give you an update in a couple of hours.
bilbo-b-baggins
Look at the juxt/allium plugin. It’s a more mature version of what you’re attempting.

Also big requirements/tasks files will rot your context opening up hallucinations and drift. So I’d guess your starting point isn’t useful for larger codebases.

NTRIXLM
To be fair allium is genuinely impressive, I checked it out and the custom language approach and autonomous tend/weed agents are more sophisticated than what I'm doing with this skill. The tradeoff I made deliberately was to use standard markdown files that any AI tool can read without installing anything. Allium's .allium format requires the skill to be installed to be useful; The requirements.md should work in any editor, any agent, any CI pipeline.

Also, context rot on large specs is a real limitation. I added a lightweight CONTEXT.md journal but nothing close to proper context rotation. That's filed for v2.0.

I'd also like to thank you so much for taking your time to revise this show HN and express that I appreciate your feedback.

v1b3c0d3r
Have signed up for your testing pool. I think I fall under the non-technical vibe coder #2.
sysguru2046
I cloned your Spec-Driven-Development repo to my GitHub repo, use codex to generate a scraper checkpoint manager spec, then use codex prompt to implement the checkpoint logic. The new implementation has significant improvement on top of my original shape of checkpoint logic. It's strict implementation based on generated spec.
NTRIXLM
First of all, Thank you so much for sharing your experimentation with it. Your checkpoint spec generation and implementation against it is a great usecase test to check if the requirements format is indeed useful and not just properly structured.

Would you be willing to share what the generated spec looked like and where it was most useful vs where it needed adjustment? That kind of usecase is really valuable to explore further improvements that could be made.

sysguru2046
Generated spec is 542 lines including 7 sections: - Requirements - Event Schemas - Checkpoint File Schema - Resume Algorithm - Failure handling - Acceptance Tests - Implementation Tasks.

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.

DeathArrow
There are lots of more mature plugins doing this: superpowers, get-shit-done, compound engineering, spec kit.
NTRIXLM
That's fair, gsd, superposers and spec kit are way more mature and complete. On the other hand, this skill is indeed narrower, and as a result currently intended for spec generation only, standard markdown output and allowing work alongside any of those frameworks at the spec later. Different scopes instead of a replacement.

Thanks for your input and the provided references as well as taking your time for reading this show HN.

sermakarevich
Maybe this might be helpful - Spec-Driven Development Workflow for Claude Code https://news.ycombinator.com/item?id=48231575

Its not a single skill, but a set of skill, organized into a workflow with design to be able to /clear the context or restart the session after each step.

There is a chain of specs delivered:

- requirements

- code analysis (optional)

- design (with split task into X subtasks)

- verification

- self-improvement

Each task is implemented in its own session, completely isolated, having clear and focused context.

Also works extremely nicely with a fleet of agents.