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.

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.

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.

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.

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.