r/SpecDrivenDevelopment

How do you go from a rough product idea to features for SpecKit or any SDD toolkit?

I am curious how people here handle the stage before SpecKit (SDD).

I am a big fan of SDD and AI-assisted development, and I strongly dislike vibe coding. I want requirements, design decisions and implementation to remain explicit and reviewable.

For my home projects, I usually use GitHub SpecKit at the level of a relatively small feature or even a focused engineering task. I intentionally keep the scope small so I can carefully review every generated specification, plan, task list and especially every PR.

For example, instead of asking an agent to "build the application", I work incrementally:

  • Create the initial solution and project structure
  • Implement the basic application shell
  • Implement a specific domain component
  • Add a specific UI capability
  • Integrate the pieces in another feature

What I am less sure about is the process before that.

How do you go from a rough product idea to the set of features that you then feed into SpecKit?

Do you maintain something like:

Idea -> Product Brief -> High-level Requirements -> Feature List -> SpecKit specs

Or do you keep only a lightweight product overview and define features incrementally as the project evolves? (This is how I work now)

I am particularly interested in workflows that preserve strong human control and review rather than delegating the whole product decomposition and implementation to an AI agent.

reddit.com
u/OdysseusDescendant — 4 days ago

Will the AI-assisted development model of SDD still be useful in the future? Is it already outdated?

At the beginning of the year, everyone was promoting SDD development, including plugins like SuperPower that implemented SDD harness capabilities. However, it seems like no one is talking about it anymore. Has fewer people been using it? I feel like SuperPower used to trigger automatically when I used CC, but it hasn't been lately. Has anyone else noticed this? Will SDD still be necessary in the future? Or, if the model and its corresponding DeepSeek harness are already well-developed, will we not need to do so much pre-specification work? Can someone answer this?

reddit.com
u/Repulsive_Ant_9943 — 5 days ago

Is text to sql a commodity layer that just increases metrics drift?

Is text to SQL just a commodity layer that increases metric drift?

I see colleagues and industries still obsess over llms generating ANSI SQL while in production the raw syntax generation may easily be the easiest pipeline part. I find bottleneck to be in context engineering, maybe in ontology too. To have antonomous agent querying arr / churn\_rate to apply my data teams precise joints to use active user definitions, filters, rather than hallucinating against raw warehouse labels as it often tends to do

When I connect ai agents or bi tools to Dita warehouses directly (snowflake, databricks) I faced an awful architectural dillema...

To lock warehouse down with rigid views (which bottlenecks my team!)

or

To let clients query raw schemas and then I end up with 15 conflicting definitions of same core CPI

That started to annoy me a lot and I thought if there was any way out, perhaps, moving from gen3 (cloud warehouse-native bi) to gen 4 that people now sometimes talk about, or ai native analytic layers. In such architecture upstream semantic layers like cube dev sit in code (version-controlled by git)

That exposes SQL-first semantic model that seems to remain extensible at query time and seems to allow downstream clients / internal dashboard / embedded app or LLM querying via model context protocol to run adhoc calculations on top of governed dimensions. Would it measure without breaking central source of truth? Probably

But how do you work with this tension between centralized governance and client level query flexibility?

reddit.com
u/annakows — 5 days ago

How do you catch bad requirements or architectural contradictions before implementation starts?

I've been thinking a lot about how much of our software quality process happens relatively late.

We review pull requests, run static analysis, write tests and maybe check architectural rules in CI. But by that point, an important decision has already been made: we decided what to build.

In larger or long-lived projects, I've repeatedly found the earlier stages more interesting:

  • Does a new requirement contradict an earlier decision?
  • Does it implicitly violate an architectural constraint?
  • Is an important edge case missing?
  • Does it conflict with something another team implemented six months ago?
  • Is the proposed change locally reasonable but slowly pushing the system away from its intended architecture?

I'm currently building a side project called BreakMySystem around this idea. It combines adversarial requirement review with architecture-drift detection, with the goal of finding these problems before or during implementation rather than only reviewing the resulting code.

But I'm more interested in how other teams solve this today than in pitching the tool.

For people working on larger or older codebases:

Where in your development process do you catch these kinds of problems?

Architecture reviews? ADRs? Senior engineers knowing the system? Jira discussions? PR reviews? Automated tooling? Or, realistically, mostly when something eventually breaks?

I'd also be interested in talking to a few experienced developers, architects or tech leads about this for ~20 minutes. I'm specifically looking for critical feedback and real-world experiences rather than potential customers.

If you've dealt with this problem, feel free to comment or DM me.

reddit.com
u/AdversarialDev — 6 days ago

SpecKit vs OpenSpec comparison

Hi there! I wrote down an article that compares OpenSpec and SpecKit.

TLDR: SpecKit has significantly more abilities for extending its workflow, but it is also harder to adopt. OpenSpec default workflow looks like more complete and easier, but there are less abilities to extend it.

Article: https://specbuddy.dev/blog/openspec-vs-speckit/

https://preview.redd.it/pb7mu61kvpih1.png?width=1672&format=png&auto=webp&s=4f6a8175adea2843635135a424373f0edf8291f7

reddit.com
u/Bitter-Ad2567 — 10 days ago
▲ 6 r/SpecDrivenDevelopment+1 crossposts

I made my tool compatible with cursor but I don't have cursor subscription to test

Hi people! Because the Cursor's agent and skill layout is slightly different, it took me a while to figure out a way to make my agentic workflow compatible with Cursor.

Would like to know if anyone here is interested in giving it a run and let me know if it works?

I have tested it with Codex,Claude, Copilot, OpenCode etc. and can confirm it is working with those platforms. I have read cursor documentation and added its compatibility layer.

About the tool:

Truthmark is a Git-native documentation curation tool for AI-assisted software development. It installs repository-level instructions and mappings that tell coding agents when documentation should be created, updated, validated, or reorganised as code changes.

Rather than acting as a one-off documentation generator, it maintains small, human-owned, evidence-backed “truth docs” alongside the relevant code, producing ordinary Git diffs that reviewers can inspect with each change.

Cheers!

github.com
u/Middle_Key8737 — 8 days ago
▲ 26 r/SpecDrivenDevelopment+3 crossposts

Ever wondered why GitHub Copilot works brilliantly in some repos and struggles in others? We built a tool to find out.

Over the last year, I've spent a lot of time helping teams adopt GitHub Copilot, and one thing became pretty obvious:

Some repositories seem to unlock Copilot's full potential.

Others have all the right intentions, documentation, instructions, and tooling, yet Copilot still feels like it's operating with one eye closed.

So a friend and I started asking ourselves:

Can we measure how "Copilot-ready" a repository actually is?

That led us to build AgentCompass, an open-source AI Readiness Analyzer that scans a repository and identifies configuration, documentation, and structural issues that can make life harder for AI coding agents.

What it checks

✅ Copilot instructions

✅ Agent documentation (AGENTS.md, CLAUDE.md, etc.)

✅ Skills and prompts

✅ MCP configuration

✅ Context scoping and repository structure

✅ Common issues that can silently reduce agent effectiveness

Instead of using another AI to judge your repo, we took a different approach:

  • No LLM calls in the scoring path
  • No "AI vibes" scoring
  • Same repo + same commit = same result every time

Think of it more like a linter for AI-readiness.

Try it yourself

GitHub:
AgentCompass Repository

Live Demo:
AgentCompass Web App

Linkedin Post

I'd love feedback from this community

A few things I'm genuinely curious about:

  • What makes a repository Copilot-friendly in your experience?
  • What patterns have you found that dramatically improve Copilot results?
  • What checks would you add?
  • Are there things that should only be measured through real-world usage rather than static analysis?

Most importantly:

👉 Run it against one of your repositories and tell me where it's wrong.

Seriously.

If it gives your repo a terrible score and you think it's nonsense, I want to hear that.

If it catches something useful, I want to hear that too.

We're trying to figure out what great AI-native repositories actually look like, and feedback from people using GitHub Copilot every day would be incredibly valuable.

u/West-Move8543 — 10 days ago

I wanted a spec-driven skill. It became Maestro.

At first, I was not trying to build a complete development environment.

I was using OpenSpec inside Cursor with custom commands and Cursor rules. The workflow worked well, but I had a problem:

Whenever I switched to OpenCode, Codex, Claude Code, or another coding agent, I lost part of my setup and workflow.

So I started building a spec-driven skill that was not tied to one IDE or one AI provider.

That project became Maestro.

I believe spec-driven development will become a normal part of software development with AI agents. GitHub’s GH-600 certification focused on agentic AI development feels like another signal in that direction.

How Maestro works

The core lifecycle is:

idea → spec → build → review → docs → archive

You can install it with npm:

npx @bryann2k/maestro

Then run it from the repository you want to work on:

cd my-project
maestro

The typical workflow looks like this:

  1. Connect an API provider or an existing CLI subscription with /providers
  2. Use /bootstrap for a new project or /adopt for an existing repository
  3. Use /propose to turn an idea into a structured spec
  4. Review and accept the proposal with /accept
  5. Let the development agent implement it with /build
  6. Run /review
  7. Generate documentation with /docs
  8. Archive the approved change with /archive

The same lifecycle can also be used through headless commands:

maestro propose -m "Add a PostgreSQL API"
maestro accept
maestro build
maestro review
maestro docs
maestro archive --yes --merge

Maestro can use its native engine, authenticated vendor CLIs such as Codex, Claude, Cursor, OpenCode, Grok, and Kimi, as well as OpenAI-compatible and local providers such as Ollama, LM Studio, llama.cpp, and LiteLLM.

Human-in-the-loop is the important part

Maestro is not meant to be “write one prompt and pray”.

A normal chat message does not automatically create a spec. You have to explicitly invoke /propose.

The generated spec.mddesign.md, and tasks.md are reviewed before they become the accepted contract. Builds run in isolated Git worktrees. Review runs deterministic checks, security analysis, and a read-only review agent.

If the review finds a problem, the findings can be sent back through /fix.

The goal is to make every phase explicit instead of allowing an agent to silently jump from a vague idea to a large code change.

Coach and integrated IDE

I also wanted Maestro to be useful for people who can describe what they want to build but do not yet feel confident reviewing AI-generated code.

The optional Coach mode gives short, contextual exercises around things like:

  • understanding requirements and acceptance criteria
  • reading diffs
  • checking assumptions
  • identifying security risks
  • understanding tests and regression risk
  • reviewing generated code

You can use /learn guided or /learn challenge.

Maestro also includes an integrated code workspace with /ide. You can select code and ask Maestro to:

  • explain it
  • comment on it
  • modify it
  • answer a question about it

So you can review code and interact with the agent without leaving the terminal or losing the current context.

This is still a V1

This is the first public release, so there are probably bugs and edge cases I have not discovered yet.

If you try Maestro and something breaks, please open an issue on GitHub. I will also be using it to build StackDeploy, so I will be fixing issues as I find them.

I’m also in public on X. If you want to follow, it help me a lot!

I would especially like feedback on:

  • whether the workflow makes sense
  • where the spec-driven process feels too heavy
  • whether the human approval boundaries are useful
  • what is missing from the review experience
  • how this behaves with different agents and providers

Thanks to everyone who takes the time to try Maestro, report an issue, or share feedback. It really helps.

u/BryaNN- — 9 days ago
▲ 2 r/SpecDrivenDevelopment+1 crossposts

I built an AI Pomodoro app entirely spec-first — every feature got a written spec before a single prompt. Here's what changed.

I've been experimenting with spec-driven development: instead of prompting an AI agent with vibes, you write a real spec first (user story, requirements, API contract, acceptance criteria), let the agent implement it, then validate against the spec and update your roadmap. Loop until MVP.

The app is a Pomodoro timer where you describe your goal conversationally and the AI proposes a task plan sized in pomodoros ("2🍅 ≈50m"). There's a focus coach mid-session, sound cues, PWA install support, and since it's publicly hosted, a Cloudflare Turnstile gate + per-IP daily rate limit on the AI routes so strangers can't drain my DeepSeek credits.

Stack: Next.js 16, Bun, DeepSeek API, Upstash Redis. No database — plan state lives client-side.

What actually surprised me:

  1. **Specs didn't slow me down**. Six features in, the AI agent was dramatically better when implementing a spec vs reading my mind. Code review became "does this match section F3?" instead of squinting at diffs.

  2. **The spec caught drift.** When the model under-filled a response schema (returned 3 tasks when asked for 3 steps instead of the spec'd 4–8), it was obviously a contract bug, not "weird AI behavior."

  3. **Re-planning after every feature** (updating mission/roadmap docs) is the part everyone skips and the part that prevents the codebase from rotting.

Happy to answer questions about the spec format or the abuse-guard setup — both were more interesting to build than the timer itself.

\- Live: \[https://ai-promodoro.vercel.app\\\](https://ai-promodoro.vercel.app)

\- Source (the \`specs/\` folder is the real content): \[https://github.com/adotey7/ai-promodoro\\\](https://github.com/adotey7/ai-promodoro)

ai-promodoro.vercel.app
u/Friendly_Tap737 — 13 days ago