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.
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.
Wondering if this is attempting what github.com/gsd-build/get-shit-done has done: plan your milestones, discuss them, execute them, review them. It can also review the plans by another agent before execution... Everything documented and checked in.
To be honest, I did not know what GSD was before publishing this skill (nerviousness).
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.
Cool, thanks for the reply. GSD is great for new projects but it burns through tokes at quite the rate. Esp. in quality mode. Something more lightweight would sometimes also be welcome. Though there is /gsd-fast and /gsd-quick that partially fill that gap.. I'll definitely check yours out, thanks for publishing
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.
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.
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.
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.
Still trying it out, but here's my feedback so far:
- Overall the approach is sound, to generate various levels of documents from requirements to finer grained ones
- I'm not sure if that's intended, but I got asked about four questions and then the model one shot all three documents at once, ideally you'd work on one at a time, then once you're happy generate the next level of documents
- The prompting by the model was very shallow, it didn't ask enough questions so the requirements were off. I was expecting more questions so that the model had more information to work with. The docs can be iteratively reworked but I think it should make a better effort at the first take.
- I don't think there's any versioning of documents but that would be useful
- Dispatching subagents to review the generated plans would be nice
Overall it's pretty reasonable, I can see it being pretty useful. Send me an email if you need more details.
This is the most specific feedback in this thread — thank you.
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.
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.
Sure, this skill is narrower and that might be its advantage, if you don't try to make it solve everything but instead if you evolve it to solve some particular use cases.
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.
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.
Wondering if this is attempting what github.com/gsd-build/get-shit-done has done: plan your milestones, discuss them, execute them, review them. It can also review the plans by another agent before execution... Everything documented and checked in.
To be honest, I did not know what GSD was before publishing this skill (nerviousness).
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.
Cool, thanks for the reply. GSD is great for new projects but it burns through tokes at quite the rate. Esp. in quality mode. Something more lightweight would sometimes also be welcome. Though there is /gsd-fast and /gsd-quick that partially fill that gap.. I'll definitely check yours out, thanks for publishing
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.
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.
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.
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.
Sure, I'll take a stab at it, that looks interesting. I'll give you an update in a couple of hours.
Still trying it out, but here's my feedback so far:
- Overall the approach is sound, to generate various levels of documents from requirements to finer grained ones
- I'm not sure if that's intended, but I got asked about four questions and then the model one shot all three documents at once, ideally you'd work on one at a time, then once you're happy generate the next level of documents
- The prompting by the model was very shallow, it didn't ask enough questions so the requirements were off. I was expecting more questions so that the model had more information to work with. The docs can be iteratively reworked but I think it should make a better effort at the first take.
- I don't think there's any versioning of documents but that would be useful
- Dispatching subagents to review the generated plans would be nice
Overall it's pretty reasonable, I can see it being pretty useful. Send me an email if you need more details.
This is the most specific feedback in this thread — thank you.
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.
what are the fundamental differences between Spec-Driven-Development and OpenSpec (https://github.com/Fission-AI/OpenSpec)?
There are lots of more mature plugins doing this: superpowers, get-shit-done, compound engineering, spec kit.
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.
Sure, this skill is narrower and that might be its advantage, if you don't try to make it solve everything but instead if you evolve it to solve some particular use cases.
Have signed up for your testing pool. I think I fall under the non-technical vibe coder #2.
[dead]
[flagged]
[dead]
[flagged]