Don't generate a spec. Build one with your whole team.
Speclr guides you from a rough idea to a BDD spec, checked from every angle before any coding agent sees it.
How it works
From idea to implementation-ready.
Discovery
Turn a rough idea into a product vision.
Find out what you are really building.
Start from a single sentence or a pile of notes. Speclr interviews you on problem, users, value and scope, and Forge Idea pushes back on assumptions that don't hold. Your uploaded files, project memory and domain knowledge feed into every question.
See the formatsEnds when
your product vision is clear enough to explore.
One context, every phase
Explain your domain once. Speclr keeps it.
Prompt one knows your domain. Prompt thirty doesn't remember prompt one. Speclr does: your domain knowledge, your decisions and your rules stay in the project, so every question starts from what it already knows.
Domain Knowledge
Your glossary, regulations, notes
Project Memory
What Speclr learned about your project
Project Constitution
Rules every story must follow
Discovery
Product vision
+ Product vision
Exploration
Story map
+ Story map
Planning
Milestones & risks
+ Milestones & risks
Refinement
Story artifacts
+ Story artifacts
Hand-off
PRD · .feature files
reads everything
Your project context
Grows with every phase. Every new question starts here, not from zero.
Guided, not generated
Speclr asks. You decide.
Give a model one sentence and it will write a confident spec full of assumptions you never made. Speclr does what a good requirements engineer does: it asks. Each phase uses a format teams know, and every answer you give shapes the spec.
Questions before answers.
Speclr starts with what a good analyst asks first: who has the problem, what it costs them, what is out of scope. You answer in your own words, and the product vision takes shape next to the chat. Short on time? Let Speclr draft from your idea and correct it instead.
Who needs to know when someone reports sick, and how fast?
Built with your whole team
One project. One conversation. Everyone in it.
Requirements live in more than one head. Your product owner, developers and domain experts work in the same project, not in separate documents.
Everyone answers in the same conversation. The product owner explains the goal, the domain expert corrects the details, the developer raises what won’t work.
Grounded in your domain
A spec that speaks your language.
A generic model writes a generic spec. It doesn’t know that in your company “absence” and “leave” are different things, which regulations apply, or what your team never does. Tell Speclr once, and the agents keep learning as they work.
Your words, not generic ones.
Add your glossary, regulations and architecture notes as PDF, Markdown or text. Agents look up what is relevant while they ask and write, and they add what they learn along the way: a new term, a rule that came up in an interview. The knowledge grows with the project.
Checked from every angle
Five reviewers read your spec before any coding agent does.
Behind every interview works a network of specialists. While you answer, they read what you have specified from their own angle and raise findings in the same conversation, while changing them is still cheap.
You
answer & decide
Refinement
interviews you, one story at a time
Reviewers
Consistency
Keeps your requirements from contradicting each other.
- Looks for
- Overlaps, contradictions and duplicates between stories and rules.
- Example finding
- “Cancel a sick report” says a report can be withdrawn at any time. “Payroll cutoff” locks reports after the 20th.
- You decide
- One replaces the other, one specializes it, or both consciously stand.
A BDD spec for any coding agent
Requirements you can test. Files any agent can read.
A spec is only worth something if whoever builds from it, a developer or an agent, can check their work against it. Speclr ends every story in scenarios and hands over plain files.
The spec
Every story ends in scenarios, not in a paragraph.
A finished story holds the rules, flows and data you decided on, and Given/When/Then scenarios that follow from them. Your Project Constitution is built in, so rules like “health data is visible to HR only” show up as scenarios in every story they affect.
The handoff
Plain files that any coding agent can read.
Each story leaves Speclr as its own Gherkin .feature file, next to a Markdown mini-PRD with vision, scope and domain terms. Use the files as acceptance tests with a framework such as Cucumber, or give them to your agent as its definition of done.
Your agent, your repo, your rules.
Speclr doesn't run your agent and isn't tied to one. Commit the files next to your code and use them with Claude Code, Cursor, Copilot or anything else that reads Markdown. What happens after the hand-off is your call.
The know-how behind it
Learn the methods Speclr is built on.
Speclr’s questions come from methods that have worked in real teams for years: requirements engineering, behavior-driven development, lateral leadership and sociotechnical design. Speclr Courses teach them step by step, around one running project. You learn why Speclr asks what it asks, and you can use the same methods in your next refinement, with or without Speclr.
Explore the courses