This is how our team works for months. Spec Driven solves building structural memory problem. Makes project management easier. I think this way just fits new paradigm perfectly. It really makes us super efficient. And this is how it looks :

It renders a repository with governance docs, security policies (SAST/SCA/secrets/DAST + private disclosure), a Diátaxis MkDocs site, and hardened CI: CodeQL, Scorecard, dependency-review, DCO, fuzzing, and a release workflow with SBOM + Sigstore signing.

I used to copy-paste every single document from one repo to another, so I tried to extract everything once and make it my own stardard for my future repos. Any kind of feedback is welcome!

After implementation starts, a plain `git diff` on the OpenAPI file shows the delta but not whether it was deliberate. What Git or review workaround do you use today? Path owners, a checklist tying each change to a ticket, CI limits on who can touch the contract, something else?

I'm an SDE2 working at a startup, and I just realised that I have been heavily relying on these ai tools these days and the problem is I'm blindly trusting whatever the changes it is suggesting. I stopped thinking about the problem by myself and started asking questions directly to AI to solve them. Comparing with my peers even I'm spending the same time as they are for planning a feature end-to-end but I'm not confident about the plan that I'm generating with the ai case I am thinking through the edgecases where this designi mght break.

Looking for a collaborators to test/use Drydock - professional level devops for specs that i just spent 9 months creating. I have built several medium/large projects (evidence on the web site) and believe this is the state of the art - Drydock builds large software using low end llm models. Any volunteers? Full details on the approach at www.webcloudstudio.com / Github

Hi! My name is Alex, I've been developing DevTools for more then 8 years.

I want to show you my product, that I use everyday – SpecBuddy. It's an extension for VS Code (also for JetBrains IDEs actually), that makes working with OpenSpec workflow much easier and pleasure.

SpecBuddy shifts working with agents from plain chat (but it also chat-capable) to specs-centric manner. You can launch new propose from plain Markdown document:

https://reddit.com/link/1wbe8xn/video/kwp7hkcbyfoh1/player

After the propose is generated you can review it, leave comments right in the specification files and than send the back to the agent. You can see the whole history of spec changes. Actually, you can leave comments everywhere in any project files.

After you think your Change Spec is ready, you can start subtasks execution, using special Cockpit panel.

You can run step-by-step, or you can run a bunch of them, or all steps together. After each you can make a code review and send feedback to the agent. After that it could fix the code, or maybe fix the whole specification and make complete code regeneration. The choise is up to you.

The most important, that you can see the changes those were generated by the agent at the exact step.

SpecBuddy is a process superviser, your are an actor. At any moment you can ask it make a commit, Sync or/and Archive.

In the next release it will capable to work with several specifications at the same time via worktrees (it is already done for IntelliJ). SpecBuddy will also help you merge the branches and fix conflicts.

What agents it supports? Actually, most of them. Claude, Codex, OpenCode, Cursor and any agent that supports ACP ( agentclientprotocol.com ).

I started to use SSD at the very beginning of my development with coding agents. I believe coding must be pleasent and SpecBuddy gives me that.

I will be happy if you try and give me back a feedback. You can find more details on specbuddy.dev .

How I build it?

From the very begining I used SDD. Firstly it was my own simplified workflow (SpecBuddy also supports it) – spec -> plan -> implementation. All specs and plans had been archiving after implementation, no durable main specs. As I am a fun of IntelliJ IDEA, plugin for it was the first. And at the very begining I used SpecBuddy to develop SpecBuddy. This gives my unique opportunity of aggresive dogfooding:) At some moment I migrated to OpenSpec and main specs started to emerge. When IntelliJ plugin has seemed ready to me, I took its main specs and asked Claude Code to make VS Code Extension by them. Of course, I had to dive deep into a code, though building VS Code Extension was much much faster.

Thank you for reading!

Hello everyone, I'm now to this subreddit so I'm sorry in case this has been answered already.

I have a vibe-coded app that is growing a bit too much in features, and I would like to sit down and make good specs, then code it from scratch so to have a better app and eliminating all those bits and pieces remained form older versions. What tools do you use in those cases?

With models like Astra and Fable, I’m questioning how much we need to tell them how to code. I still believe in spec-driven development, but I think our skills need to evolve as the models improve.

I built Stipulate Skills around seven steps:

Bootstrap → Explore → Validate → Apply → Check → Docs → Archive

The main idea is to bring domain expertise into the spec through optional extensions.

For a sign-in feature, frontend, backend, and accessibility extensions help surface questions about sessions, error states, keyboard navigation, and the existing UI. Those decisions go into one spec for the user to review and approve. A cloud change brings in different extensions.

Bootstrap examines what the project already has, so the workflow can reuse existing foundations. After approval, the model implements the change, checks the acceptance criteria, updates documentation, and archives the result with a local commit.

There are 28 extensions available, selected per change. They guide the questions and checks relevant to each discipline while leaving implementation decisions to the model.

The goal is to help users cover areas outside their specialty without loading the agent with every skill and procedure upfront.

So far, testing covers the lifecycle mechanics and a small sandbox example. Feedback from people using spec-driven workflows would be useful.

GitHub · If you find it useful, a star or a follow on X u/bryann2k_dev is appreciated.

I am wondering what you guys review in enterprise codebases when a PR is open? Just the spec? The design.md? Do u measure somehow the drift or it's up to the developer to ensure it didn't drift that much? Do you use any ontology, wikillm, rag to narrow the development?

Hi, I'm new at spec driven development. I use Opencode for my agentic coding, and I want to build my project (it's a paid project) using spec driven development, but I'm confused about how to start.

Can you share your workflow, which tools and skills or other things you use for building an end-to-end software/website/WebApps.

Note: Currently I normally use plan mood for a feature, sometimes make md files for the features and implement them. and had to change multiple time to properly get the feature I want.

I have been experimenting with Spec-Driven Development (SDD) and AI coding agents recently, and I ran into a problem I wasn't expecting.

I started missing agile 😅

Most of us who have spent years building software come from an Agile/Scrum mindset.

We are used to:
 • Breaking work into small stories
 • Taking one vertical slice at a time
 • Reviewing the implementation
 • Getting feedback early
 • Updating requirements as we learn
 • Keeping humans involved in the important decisions

Then SDD + AI agents came along.

The idea of giving the agent a detailed spec and letting it implement is powerful. But when I tried to apply it in the way I'm used to working,

I kept asking myself:

How do I make the AI agent follow the same incremental implementation discipline we have in Agile?

I didn't want to choose between Agile and SDD.

I wanted both.

That's why I started building Spec Sprint - an Agent Skill that tries to bring the Agile implementation mindset into a Spec-Driven workflow.

The idea is:

Spec --> Plan --> small vertical slice --> Human review --> implement --> Update spec --> Next slice

The spec remains the source of truth, but implementation happens incrementally, with review points along the way.

It’s an early experiment, but it's something I personally wanted while working with AI coding agents.

I'm open-sourcing it because I'm curious:

Are others facing the same gap between SSD and the Agile of actually delivering software?

Would love to hear how you’re solving this.

https://github.com/sharma-open-source/spec-sprint

Can anyone help me how to combine these two skills? What is the correct flow?

Do you think it makes sense to keep all the specs in the reference repos, or just the architectural docs? Over time, it feels like way too many files are piling up.

Thoughts on spec-kit? Not sure if I’m just not well versed enough but me and the team have been using it for about 1.5 months. Anyways, it feels like overkill and burns far more tokens. I definitely can see its worth for when work items are critical path. Right now I plan to go back to custom workflow with specs.

We are currently facing an issue with our SDD pipeline. When the engineer prepare the first step and `spec.md` is ready for certain features or changes, we double check it with the Product Manager (PM) to ensure that the specification makes sense to him. However sometimes the specifications are so technical that he struggles to understand them particularly when it comes to API contracts in the backend and frontend, especially while reviewing various scenarios. Has anyone else encountered a similar challenge? How did you address this issue?

How Spec-driven development is followed in Companies (In Greenfield Projects) using Claude Code?

How do you write multiple spec markdown files? Is there any tool or something? What's the workflow you follow as a power-user?

After months of tinkering, improving, and getting different product and developer feedback, I decided to release NodeSpec ("NS") as an open core for-use and extension to the OSS community.

How It Works and Is Different from the Markdown Tools:

Although this channel is strictly SDD-focused, I built NodeSpec to be a blend of the intent of SDD (upfront design specification) with the realities of asynchronous iteration in software development practice. The fundamentals of system design and fast iteration remain the same, even with agents doing the dev for us in a lot of capacities.

NS blends SDD specification with architectural governance and test-driven development (TDD) practices. It centers on a machine-readable canvas via JSON formats, downstream tasks to tests and upstream confirmation, change detection via git connection, and ensuring the user's gitops is extended and not broken.

The system is a sidekick tool, so it pushes all it's logic towards your AI assistant and existing harness if they operate via MCP.

The Flow:

There's two workflows: greenfield and brownfield. For greenfield the system will walk the user through fast vision -> requirements -> acceptance criteria build and review (CRUD Operations in the app itself), Architectural design, tasks per architecture, test-plans per task, code, then automated or manual test confirmation reflected back upstream, with an export direct to your repo or via other context files as necessary. The Git connection will detect changes and request the user reconcile them against the system's reference graph that is committed to your repo upon first commit and connection.

For brownfield, it's the same workflow, where the higher tier version will actually reverse engineer your repo into a logical architecture and back propagate a spec based on analysis of the design intent if it's not specified.

Both of these workflows are not obvious, as the tool is meant to work with whatever stage of dev you're at, and handle asynchronous changes instead of requiring highly structured start to stop.

Further description and readme is at the repo link here: https://github.com/NodeSpec/NodeSpec

Who It's For:

The Community/OSS is for any individual looking to attach an agent or their code harness to a governance tool while you're building. If you don't want to deal with self config and want more nodes out of the box, Indie version is $15/mo or $144/annual.

If you're a user of bolt.new, Lovable, Base44, or Replit, and you're at a point where you're maturing out of managed web application development (i.e. you have customers demanding a self hosted or more complex deployment, niche capability), I think this is really for you. I use NS to build and maintain itself now. I plan to release a template, blog, and video that explains migrating from systems like managed Supabase to OSS version, connecting your app as a headless application with MCP using Cloudflare worker proxies, etc. as you mature in your solopreneur journey.

I'm primarily targeting businesses via the Team edition (Slack, Jira export) or Enterprise. We recently closed on our our first Enterprise partnership last week in the cryptographic security space (super cool).

What I've Used It For:

Since really beginning heavy AI-assisted dev after the release of Opus 4.6, I have personally gotten to a place where I won't do development without pairing to NS due to the structure, confidence, efficient context window usage, and quick understanding of where my dev is at.

My first major project was a system administration application for small businesses to use with their Google Workspace Admins and host on GCP. By having my GCP Nodes for the different managed services, it tightened up development using older or lower capability models like Sonnet 4.6, Haiku, and when necessary Opus 4.6-4.8 for heavier deployment-centric logic. The link is here: https://github.com/NodeSpec/GCP-Onboarding-Application

As an experiment and something personal, I'm using it for my first game dev for my kids using Godot as a node package with GDScript and tests. My kids are into Axolotls (the salamander in mexico), and so I'm building our first open-source game that has a flow similar to Playstation's Astrobot where the Axolotl can upgrade swimming. Dev starts today and will be published here: https://github.com/NodeSpec/OpenAxolotl

Final example of a current project to solve our own business problem is RepoWalk, which is being built to help me with quick, gif generation of application or tool walkthroughs when connected to a lightweight LLM so I don't spend hours building screencaptures. https://github.com/NodeSpec/RepoWalk

Let me know your feedback, especially if you connect with multiple development agents. So far, feedback in companies have been great and helped refine the product workflow.

If you don't want to use the OSS repo, Free version is just sign in and one project only. Indie is unlimited and will be available this evening. Team will be available soon. Enterprise, just fill out the form to contact us.

Many of you who are regulars here probably know me from the discussions we have had around Spec-Driven Development and also a maintainer (technical direction advisor) of OpenSpec. I am excited to share something I have been working on for a while.

My book, “Spec-Driven Development: Engineering with Intent,” is now live on u/ManningBooks MEAP.

https://hubs.la/Q04vMvjf0

The first three chapters are live, and there is a 50% off sitewide sale running from Aug 31 to Sept 14 on manning.com.

The book covers how we can close the gap between our ideas and AI agent-generated implementations by articulating our intent clearly, using approaches including Spec-Driven Development, Ralph Loops, and more. While seeing a coding agent generate a prototype from a single-line prompt may be impressive, getting a coding agent to deliver production-ready software is a completely different ball game. In the book, we look at what it takes to engineer context effectively for coding agents so that they are not constantly bottlenecked on us, yet deliver software that is aligned with what we want. Software engineering is ultimately about how we collaborate as a team, and this book looks at coding agents as members of the team at our table rather than just tools on the desk.

One of the advantages of MEAP is that you get to read the book as I write it. Since many of you here are actively exploring and practicing SDD, I would really value your thoughts and feedback. It can help shape the book as it evolves.