Overview
What I Built
Most requirements do not arrive as requirements. They arrive as a Slack thread, a half-finished doc, and a stakeholder saying 'we just need it to work like the old system, but faster.' The skilled part of business analysis is not writing user stories. It is imposing structure on that mess without losing what people actually meant.
This demo encodes the structure I use for that work. You paste the raw material, and Claude returns a strict JSON object: one epic with a title and summary, a set of user stories in As a / I want / So that form, Given / When / Then acceptance criteria for each story, plus the assumptions it made and the open questions it could not answer. Asking for JSON instead of nicely formatted text matters: the page renders real story cards from the data, and the same object generates the Markdown export.
Assumptions and open questions are first-class output on purpose. When the input is thin, a useful tool says what it guessed and what it still needs. A backlog generator that always sounds certain is one that invents scope.
Try It
Live Demo
Paste raw requirements below, add a line of context if it helps, and generate a starter backlog. Use the example if you want to see the shape of input that works well.
The idea
Messy input is the job. Structure is the deliverable.
Every requirements document I have ever received arrived as fragments. The craft is turning fragments into work a team can estimate, build, and test.
Architecture
How It Works
The page sends your text to Claude through the same proxy the other demos use, with a prompt that specifies an exact JSON schema. The response is parsed in the browser, rendered as story cards, and converted to Markdown locally. If the model ever returns something that is not valid JSON, the page falls back to showing the raw text instead of failing.
Messy stakeholder text pasted into the form
Exact JSON schema and story format rules
Drafts the epic, stories, and criteria
Parsed and validated in the browser
Rendered backlog plus a Markdown export
Why JSON? A schema is a contract. It makes the model's output checkable, renderable, and reusable, and it fails loudly when the output drifts, which is exactly what you want from anything headed for a real backlog.
Reflection
What I Learned
Built and written from the perspective of a Business Analyst turned Product Manager.
-
Asking for JSON beats asking for nice formatting Rendering, copying, and downstream tooling all get easier when the model returns data instead of prose. The model also follows a schema more reliably than it follows a layout.
-
Assumptions are a feature When input is thin, a good tool says what it guessed. Forcing an assumptions section made every output more honest, and it mirrors what I ask analysts to do in review.
-
Acceptance criteria are where quality shows Given / When / Then forces testable statements. Vague criteria in, vague criteria out; the format exposes weak thinking immediately, whoever wrote it.
-
The example does the teaching One strong preloaded example communicates the expected input better than a paragraph of instructions. People copy the shape of a good example.
Tools Used
Tech Stack
A single HTML file with vanilla JavaScript. The only network call is the proxied request to Claude.
Keep exploring
More from the site
Head back to the projects page or take a look at the source on GitHub.