Turn a customer complaint into a reproducible issue brief

A useful bug brief helps an engineer reproduce a problem. It should distinguish what a customer reported from what anyone actually tested. This workflow organizes evidence; it does not run software or claim reproduction.

Prepare the input

Provide the original complaint, available screenshots or text descriptions, app version, and environment if known. Remove account secrets. Keep each source reference so the engineer can inspect it.

Run the workflow

Ask for a numbered reproduction attempt based only on stated steps. List missing prerequisites and questions separately. Expected behavior should come from a documented requirement or a clearly labeled user expectation.

Prompt to copy

Create an issue brief from these reports: [material].
Include environment, reported steps, expected behavior and its source,
actual behavior, attachments, and unanswered questions.
Label every untested step as proposed, not reproduced.
Do not invent logs, version numbers, or a root cause.
Finish with the smallest next verification step.

Review a worked example

Illustrative complaint: “Export fails after I choose last month.” If the browser and file type are absent, they belong in questions. “Click Export” may be a reported step; “database timeout” is not a justified diagnosis. Check that the brief does not claim a test happened.

Inspect the proposed steps for hidden prerequisites such as an account role, existing file, or earlier setting. A reproduction attempt without those details may fail for the wrong reason. Keep unavailable evidence in a missing-evidence list. Do not let a clean template make an incomplete report appear fully investigated.

Use it again

Have the engineer add observed results after the attempt. Preserve the difference between proposed and verified steps. Bot can support preparation from supplied evidence; connected issue tracking or staging interaction requires an assessed integration scope.