You came for a bug report template — the fields, the headings, something to paste into Jira or a form. It's below; take it. But a good software bug report template answers one question the standard fields never do: what was this supposed to do in the first place? A ticket in Jira or a Google Form is an island — it describes what broke, severed from the spec or decision that defined "correct." Draftlize gives you the same eight fields — and makes the last one a real link, so a bug card points at the spec it violates, and the agent fixing it reads the original intent before it writes a line.
This is the whole bug report template. It works in a Jira ticket, a Linear issue, or a bug report form — paste it as-is. The next section is about what changes when the last field stops being a free-text note and becomes a link to the spec the bug broke.
One line: component, the broken behavior, the trigger. "Checkout — total ignores the per-use discount when a coupon is applied." A title someone can triage without opening the ticket.
Build / version, OS, browser, device, and the account or data state. Half of "cannot reproduce" lives here — the bug is real, it just needed the environment you forgot to write down.
Numbered, from a known starting state, with the exact inputs. If a stranger can't follow them to the failure, the report isn't done. This is the field that decides whether the bug gets fixed or bounced back.
What should have happened — and, ideally, the spec or decision that says so. This is where most templates wave their hands. "Correct" isn't an opinion; it was defined somewhere. Point at it.
What actually happened: the wrong output, the error, the stack trace, the screenshot. Concrete and observable, not "it's broken." The gap between this and Expected is the bug.
Blocker, major, minor, trivial — plus impact: who hits it, how often, is there a workaround. Severity is what an agent or a human sorts the queue by; guess it honestly.
Screenshots, a screen recording, logs, a HAR file, the failing payload. The proof that turns "I think it's broken" into a reproducible fact someone can act on.
The spec, requirement, or product decision this bug contradicts. In a form this is a dead URL you'll paste and forget. It's the field that says what "fixed" even means — and the one this whole page is about.
That's the template. Below: why a ticket cut off from its spec is half a bug report — and what we do about it.
The fields are good — that's why every bug report form has roughly this shape. But they capture what went wrong, never what right was. "Expected behavior" is whatever the reporter remembers the rule to be, which is often not the rule. The spec that actually defined correct lives in another tool, if it lives at all.
Whoever picks up the bug — a developer or an AI agent — patches the symptom in the report. They never see the decision that set the behavior, so they "fix" it back to something that violates a different rule, and you ship a second bug to undo the first.
You change a pricing or flow decision. Somewhere there are open bugs filed against the old behavior — now obsolete, or now pointing at the wrong "expected." Nothing connects the spec to those tickets, so they rot in the backlog until someone wastes an afternoon on a bug that no longer exists.
In Draftlize the bug report isn't a stranded ticket — it's a typed card with those exact fields, and "Related spec or decision" is a real link to the spec or decision card it breaks. The bug and the intent it contradicts sit one click apart, in the same structured graph.
Claude Code or Cursor, over MCP, opens the linked spec and decision before it touches the code. It fixes toward the behavior that was actually specified — not the reporter's half-memory of it — so the patch restores intent instead of guessing at it.
Because the link is real and not a pasted URL, changing a spec flags every bug filed against it — the way a build system invalidates everything downstream of a changed file. A bug whose "expected" just moved gets surfaced, not silently stranded in the backlog.
A bug is the distance between what happened and what was supposed to happen. A report that omits the second half is only half a bug.Keep the eight fields. Link the last one to the spec it broke.
A good bug report states the distance between what happened and what was supposed to happen: clear steps to reproduce, the actual result, the expected result, environment, severity, and a link to the spec or decision the behavior violates. The expected-result field is the half most reports omit — and without it a bug is only half described.
Title, steps to reproduce, actual result, expected result, environment or version, severity or priority, screenshots or logs, and the related spec or decision. Steps to reproduce and expected result do the heavy lifting: they turn "it is broken" into something an engineer, or an agent, can act on without a back-and-forth.
A bug is a gap between the product and its own spec — it is not doing what it was defined to do. A feature request asks the product to do something new it was never specified to do. One restores intended behavior; the other adds intent. Filing them the same way blurs a line worth keeping sharp.
The related-spec field is a real link, so a bug sits one click from the behavior it violates, and a coding agent reads that intent before it patches. Change the spec and every bug filed against the old behavior flags stale — an obsolete ticket gets surfaced instead of rotting in the backlog.
Take the template above, or spin up a project where every bug links to the spec it violates — so the agent fixing it reads the original intent, and a changed spec never leaves a stale bug behind.
Start free with $5