A useful bug report lets another person understand what happened and, where possible, repeat it. AI can organize rough notes into that format. It can also make an incomplete account sound more certain than it is.
The workflow below keeps your observations separate from guesses. The example is fictional and written for this guide; it is not a recorded AI response or a test of a real app.
Collect observations before asking AI to write
Write down what you did, what you expected, and what appeared instead. Include the starting conditions that matter, such as a selected filter or whether you were signed in. Copy a visible error message accurately, but check it for private information before sharing it.
Record the app or website, device, operating system, browser or app version, and how often you observed the behavior when you know them. Leave missing details blank. “It happened once” is useful evidence; “it always happens” is a different claim.
Mozilla’s guide to filing good bugs emphasizes a descriptive title, specific reproduction information and relevant environment details. Those principles also help when AI is assisting with the wording.
Prepare a small, safe example
Use an approved AI service and follow your organization’s rules about what may be shared. Replace customer names, private URLs and confidential content with a suitable test example. Do not paste passwords, tokens, cookies or an entire unreviewed log.
Keep any original evidence in its appropriate secure location. A redacted description can refer to an attachment without sending that attachment to AI. Our guide to removing sensitive details from AI writing prompts offers a more detailed preparation checklist.
Here are the fictional source notes for this example:
- App: a test reading-list website called Shelf Notes.
- Environment: laptop, Firefox. Browser and operating-system versions not recorded.
- Starting list: Paper Gardens marked Read; River Maps marked Unread.
- Action: selected the Unread filter.
- Expected: only River Maps would appear because it was the only item marked Unread.
- Observed: Paper Gardens and River Maps both remained visible. The filter label displayed Unread.
- Frequency: observed once. No repeat test performed.
- Evidence: no screenshot or log collected.
The notes describe a mismatch between the filter label and the displayed list. They do not establish whether the cause is the interface, stored data, a network response or something else.
Give AI a bounded drafting prompt
Paste only the prepared notes after a prompt like this:
Turn the notes below into a concise bug-report draft. Use only facts in the notes. Include: title, environment, starting conditions, numbered steps, expected result, actual result, frequency, evidence available and unanswered questions. Preserve exact item names and interface labels. Do not invent versions, timestamps, error messages, tests, causes, severity or attachments. Mark missing information as “not recorded” or “not tested,” as appropriate. Separate any question from an observation. Do not submit the report or suggest that the problem is confirmed beyond the stated observations.
Using a fixed structure makes omissions easier to notice. Asking the model to “make this sound technical” gives it much more room to add a plausible explanation you have not verified.
Review the draft against the original notes
A report based on those notes could look like this. This is an editorial example, not output captured from an AI service.
Title: Read item remains visible after selecting Unread filter
Environment: Shelf Notes test website, laptop, Firefox. Browser version and operating-system version: not recorded.
Starting conditions: The list contains Paper Gardens marked Read and River Maps marked Unread.
Steps:
- Open the reading list containing those two items.
- Select the Unread filter.
- Observe the filter label and the items displayed.
Expected result: Only River Maps appears, matching its Unread status.
Actual result: Both Paper Gardens and River Maps remain visible while the filter label shows Unread.
Frequency: Observed once; repeat testing not performed.
Evidence available: Written observations only. No screenshot or log collected.
Unanswered questions: What were the browser and operating-system versions? Does the same behavior occur when the permitted test steps are repeated? Does the project documentation define the filter differently?
Notice what the report does not say: there is no claimed server failure, lost data, affected-user count or successful workaround. Those would require additional evidence.
Check claims one field at a time
- Title: Does it name the observed behavior rather than an assumed cause?
- Steps: Are they in the order actually followed, with the necessary starting conditions?
- Expected result: Is it supported by the interface, documentation or an agreed requirement? If it is only your expectation, say so.
- Actual result: Does it preserve the visible behavior without adding a diagnosis?
- Frequency and scope: Did “once on this laptop” become “every time for all users”?
- Evidence: Are all named attachments real, relevant and safe for the intended recipient?
- Unknowns: Are missing versions or unperformed checks still marked as missing?
You can ask AI to list sentences in its draft that lack support in the notes. That is another review aid, not independent verification. Compare the draft yourself, especially after a rewrite or a request to shorten it.
Repeat only checks you are allowed to perform
If the behavior can be reproduced safely in an authorized test environment, follow the stated steps and record the actual result. Change one relevant condition at a time. If a second attempt works normally, add that fact rather than rewriting the first observation as though it never happened.
Do not repeat a purchase, delete data, change security settings or perform an intrusive security test just to obtain a cleaner report. When a check would have consequences, stop and ask the responsible person how to proceed. A report can honestly say that further testing was not performed.
For a browser-specific issue, MDN’s browser bug-reporting guide discusses small test cases and checking whether the issue belongs to the site, browser or documentation. A problem seen in a browser is not automatically a browser defect.
Choose the right destination before submitting
Search the project’s existing issues or support guidance for a matching report. If there is one, follow the project’s process for adding useful new evidence. Otherwise, use its required template and review the final text and attachments in the destination form.
A private support ticket and a public issue have different audiences. Check screenshots for account details, other tabs, notifications and private content. Security concerns should go through the owner’s designated private reporting route rather than a public issue containing sensitive details.
OpenAI’s responsible-use guidance recommends following workplace policies and keeping people involved in checking important work. In this workflow, the final decision to submit stays with the reporter. A polished draft is ready only when its claims match the evidence and its destination is appropriate.
