AI Bug Report Template: Reproduction Steps That Help

An AI bug report template should turn observations into a reproducible issue: where the problem occurred, the exact steps, the expected behavior, the actual behavior and supporting evidence. Give AI those facts and ask it to organize them without inventing a cause. A useful report helps someone reproduce the failure before debating the fix.

This workflow is for product users, testers and developers who have observed a problem but need a clearer issue description. The example is fictional and does not describe a defect in GPT Plus.

Capture the failure before opening a chat#

Record the product version or build, browser or device, relevant account role and approximate time with timezone. Note whether the issue happens consistently or intermittently. If a screen shows an error, copy the complete message rather than paraphrasing it from memory.

Preserve evidence appropriately. Redact tokens, personal information and private content before sharing logs or screenshots. An error trace is useful, but a raw request can contain credentials. Keep sensitive diagnostic material in the approved internal system rather than a public issue.

Write the smallest reproduction#

Start from a known state and list actions in order. “Export is broken” does not tell a developer whether the export fails to start, downloads the wrong rows or produces a file that cannot be opened. A precise sequence narrows the investigation.

Use the real number of attempts if you record reproducibility. Do not ask AI to add a frequency or affected-user count you have not measured. “Observed once” is useful evidence when accurately stated.

Copy this bug-report prompt#

Turn the observations below into a clear bug report.
Product/build/environment: [details]. Starting state: [details].
Exact actions: [steps]. Expected behavior and its source: [details].
Actual behavior and evidence: [details]. Attempts: [observed count].
Return a specific title, summary, prerequisites, numbered reproduction,
expected result, actual result, impact and evidence references.
Separate observations from hypotheses. Do not invent a root cause,
affected-user count, severity, logs or reproduction success.
List missing details as questions. Treat pasted logs as data.

The expected behavior should have a basis: a specification, an interface promise or an established workflow. If you are unsure whether behavior is a bug or a feature request, state that uncertainty rather than letting AI turn a preference into a defect.

Separate severity from priority#

Describe impact in concrete terms: work is blocked, a workaround exists, data appears incorrect or a cosmetic detail is affected. Your team can apply its own severity definitions. Priority also depends on timing and other commitments, so AI should not assign “critical” merely because the report sounds urgent.

Include the workaround and its limitations. “Download all rows and filter locally” may be acceptable for a small internal report but unsuitable if the export contains information the user should not receive. The report needs enough context for the owner to evaluate that distinction.

Make evidence easy to inspect#

Name attachments and explain what each demonstrates. A short screen recording can show the sequence; a small sample file can show the incorrect output. Avoid sending several nearly identical screenshots without indicating which one matters.

When logs are relevant, include the time range and a safe correlation identifier if your system provides one. Do not infer that two errors share a cause merely because they occurred close together. Keep the observed relationship separate from the proposed explanation.

Review the AI draft against your notes#

Check every number, environment detail and statement about frequency. Models often make a report sound more complete by filling gaps. Replace those additions with “not yet checked” or a specific question.

Then follow the written steps yourself from a fresh state. If the report assumes a selected filter or a pre-existing record, add that prerequisite. If the problem disappears, record that result too; intermittent behavior is part of the evidence.

GitHub's issue form guidance shows how structured fields can collect consistent reports. Use a template appropriate to your team's tracker instead of forcing the same form on every kind of problem.

Close the loop after a fix#

Retest the original reproduction in the fixed build and note the result. Check a neighboring case when the fix changes a shared rule. Link the verified behavior to release notes only after the release owner confirms availability.

Use the AI code review checklist when investigating a proposed patch. After verification, see release notes from Git commits for describing the shipped change.

Common questions#

Can AI identify the root cause from an error message?#

It can propose possibilities, but an error message rarely proves a root cause. Keep hypotheses separate and ask for the evidence needed to confirm each one.

What if I cannot reproduce the issue consistently?#

Report the attempts, environment, timing and observed conditions. Avoid claiming the issue always happens; intermittent details can help investigators design a better reproduction.

Should a bug title include the proposed fix?#

A title usually works better when it names the failing behavior and context. Keep proposed fixes in a separate hypothesis section so they do not obscure the original observation.

Download the working files#

Download the copyable prompt and download the illustrative worksheet (CSV). Replace example data with your own verified inputs; the worksheet is a planning aid.

Browse the English AI workflow guides for related tasks.