A hands-on comparison measuring the exact number of actions required to reach the first usable prompt in OpenSpec, GitHub Spec Kit, BMAD Method, and Kiro.
Adapted from @SSShken# 8 clicks or 54: what four spec-driven tools actually cost before you write a line of code Yo guys, today I'm starting a series of articles to help you pick a workflow for AI coding agents, and to figure out how useful these tools actually are and what you really have to do before you can use them. Not what the promo videos say, that you'll have full control over your AI context in a minute. The first one compares four tools: how many steps it takes to get to the first prompt and actually start writing code. The next ones go further, how many steps after that, and what's inside those prompts. So the tools that we're gonna test today are: OpenSpec github.com/Fission-AI/OpenSpec (https://github.com/Fission-AI/OpenSpec) GitHub Spec Kit github.com/github/spec-kit BMAD Method github.com/bmad-code-org/BMAD-METHOD Kiro (IDE) kiro.dev # The rules Before the numbers, three definitions, so you can check my count instead of trusting it. An action is one thing I do with my hands: a click, a keystroke I have to think about, a command I type, an answer I pick. Waiting for generation is not an action. The first prompt is the first workflow command I can actually send to the agent. For some tools that command carries my idea. For others it doesn't, and I say so in that tool's section. A hidden action is one the tool doesn't tell you about, but without which nothing works. Those are counted separately at the end of each section. And one rule I follow everywhere: when a tool offers options, I take the one marked recommended. If nothing is marked, I take the first one in the list. As the model i used Claude Code with Opus 5 on high effort, except Kiro, which runs its own agent and picks the model itself. Everything will be counted manually, without any automation or AI, so I can feel like a real user who decided: alright, I wanna take over my AI daily life, and try OpenSpec. # # OpenSpec What the README says > Node 20.19+, two commands, that's it. npm install -g @fission-ai/openspec@latest openspec init There's also a new workflow they push on the front page, /opsx:propose "your idea", so that's the one I measured. ## What actually happened Install took 6 seconds, 80 packages, no errors, no questions. The installation instructions feel really simple and don't require anything complex based on my experience. openspec init opened a welcome screen and told me right away that it collects anonymous usage stats and how to turn that off. I'm completely okay with that if it really is anonymous. But I know that for some of you guys it's an issue, so let's see what comes next. Actually, it depends on the result, if it's good enough, I guess we can close our eyes. Then a list of 40 tools to pick from. Claude Code was fifth. I love this minimalistic style and small controls. There are 40 options in total, even Kiro, which we're gonna test later. Choosing Claude Code as the main tool. Setup done. Four actions so far. ## ## What it put in my project .claude with 6 skills and 6 commands, and openspec with changes, specs and config.yaml. So I got ".claude" and "openspec" inside "openspec" haha. Love that no git repo required, no existing project required, no account, no API key. ## ## Then I gave it the idea /opsx:propose "A single-page web app for planning a week: seven day columns, add a task to a day, mark it done, everything stored in the browser." It asked three questions in one form: stack, week model, task actions. Every question had one option marked Recommended, so will be going with "recommended" in this article. I know most of you would do the same and keep watching Spider-Man (haha just joking, continuing). Honestly, I'd like not to have a stack question anywhere. I don't think it should be asked if the user doesn't ask for it, but that's just my personal opinion. 3 minutes 9 seconds later, I had proposal.md, spec.md with 7 requirements and 18 scenarios, design.md and tasks.md with 17 checkboxes. And a line telling me exactly what to run next: /opsx:apply. ## ## The Things I didn't expect It wrote down its own assumptions in a list, so I could see where it decided for me instead of asking. It flagged a weak spot in its own plan before I built anything: no automated tests, and why it left them out. Weird that edit task is not included in the recommended options, it's a small thing but you all know how important this feature is. OpenSpec: 8 actions to the first prompt, and the same run produced the full plan with tasks. 0 hidden. # Spec Kit What the README says > Requires uv, no minimum version given. I have 0.12.10. The description of the tool is quite similar to OpenSpec, I don't think I will see something revolutionary in the description, but Spec Kit says I can bring my own workflow, I guess we will get back to this in future articles. Alright, enough talking, let's get to the installation. This one already seems a bit piled up: uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z specify init my-project --integration copilot cd my-project The README then says: replace vX.Y.Z with the latest release tag, keeping the leading v. So the command they give you isn't working; you have to go to the releases page, find the latest tag yourself, and paste it in. New tags come out once or twice a week, so either they release too fast to keep the README updated, or they're just lazy 🤔. That trip to the releases page is the one hidden action in this whole article: the README doesn't count it as a step, but without it the command doesn't run. Right under it they give a second install command from PyPI, uv tool install specify-cli, with no tag to paste. I'm measuring the first one, since that's the one they lead with. Tbh I have a good background with CLI, switching versions and so on, but I never liked looking for these things, for me specifically, that's confusing. copilot is what they put in the command by default, so let's find the option for Claude Code. Found it, I just replace copilot with claude. To see supported tools, you either run specify integration list, or go to the integrations page in their docs. ## What actually happened The install itself took about 4 seconds. 15 packages, one executable: specify. No errors, no prompts. specify init took the --integration claude flag without asking about the agent, but asked its own question instead: script type, sh / ps / py, with sh preselected. Asks for some script to choose; confusion is still with me. I would go with Python because it looks the most familiar to me, but we're going with the proposed options, so let's just press Enter. Project ready. The initialization was really fast and I got a list of commands and skills. It also warned me that agent folders can hold credentials and recommended putting .claude/ into .gitignore, that's a big advantage. But here's the thing: that's four actions, and I still haven't described what I'm building. With OpenSpec the idea went in on the very first workflow command... ## What it put in my project 10 skills in .claude/skills, and .specify with integrations, memory, scripts, templates, workflows, plus init-options.json and integration.json. No git repo required, so far, no existing project required, no account, no API key. ## ## A note on the agent reading everything around it Damn, I was about to get some stuff after running /speckit-constitution, but Claude Code went one folder up and read my log.md where I'm tracking every run. Not Spec Kit's fault, the agent just reads what's around the project. So I moved my notes out, deleted the folder and ran init from zero. Ran /speckit-constitution again and it still knew too much: it saw the sibling folders bmad, kiro and openspec and told me straight away this is a four-tool comparison. My notes were gone, the folder structure alone was enough. So now every tool gets its own isolated folder with no siblings around it. Delete, init from zero again, love that. Third time it was clean: empty folder, neutral name, no siblings. That's the run I'm counting. ## The first command is not about your idea This is where Spec Kit and OpenSpec split. With OpenSpec I gave it the idea in the first command. Here the first command is /speckit-constitution, and it takes no idea at all. The folder was empty, so the agent guessed what the project was from the folder name and asked me three questions to fill in the gaps. As I noticed, none of the constitution questions had a Recommended mark, though OpenSpec marked one in every question, so I'll be choosing the first option as always. I actually had to read everything, so no more clicking Enter and watching Spider-Man ;( Have no idea what it asks me at the third question, going with template default, and this is just the run of first command hahaha. Out came constitution.md, version 1.0.0, five principles. It added a fifth one on its own and said openly that this one was its inference. I see that the tool is more serious than the previous one in terms of approach, here you're diving deeper into your specific task. Let's see what comes next in the 3 remaining commands. ## Then the idea, finally /speckit-specify "A single-page web app for planning a week: seven day columns, add a task to a day, mark it done, everything stored in the browser." 3 user stories, 16 functional requirements, 8 edge cases, 8 success criteria, plus a requirements checklist. The checklist passed 14 of 16, both failures on the same open question, and it stopped to ask me instead of guessing. It reminds me of a workflow I had about in 2025 where the system prompt was always reviewing itself to make sure nothing is missed and all the decisions are discussed. And interestingly, it asks almost the same question as OpenSpec about weeks: current and previous week, or just a week without dates. It recommended option A, so I chose A and went next. After my answer the checklist went to 16 of 16, with two new requirements added and one edge case rewritten. Noticed that it thinks about many decisions that could be skipped, looks like overcomplicating a simple task. ## The plan /speckit-plan scaffolded plan.md and asked about the stack. Three options, TypeScript + Vite marked Recommended. Oh yeah, it's time for the stack question. I know it's not the right time to compare, but OpenSpec identified this as a simple task and recommended plain HTML/CSS/JS, while Spec Kit is clearly designed for heavier tasks, that's why we see this tendency. Second question was about testing. Hehe, tests are here, I like that one, it has a really strict workflow that keeps everything in hand in my opinion. Out came 7 files: plan.md, research.md, data-model.md, three contracts and quickstart.md. Constitution check 5 of 5 with one deferral it recorded and explained instead of being hidden. Getting more and more stuff, I'm already feeling like I've written 10 features lol. One thing to flag: it reported "Branch: 001-weekly-task-board", but there is no git repo in the folder and no branch was created. git status says: not a git repository. The name is just the spec folder name. ## The tasks /speckit-tasks gave me tasks.md with 40 tasks in 6 phases. Tests come before implementation on every single task, because the principle I picked in the constitution is non-negotiable. It also marked parallel opportunities, file collisions, and an MVP cut at task 22. Got 40 tasks for a one-page week planner. I guess it works amazing for complex tasks, but it doesn't have a validator checking task complexity, so every time I want to add some feature, let's say moving a task between days, I'll get a bunch of tasks and big waiting time. Wonder how many tokens this amount of tasks will burn, but that's not today's topic. Spec Kit: 4 actions to the first prompt, 14 to a full plan with tasks. 1 hidden, finding the release tag. # BMAD Method What the README says > Requires uv, Node.js, npm, Git, and an AI coding tool that supports skills. No minimum versions given. The README looks cool, it feels like you've discovered something niche from an indie developer, and already in the intro I see "process sizes itself to the work", that's what Spec Kit was lacking. Three install routes: npx skills add, Claude Code plugin, Codex plugin. Covers the main market from the beginning. Taking the CLI one because it's first and it doesn't depend on which agent you use. npx skills add bmad-code-org/BMAD-METHOD ## Eight actions before the idea That's the short version of what happened next. Here's the long one. The command asks to install the skills package first, so that's one confirmation. Then it clones the repo, finds 29 skills and opens a picker. The README says to select the ones you want and include bmad, but it doesn't say which of the other 28 matter. Seeing a bunch of skills to choose from. The setup has "search" inside the terminal, I'm seeing this for the first time and it's actually amazing. Gonna hit "select all" anyway. Next screen: 79 agents. Wow, this time 79 tools covered, I can only imagine how much time it took to support all of them. 20 of them are Universal and get installed automatically, and it's not clear why. Claude Code is not one of them, it sits in the Additional list and has to be picked by hand. Then the installation scope: Project or Global. Choosing "Project" for our test case and because it's the first option. It says "committed with your project", so I assumed a git repo would be needed at some point. Spoiler: it never was Then the installation method: Symlink or Copy to all agents. It still asks questions about installation, and I have no idea what a symlink is or what "copy to all agents" means here. Of course I can visit the docs or ask an AI, but I'd like to have a bit of understanding just from installing. Choosing Symlink, it's recommended. Eight actions in, and I still haven't said a word about what I'm building. ## The security table Then something no other tool did: a security risk table for all 29 skills, from three scanners. Gen, Socket and Snyk, each with its own verdict. One skill is High Risk according to Gen, another one is High Risk according to Snyk, several are Medium. Mhmm, why do they show me these red "High Risk" things! They put a details link below, I went there and didn't find an explanation of what High Risk means for Gen or for Snyk. Let's just finish, I'm so advanced lol. I confirm, and I get one more proposal: install a skill that finds skills, hahaha, alright let's go. Worth knowing that this one goes into your home folder, not into the project. Then bmad setup, which asks nothing and silently creates a _bmad folder with config and scripts. Based on the docs that's the last command to finish setup, now it's time to type the idea. I hope now it's time for the stack question haha. ## The idea, on action ten bmad-build A single-page web app for planning a week: seven day columns, add a task to a day, mark it done, everything stored in the browser. And the first thing it asks is whether to use subagents. I definitely didn't expect such a question, I thought this kind of stuff is decided inside the workflow. And it's not even BMAD asking, it's Claude Code: its own rule is not to spawn subagents unless I say so, while the BMAD workflow is built around them. So the first question I get is not about my app, it's about two tools disagreeing on how to work. Alright, let's choose recommended. After that it drafts a spec and asks three questions in one form. Delivery: split files with node --test, recommended. Finally, the stack question, and the interesting part is that it proposes tests with Node, that's something new. Task actions: add plus delete, recommended. As always, delete is the most important feature in its point of view, but three of them do it the same, which means a good understanding of the task. Week model: generic Mon-Sun, recommended. Same question all three tools asked. ## What came out One file: spec-week-planner.md, about 1550 tokens. Not a set of documents, one spec. It recorded my three decisions in a frozen intent block, pinned a constraint its own investigation found (file:// blocks ES-module imports, so the logic file has to work both in the browser and in the Node test runner), and built an I/O matrix with nine rows including corrupt storage, private mode and XSS-shaped task text. Nice, so we got the spec. And I immediately want to give respect for this line: use the other skills "ideally in another session to avoid context bloat". The tool takes care of the context, and for me personally that's a big advantage, especially when the task isn't a simple week planner. Then it offered three ways to continue: approve and implement, approve and stop, or have a subagent review the spec first. I chose approve and stop, to see whether a task list appears before implementation. It doesn't. The spec gets marked ready-for-dev, the intent block gets frozen, and that's it. I expected to get more files or tasks like in the tools before, but it just told me it re-read the spec from disk and changed its status. BMAD Method: 10 actions to the first prompt, 15 to an approved spec. No task list at all, the workflow goes from spec straight to implementation. 0 hidden. # Kiro (IDE) What the site says > Three entry points: Kiro Crew, an IDE and a CLI. We're going with the IDE, that's the surface the product leads with. Unlike the others, this one is a paid product, and as an average person I'm going to check the pricing before downloading. On the free plan you get 50 credits and access to open weight models plus Claude Sonnet 4.5, with limits. This is the only one where you really need to think about what you're doing and which skills you're using, because any exploration carries the risk of wasting money. Opening their website and seeing purple design which many people call AI-slop, but I see that a lot of time was spent here, the animations and sections look solid. ## Getting it running Download IDE, choose Apple Silicon, 243 MB dmg. Drag into Applications. Launch. And it immediately asks me to sign in. First tool out of four that needs an account. Four options in the browser: Google, GitHub, AWS Builder ID, Your Organization. Going with Google like everyone else, not gonna spend time choosing a method. Then onboarding. Import VS Code config, which I skip, because mixing my extensions into this would not be fair and not everyone uses VS Code anyway. Then a theme: dark or light, dark preselected, and that already gives you a feeling of dressing up before going out. People with the light theme, let us know that you exist hahaha. Then shell setup, and this is where it gets interesting: macOS asks for administrator privileges. Kiro will prompt now, so I don't even need to prompt with this tool hehe. Jokes aside, first tool out of four that asks for admin rights, and not for the workflow, just to add a command to my PATH. After the password the editor finally opens, and immediately a modal about migrating my previous sessions, on a fresh install where I have none. Behind it, three more screens about features I've never used. I have no idea what those are and it's unlikely anyone visits the docs at this stage, so I just close it. ## Fifteen actions to the first prompt It shows a button "Open a project", and here I'm confused, there's no button to just start a new project like in VS Code. So I find and open our week-planner folder -> trust dialog, of course I trust. The editor opens with four workflows on the right: Spec, Plan, Bug Fix, Quick Spec. All marked optional, which means I could just type into the chat and skip all of this. The tool gives you quite a lot of freedom, but as a user who just downloaded the app I'd like something more step-by-step. You probably don't know what to choose either and would just type your task into the chat. Spec is the first one, so I click it. Nothing happens. It just gets highlighted. I guess I'll just type now. A single-page web app for planning a week: seven day columns, add a task to a day, mark it done, everything stored in the browser. And it asks whether this is a new feature or a bugfix. In an empty folder, where nothing exists yet. Build a Feature, of course. Then: requirements or technical design. Similar to BMAD's questions about the workflow itself, going with recommended. ## Then the approvals Approval request to run mkdir. Allow, Always allow, Deny, Always deny. All of us saw this in any coding agent, and I always hit Always allow to avoid it asking me every time. I've recently even enabled dangerously-skip-permissions. But we take the highlighted option, so Allow. Then Allow again. And again. I already hate that I didn't click Always allow ahahah, I'm feeling like half a year ago when I tried Claude Code and thought there was no way to give it permission once. While it was running I looked around the app. It's another VS Code style editor like Cursor, same source control, extensions, debug, but with a ghost section that looks like an extension for AI: skills, hooks, specs. By the end of the run I'd clicked Allow 32 times. Some of them to let it read a file it had just written itself, twice in a row. If you think approvals shouldn't count as actions, subtract them and Kiro lands at 22. ## What came out At some point requirements.md appears with six requirements. Including a Clear day action, which is smart, so I don't need to delete 20 tasks one by one. Then three options: Generate Tech Design, Generate Task List, Analyze Requirements. We need the prompts asap, so I click Generate Task List. And it starts generating design.md. Wait, why is it generating a design if I clicked Generate Task List? Probably that's part of the process, but I don't see any connection between what I clicked and what it does. It does get there in the end. All three documents: requirements.md, design.md, tasks.md. A zero-dependency SPA, a pure-function state layer with localStorage, 6 correctness properties verified with fast-check, and 7 implementation milestones. And it never asked me about the stack, the week format or testing. It decided everything by itself, and some of the decisions I saw along the way show that the tool thinks about UX on its own. Planning alone cost 6.94 of the 50 free credits, according to the counter at the bottom of the editor. The message itself reports 3.35 estimated credits, so the rest went on everything around it. Elapsed time: 41 minutes 50 seconds. Kiro: 15 actions to the first prompt, 54 to a full plan with tasks. 32 of those were approval clicks. 0 hidden. # Conclusion ## What they agreed on Three of the four asked the same question about weeks: fixed Mon-Sun columns, or real dates with navigation. All three recommended the simplest version, no dates. Kiro never asked, and went with real dates for the current week. It also added a "Clear day" action nobody else offered. All four added delete on their own, and not one of them offered editing a task. If you gave the same sentence to a person, editing is probably the first thing they'd ask about. None of them needed a git repo, an existing project or an API key. Only Kiro needed an account, and only Kiro asked for admin rights. Three of them asked me about the stack, even though nothing in my sentence mentioned it, and the recommended answer was different every time: one HTML file, TypeScript with Vite, split files with node --test. Kiro didn't ask and picked its own. ## Where they split The same sentence produced four different amounts of work. OpenSpec wrote 17 tasks, Spec Kit wrote 40, Kiro wrote 7 milestones, and BMAD wrote no task list at all. Two of them checked their own output before handing it over. OpenSpec listed the assumptions it had made for me and flagged that its plan had no tests. Spec Kit ran a checklist against its own spec and stopped on the two items it couldn't answer. One of them counted its own limits: Kiro spent 6.94 credits and 41 minutes on planning alone. OpenSpec did the equivalent work in 3 minutes. And one number doesn't fit the pattern: Spec Kit reaches its first prompt in 4 actions, the lowest of the four, but that prompt doesn't take your idea. It asks about project principles. The idea goes in five actions later. # My take OpenSpec The one I'd actually keep. Two commands, four actions, and the plan was already there. The install instructions are simple and don't require anything complex, the tool selection is minimalistic and it told me about telemetry upfront instead of hiding it. What sold me is what it did without being asked: it wrote down its own assumptions so I could see where it decided for me, and it flagged a weak spot in its own plan before I built anything. The only thing I'd complain about is that editing a task wasn't in the recommended options, and honestly I'd rather not be asked about the stack at all. If you're one person building a small web app, start here. Spec Kit The most serious of the four, and the heaviest. The install command they lead with doesn't even work until you go find a release tag yourself, and the first command isn't about your idea at all, it's about project principles I had no idea how to answer. But once it gets going it has a really strict workflow that keeps everything in hand. It checks its own spec, it stops when it can't answer something, it warned me about credentials in the agent folder, which nobody else did. 40 tasks for a one-page week planner though. It works amazingly for complex tasks, but there's no validator checking task complexity, so every small feature will produce a pile of tasks and a long wait. If you're on a real project with a team and standards to enforce, this is the one. For a weekend app it's too much. BMAD Method The README feels like you've discovered something niche from an indie developer, and the line "process sizes itself to the work" is exactly what Spec Kit was missing. Eight actions of installation before I could say a single word about my app, and half of those were questions about symlinks and installation scope that I couldn't answer confidently. The security risk table with red High Risk labels and no explanation didn't help either. But the output was thoughtful, and it's the only tool that told me to run heavy work in a separate session to avoid context bloat. It takes care of your context, and for me that's a big advantage, especially when the task isn't a simple week planner. Then it stops at a spec and goes straight to implementation, no task list at all. Kiro The only paid one, the only one that wants an account, and the only one that asked for admin rights. The website looks like a lot of work went into it, and the editor is another VS Code clone like Cursor, with a ghost section for AI. 54 actions, 32 of them clicking Allow. At one point it asked permission to read a file it had just written itself, twice in a row. I clicked the highlighted button instead of Always allow, and I regretted it for the next forty minutes. It also never asked me about the stack, the week format or testing. It decided everything itself, and some of the decisions show the tool thinks about UX on its own, like adding a "Clear day" action nobody else offered. 41 minutes and 7 credits out of 50 free ones, just to plan. That's the part that would stop me. ## ## So what does this mean The promo videos say you'll have full control over your AI context in a minute. The cheapest of these four costs 8 actions, the most expensive 54. None of them is a minute. And the number itself doesn't tell you which one is better. Spec Kit reaches its first prompt fastest of all four and still made me work the longest. Kiro asked me nothing about my app and still produced a solid spec. The four numbers measure friction, not quality. > Thank you for reading. I hope it was useful, and I'd like to hear what you think, especially if your numbers came out different. You're part of this more than you think. What you tell me you want to see next is what I measure next. Right now I'm thinking: what's actually inside those prompts, and how many steps come after the first one.
