Use case
Write user stories your developers can actually start
A story is finished when a developer can pick it up without asking you a question first. That needs acceptance criteria you can actually test, an estimate based on your real system, and enough background that the reason for the work survives into the ticket. Spectr drafts that. You check it.
A general AI chatbot writes a tidy story about a product it has never seen
Paste a feature description into ChatGPT and the format comes back perfect. The content is guesswork. It does not know your data model, your feature names, the migration you are halfway through, or that half of what is being asked for already exists. So the acceptance criteria sound right and are wrong, and fixing them takes about as long as writing them would have.
What it actually looks like
Sprint planning is tomorrow. You have 14 items to write up from last week and two hours before your next call.
Before
You open the recording in one tab and Linear in another and start typing. Two hours gets you nine tickets. The last four are one-liners you promise yourself you will come back to.
10:02am
Instead: you open the spec sheet Spectr already made from that call. Fourteen items, each with a draft story under it.
10:03am
Each story names your real components, because Spectr read your Figma file and your repo. The estimates reflect the three services the change actually touches.
10:11am
Spectr flags two of the fourteen as possible duplicates of stories already in the project. One genuinely is - you mark it confirmed, and the two are linked from then on.
10:26am
You bulk-approve ten, rewrite two acceptance criteria that were too vague, and reject one with a note saying why.
10:31am
Thirteen issues land in Linear, nested under their parent where a single requirement produced several.
Two hours of typing tickets from a recording has turned into about half an hour of checking them - and all fourteen items get the same attention instead of the first nine getting all of it.
Stories written against your actual product
Spectr reads the Notion pages, Figma files and GitHub repos you pinned before it writes anything - including screenshots of the relevant Figma screens, which go to the model as real images. So a story about filtering the results list describes your results list, with its real states and components. The estimate reflects what the change would really touch, not a guess from the wording of the request.
The shape matches how you plan
A per-project setting takes output from a flat list of stories to nested stories with sub-tasks. Each story gets a type - feature, bug, chore or spike - plus a priority, an estimate, labels and acceptance criteria. When one requirement produces several stories, they publish as a parent with the rest underneath rather than as unrelated siblings.
Duplicates get caught before they reach your board
When a spec sheet finishes, Spectr checks its new stories against everything else in the project and flags anything that looks like a repeat. You can promote a flag to a confirmed duplicate, which links the two for good. That is how you stop the same piece of work sitting in the backlog three times in three different phrasings from three different meetings.
Reviewing is the point, not a formality
Every story goes to a review page. Approve, edit inline, reject, or reject with a note about why. Approved stories publish to Jira, Linear or Shortcut and map onto that tracker's own fields. Rejected ones stay out, and when the setting is on they inform later runs so you are not offered the same bad idea twice.
Works with
Frequently asked questions
Is reviewing 14 drafts really faster than writing them?
Yes, and not by a small margin - reading a written story and deciding if it is right is a different task from producing one from a blank box. Bulk approval handles the ones that need no argument, which leaves your attention for the two or three that do.
Which AI model writes the stories?
Claude Sonnet writes the stories and pulls the spec out of the call. Claude Opus handles requirement documents, where full-document reasoning matters most. Claude Haiku does the cheap, fast jobs like summarising and duplicate-checking.
Can I change a story after it is published?
Yes. Edit it in Spectr and the change syncs across to the ticket, so you are not left with a stale copy in your tracker.
Does Spectr write acceptance criteria for bugs too?
Bugs are recognised as bugs and published as your tracker's bug type. For those it writes reproduction detail and what should happen instead, which is more useful than story-shaped criteria.
Also worth reading
See it on your own project
Free plan available - five spec sheets a month, two seats, no card required. 30-day free trial on Starter.
Free plan available. 30-day free trial on Starter.