What to do before Spec Kit: settle these six questions

Spec Kit and Kiro both start with a feature description you already have. Spec Kit's README shows the input as one sentence: "Build a photo organizer with albums grouped by date and a tile preview of each album." Kiro starts from an idea you bring. Requirements, plan, tasks and code all derive from that first input.

If you are comparing Spec Kit, Kiro and BMAD, you are choosing the second step. The first step decides whether the spec is worth writing: what has to be settled before the tool starts, how you check that it is, and who on your side supplies it.

In many teams that step lands on the developer by default, because the tool runs in the developer's terminal. A product owner who wants to hand over more than a one-liner needs the same answers, from the other side.

Spec Kit and Kiro start where you already know what to build

Spec Kit works in steps: constitution, specify, plan, tasks, implement. The specify step takes a plain description of what you want. Kiro works the same way. You bring an idea, it produces requirements, design and tasks, and for well-understood features Quick Spec generates all three without approval gates.

That is a sound design for what these tools do. They turn a description into a chain of documents an agent can follow. Their questions start from the description you gave them.

So we gave Spec Kit one sentence from an invoicing tool for freelancers: "Add automatic payment reminders for overdue invoices." We ran it on 6 October 2026 in Claude Code 2.1.238 with Opus 5.5 at high effort and Spec Kit 0.7.6.dev0, a development build. It is one run.

The specification came back complete on the first pass. Spec Kit had settled the open points itself and listed them as assumptions: email only, reminders at 3, 7 and 14 days overdue, and "business owner" meaning whoever has administrative access. It also wrote a success criterion with a number nobody had given it: time-to-payment down "by 20%". Its own checklist ended with "Spec passed validation on first pass."

Then /speckit-clarify asked four questions, one at a time, each with a recommended answer. Should owners be able to configure the schedule? Does the feature have to meet legal requirements for payment reminders? How is the owner alerted when an invoice needs follow-up? Should a failed send be retried? These are good questions about the spec, and we answered each with a letter.

The legal question shows the pattern. It was a yes-or-no choice, and the recommended answer was "no special compliance obligations". We picked the other option. The spec now demands legal disclosures and contact-time windows, and hands their content to "a business/legal responsibility". We answered as testers, and nobody in that session knew which rules apply to a freelancer's invoice.

None of the four questions asked why invoices go overdue or what a reminder costs the relationship. That question matters because each answer leads to a different feature. If customers forget, a reminder works. If they dispute the invoice, a reminder damages the relationship, and the feature that helps is a way to pause it. If they lack cash, a reminder adds pressure and nothing else. Our spec already stops reminders for disputed invoices and lets the owner pause one, as options nobody asked for. Which of the three is the real problem decides what the product does first, and that answer stayed unasked.

Spec Kit answers the strategic questions itself, with plausible assumptions, and asks about the spec. It starts where you tell it to start. The work before that sentence is yours, and it has its own questions.

How much spec you need depends on where you ship

The skeptics have numbers, and for their cases the numbers hold. Scott Logic ran Spec Kit on a feature for managing circuits in a go-kart logging app: add and remove circuits, link them to sessions. The first increment took the agent 33.5 minutes and produced 2,577 lines of markdown against 689 lines of code. Review took 3.5 hours, although the author notes that part of it may have been unnecessary. As a reference, he gives his usual iterative routine, not the same feature: 8 minutes of agent time, 15 of review and 9 of testing. He puts the difference at roughly ten times. Marmelab got eight files and 1,300 lines of text for showing the current date in a time-tracking app. Both compare the result to the waterfall model.

For a small, clear change, the "before" is overhead. We agree. A date on a screen needs no constitution.

Those features share one property: a wrong guess is cheap. You see it in the running app and fix it the same hour. Move the question to software where a wrong guess costs more, and the answer changes. For medical device software and airborne systems, standards such as IEC 62304 and DO-178C expect requirements that are documented, testable and traceable to design and tests, with the rigor scaled to the risk of the software. There the spec is part of what you ship.

So the waterfall question depends on three things: what a wrong guess costs, who has to approve the result, and how many people hold part of the answer.

Our rule of thumb: the "before" starts to pay when a wrong guess costs more than a day, or when more than one person holds part of the answer. A tool for this range has to serve both ends. First decide how much spec your environment demands, then pick the tool.

What has to be settled before the first prompt

Spec Kit gives you two tools for checking. /speckit-clarify asks up to five targeted questions about underspecified areas (in our run: four, one at a time, each with a recommended answer), and you can run it as many times as you like before planning. /speckit-checklist checks whether the spec itself is complete, clear, unambiguous and consistent (reference). Both are optional: only the specify step is strictly required before the plan.

Both check the document, and neither checks whether the right questions were asked before it existed. That is a separate check, and it comes first.

We use six questions. Read them against the payment-reminder sentence:

The right column is the point of the table. No single person holds all six answers.

Do not wait for people to volunteer them. Burnay, Jureta and Faulkner mapped 30 topics in requirements interviews and found that stakeholders raise some on their own and stay silent on others "unless asked explicitly". People rarely volunteer what must never happen. We suspect questions five and six belong in that group, but we have not tested that against the study's 30 topics. It is the reason to ask the questions as a list rather than hope they come up.

You can check the answers in three steps:

1. Write each answer as one sentence. A blank or an "it depends" is an open question.
2. Mark each answer as known, assumed or unknown, and note who confirmed it. The author of the description cannot confirm their own assumptions.
3. Reread the one-liner. If an answer changes it, the question earned its place. In the example, a "dispute" answer to question two moves the first release from sending reminders to pausing a disputed invoice. That change is the one the spec would otherwise have missed.

Requirements are found between people, not typed by one

Requirements are found between people. A terminal has one person in it.

Alistair Cockburn described the same idea in 1998: "A user story is a promise for a conversation." Ron Jeffries (InfoQ) split a story into three parts: the card, the conversation and the confirmation. The card is the small part. The conversation does the work, and the confirmation shows whether it worked. A spec is what the conversation leaves behind. It documents the result and does not produce it.

Spec Kit and Kiro document well. What they leave open is where the conversation happens. Birgitta Böckeler tried Spec Kit and noted that it treats the analysis as the developer's job without making that explicit. That is the question this page is about.

A model can ask good questions too. In 33 simulated interviews, an interview chatbot called LLMREI made a similar number of errors as human interviewers. In a second study, GPT-4o follow-up questions were no worse than human ones, and better when the model was guided by common interviewer mistakes. Asking can be shared with a model; answering cannot.

Look at the table again. The freelancer knows what chasing a late payer is like. The accountant knows which rules apply in which country. The end customer knows what an email from the freelancer feels like at day fourteen. In a terminal session, the one person at the keyboard answers for all of them, and each answer is a guess. In our Spec Kit run, one person answered all four clarification questions with a single letter each, including the one about legal requirements. The spec then reads like knowledge and is built on assumptions.

This applies once a requirement belongs to more than one head. A solo developer building a tool for their own use holds every answer. For them, the terminal is the right place, and the "before" is mostly a matter of discipline.

For everyone else, the question "who supplies it?" has a plain answer: the people who own the question. If you are a product owner or product manager, that is your part of the work. You do not write the spec. You make sure each answer comes from the head that holds it before the developer's tool starts, and that the spec records who confirmed what.

BMAD starts earlier, and lives in your coding agent

BMAD covers part of what this page covers. Its documentation describes a delivery loop that starts with a Clarify stage, though work of different sizes enters it at different points, and the tool offers brainstorming to "generate options or pressure-test the idea". Where Spec Kit and Kiro take your feature description as input, BMAD starts before that description exists. For a developer working alone, those early steps are a real answer to the question this page asks.

We don't see a showdown here, and we don't claim BMAD misses things. Two differences are verifiable:

• Where it runs. BMAD adds named commands, which it calls skills, to AI coding tools such as Claude Code and Cursor. The Clarify stage happens inside the coding agent.
• Who can reach it. The tool lives in the coding environment, so everyone who has to answer needs access to that environment. The developer is there already. The accountant and the freelancer from our example would have to work inside it too, or through someone who does. This follows from where it runs and is not a flaw.

The previous section explains why this matters. The six questions have owners in more than one head. A Clarify stage inside a coding agent still runs in a session with one person at the keyboard. BMAD can ask the questions well. The people who hold the answers have to get into that session.

We built Speclr for the other arrangement. It is a workspace in the browser, outside the terminal, where a developer, a product owner, a requirements engineer or a whole team can work in the same place. It interviews you in four phases, from discovery to refinement, and keeps rules, actors and data fields in one shared body of knowledge so that an answer is recorded once and reused. You choose how much to take on yourself: fully interactive, pre-filled, or automatic. The result exports to your repository as input for the spec tool you use.

How much spec your environment demands, you decide before any tool, with the people to whom the requirements belong. The tool documents the result.

Further Reading

Settle the six questions with your team

Take your next feature through the interview. Speclr is free for 14 days.

Get started