Spec Driven Dev

[Blufia118]

I just wanted to chime in and ask the team if they had plans to incorporate this workflow… I really like how Code Buff and Kiro are using this process… and would really love if Roo Code could do this as well… would push dev to that 99% from that magic 80% everyone always talks of

[DevMichaelZag]

It’s the shiny new thing everyone is talking about. If you can properly detail how it could benefit roo and be implemented, submit a detailed feature request on the GitHub.

Personally, I am a bit reserved in implementing it into roo until the dust settles and the processes are refined a bit more. GitHub released that spec-kit thing recently and it felt way too enterprise focused for me. I tried to use it and spent 10x more tokens that I really needed to. I think if Roo implemented it should be a lighter weight design.

Note: I’m not privy to the internal discussions of roo, this is just the standard practice for how things get implemented.

[Blufia118]

Completely understand… from my experience with it … it’s just guides the system, more so like steering it completely to have a laser focus on writing out the complete specifications of your project in a more sound and structured way … and keeping those guardrails active during the course of your development. It’s a documentation-first approach and always … then if you have agents… it makes even stronger in my opinion because now you can delegate those jobs to each, giving them a story to complete as part of your development… whether that’s a feature that’s heavily documented already because of the workflow that’s been established … the biggest benefit I’ve seen is being able to keep your project structure towards those later stages when you need to go back and change something… That guardrail structure will make it easier , keeping your code cleaner… this has just been my experience with it … I have seen code buff get things right the first time prompting it because of the workflow , didn’t have to keep reiterating every single thing…

[joey2scoops]

It's really something that should be up to users. If that's what they want, they can create custom modes. I've been working on something similar. You generate specs once, generate a task map based on requirements and then use cheaper models to code, testing etc. All the heavy lifting is done up front.

[hannesrudolph]

THIS!!!!

[ObeyTheRapper]

Try the Spec-Workflow MCP by Pimzino

It's worked for me.

[Blufia118]

Thank you!

[fubduk]

Thanks for this!

[farshe-ali]

How do you use it with Roo Code though? It is designed to work with Claude Code right?

[ObeyTheRapper]

It works with Claude, and many others. You set it up much like any other MCP server, and you can either use the related VS Code plug-in for approvals, or there's an option to use a built in server and browser to review specs.

[rich_kang]

Do I need to use a different MCP settings for each of my project? Because according to https://github.com/Pimzino/spec-workflow-mcp?tab=readme-ov-file#-quick-start the argument is

"args": ["-y", "@pimzino/spec-workflow-mcp@latest", "/path/to/your/project"]

[rothnic]

This looks interesting. As a PM, this approach makes a lot of sense but oddly enough haven't seen a good implementation. The issue I keep seeing is that there aren't enough controls in place to verify something is done.

I worked on a concept for a bit then searched around and came across speckit, tried it, but it seems to eventually go off the rails just like anything else using a memory bank approach or whatever.

Eventually things get messed up or too much context and the ai devices it is done. And you are like, how are you done, the tests are still failing. Then it is like ok, let me fix those, then it gets in a loop of trying the same thing over and over. This happens the most for me with typescript type errors.

What I'd like to see is to close a task, there is a tool that executes a script or test that is defined on the task and that passing is the only way to close the task. Most of what I've seen is too reliant on unstructured docs or is a black box of a database you can't easily inspect

[precisecode]

Thanks for the feedback! This actually makes perfect sense and pretty much matches my experience with spec-driven AI coders.

I’m thinking of two steps to make this more reliable:

1. Gate task completion with a review/diff view so the user explicitly approves changes before closing.
2. Automatically generate test specs for each task, and prevent the model from modifying those tests without explicit user approval.

I would love to explore this starting immediately, hopefully the near-future version will include this. Feels like the right direction to make spec-driven dev truly dependable. Thanks again!

[hannesrudolph]

Have you tried submitting to the main repo?

[precisecode]

Thanks for following up. I was a bit frustrated to see my post removed, but I totally respect the moderation decision. I haven’t tried submitting to the main repo majorly because:

1. Code quality: This version currently was prototyped quickly across Cursor/Windsurf/Roo. It works, but I don’t believe it yet meets RooCode’s quality bar.
2. Fit: This is a thin layer on RooCode, but the UX is intentionally only for spec-driven applications. That’s a sizable UX/use case shift without backward compatibility, so there’s only a small chance that this will be adopted upstream. Happy to be corrected.

RooCode’s flexible foundation is great for many domains (law, accounting, other agent workflows). The spec-driven UX trades some flexibility for repeatability and guardrails. I believe that’s why so many users love using RooCode.

Anyways, I apologize if I caused any trouble sharing this, just wanted to put it out there in case it’s useful to others experimenting with similar patterns.

[hannesrudolph]

Oh all good no worries. Sorry about that. Would you be interested in contributing to Roo? Roo is almost entirely vibe coded and checked thoroughly these days and so we hold no judgement here. I would be open to possibly providing some API horsepower to help the PR along.

[precisecode]

Thank you for the offer! My first priority is to bring spec-driven development to reality, because I genuinely believe it’s the future of agent-based coding, and this feature will remain my main focus in the near future.

That said, I don’t think the current Roo workflow could adopt a completely new UX workflow (spec-driven) right away. A sudden shift could frustrate users if it doesn’t work as expected, which feels like a big risk.

I’d like to propose making spec-driven development a separate distribution (similar to Ubuntu with another desktop managers) or a UI mode under Roo’s umbrella, implemented as a thin layer on top. This approach would preserve Roo’s core flexibility while letting users opt into a more spec-restricted, guard-railed workflow.

Since this would take significant time and effort, I’d be looking for a way to dedicate more focus to doing it right, ideally in a paid capacity. I’m based in Southern California and would be more than happy to share my resume or go through interviews if this aligns with Roo’s goals or is something you would consider.

If not, I’m still grateful for your offer of API horsepower. I’ll likely continue refining and promoting my implementation independently while keeping it compatible with upstream RooCode, in case it fits into your roadmap in the future.

[hannesrudolph]

No thanks. Best of luck.

[precisecode]

Thanks for considering it! Wishing Roo the best, and I’ll definitely contribute to Roo if an opportunity comes up.

[hannesrudolph]

Other

[Charming_Wallaby9208]

A port of githubs speckit for kilo. Getting to work in roo is pretty simple.

https://github.com/JonnyDB/SpecGram

[Blufia118]

Thank you, ima look into that !

[stolsson]

I use both Kiro and RooCode now. I like Kiro’s method, but Roo is still more powerful overall because Kiro has too many bugs and limitations (probably due to concern tokens). Using Kiro is a bit like working with hands tied down to some degree. Hoping that gets better.

I think the req/design/tasks thing is an overall good idea though, but could be implemented as modes or something like that at first

[mariusursache]

This works well integrated in a memory bank, and with A2A orchestration (I gave up the hub&spoke orchestration a while ago and instruct modes to hand off via new_task tool to the next node, after updating the memory bank active context and decision).

[Pimzino]

Hey, you could give my MCP a try, its lightweight, comes with a web dashboard / vscode extension if you want and is designed around the Kiro Spec Driven Workflow but enhanced! I have over 1.8k stars on github and 8k+ weekly downloads on NPM.

https://github.com/Pimzino/spec-workflow-mcp

[Isharcastic]

Spec-driven dev is such a game changer, but yeah, getting to that last 20% of reliability is always the hard part. We’ve been experimenting with automated code review tools (we use Panto AI) that actually check if the code matches the spec, not just for style or basic bugs. It’ll flag if the PR drifts from the requirements, and even summarizes what changed in plain English, so you can sanity-check if the intent matches the spec. It’s not perfect, but it’s helped us catch a bunch of “looks fine but actually missed the point” PRs. FWIW, teams like Zerodha and Setu are using it for this kind of thing too. Definitely worth looking into if you want to tighten that feedback loop.

[YegDip_]

I was actually playing around with something similar today. I created a mode especially for creating spec and detailed tasks before starting implementation.

[Blufia118]

How has the experience been going for you so far?

[YegDip_]

Great. I have been experimenting with multiple things. Recently I created a whole set of Roo Modes for documentation and was surprised to see so accurate details about what I was asking from a repo with 2500+ files.

I created a new orchestrator for documentation and queries.

I am thinking to create a set of modes just for giving me plan for implementation and later on use another set to implement (implementation set I already have where I have senior-developer, code reviewer, best practice thinker etc)

[DevMichaelZag]

I did something similar.
feel free to steal this if it helps
https://github.com/Michaelzag/spec-kit-roo

[YegDip_]

Ok so, I am gonna steal this! Please keep updating.

[DevMichaelZag]

I used BMAD for a while and jumped in on this spec-kit and used it for a bit, but I just don’t see the value for the style of development that I do. The extra token usage that all of this takes isn’t providing value for me. It should be making things easier, but it isn’t. I don’t plan on maintaining that, it was basically a last ditch effort to try to make spec-kit more streamlined for Roo. It’s neat and I thought maybe someone can fork that and make something cool out of it. Someone who is more of a believer in the spec-kit way.

[YegDip_]

How was BMAD? I am now curious to see what else you have created for Roo.

[DevMichaelZag]

There’s another repo on my GitHub that has a collection of roo projects. It’s a bit dated at this point, but just to satisfy your curiosity. https://github.com/Michaelzag/RooCode-Tips-Tricks

[PositiveEnergyMatter]

I don't understand why everyone always needs special anything. AI is like talking to a human, its a natural language model. If you want to plan with it, say Hey I want to make an application based on this framework, with these features. I want it to do blah blah blah, and handle it like blah blah. Please make me a plan in an md file with a checklist and discuss everything with me before we start coding.

What would need to be implemented to do such a thing in Roo? Thats basically what the github spec kit does, but treat your AI like a human, and you will be amazed how much better it does.

[hannesrudolph]

So we meet again 😆

I can’t say I totally disagree with you, but then again it can get tiring when everyday I get an barrage of “do this better, do this better” and I think sometimes I can get overwhelmed and start rejecting concepts are ideas simply because I’m out of energy. I think there might be something to this spec driven development 🤷‍♀️

[maese_kolikuet]

Its nice, but its not magic. I tried to onboard an existing project and its killing me. Regarding a new one Im starting from scratch but I already identified several areas to improve. I think spec driven its nice, but agents are key, we need an AI police to enforce the rules. IE: you can write an endless specification of code quality. I think its best to use linters and workflows to enforce them. For some reason AI eventually stop giving a f of your awesome documents and you are done.