Steps to reproduce generator (free, no signup)
Describe what you did and this free tool turns it into clear, numbered steps to reproduce, with the expected and actual results spelled out. Copy the Markdown into GitHub, Linear, Jira, or a message. It runs entirely in your browser, nothing you type is sent anywhere.
Generator
Build your steps to reproduce
Environment (optional)
## Steps to reproduce Starting point: Logged in, on the settings page 1. Change the display name to a new value 2. Click Save ## Expected result The new display name is saved and a confirmation appears. ## Actual result The page reloads and the old name is still shown. No message appears. ## Frequency Happens every time. ## Environment - Browser: Chrome 120 - OS: macOS 14.2 - App version: 2.3.1
Add the repository as owner/repo, for example octocat/hello-world.
Why it matters
What makes repro steps reproducible
Steps to reproduce fail for one of three reasons: they start from a state the reader cannot reach, they bundle several actions into one step, or they carry on past the point where the problem appeared. Fix those three and a developer, or a coding agent, can follow the list and see the same failure you did. That is the whole job.
- Start from a known state. "Logged in, on the settings page" is a place anyone can get to. "After I had been using the app for a while" is not.
- One action per step. "Change the display name and save and refresh" hides which action actually triggers the bug. Split it.
- Stop at the failure. The last step is the one where things go wrong. Everything after that belongs in the actual result, not the steps.
- Say what correct looks like. The expected and actual results, as two separate lines, plus how often it happens.
Once you have the steps, they are usually half of a larger write-up. The bug report template generator wraps the same structure in a full report, with room for the console error and the failed network call; if that console paste is a wall of repeats and dev server chatter, the console log cleaner strips it down first. And once the steps are written, the bug severity and priority calculator sets the triage labels for it. When the steps are done, the buttons under the output send them straight to GitHub or Linear as a prefilled issue, no retyping.
FAQ
Steps to reproduce questions
What are steps to reproduce?
Steps to reproduce are the exact actions someone takes to make a bug happen again, written as a numbered list. They start from a known state, list one action per step, and end at the point where the problem appears. If a developer or a coding agent can follow them and see the same failure, the bug is halfway fixed. This tool formats yours for you.
How do I write good steps to reproduce?
Start from a state anyone can reach, for example logged in on a specific page. Write one action per step, in order, and stop at the step where things go wrong. Then say what you expected and what actually happened, as two separate lines. Note how often it happens. Vague steps like 'use the app for a while' are the main reason bugs bounce back as cannot reproduce.
What is the difference between expected and actual results?
The expected result is what should happen after the final step, based on how the feature is meant to work. The actual result is what really happened. Writing both, rather than only 'it broke', tells whoever picks the bug up exactly what correct looks like, which is often the missing half of a report.
Is this steps to reproduce generator free?
Yes. There is no signup and no limit. It runs entirely in your browser, nothing you type is sent anywhere. Fill in the fields, then copy the Markdown or open it straight as a prefilled GitHub issue or Linear ticket.
Can coding agents use the output?
Yes, that is the point of the format. The output is structured Markdown with predictable headings, so an agent reading the ticket can parse the steps, replay them, and check the actual result against the expected one. Quell calls this agent-readable feedback, and its widget captures the same structure automatically.