A useful dictated bug report records the environment, the shortest known steps, expected behavior and actual behavior. Describe what you observed without guessing the cause. Edit the transcript into labeled sections before submitting it.
Record the environment first
Note the product version, operating system and relevant browser or editor. If you do not know a version, look it up rather than letting a plausible number slip into the report. Use a disposable reproduction where possible. A report containing real customer data may be harder to share safely than a minimal example with invented text.
Say the steps in the order you performed them
An illustrative draft is: “In the test build, I open Settings, choose the dark theme, close Settings and reopen it. The preview stays light until I resize the window.” Say the actual steps, including whether you restarted the app. Avoid “it always happens” unless you tested repeated attempts and can report them accurately.
Separate expected from actual
Manually organize the example as: “Steps: open Settings; choose dark theme; close and reopen Settings.” “Expected: preview matches the selected theme.” “Actual: preview remains light until the window is resized.” This is a fictional teaching example, not a reported Sayhush defect. Add the genuine version and reproduction frequency in your own report.
Leave the suspected cause as a hypothesis
“The preview did not update” is an observation. “The rendering cache is broken” is a theory unless you investigated it. Keep any theory in a separate note with its supporting evidence. Sayhush cannot inspect logs, identify the failing function or reproduce the issue from your speech; it supplies the text you dictate.
Attach evidence deliberately
Add a redacted screenshot or log excerpt yourself if it helps reproduce the issue. Type exact file paths, identifiers and error codes when recognition changes them. For long logs, paste the relevant excerpt directly rather than reading it aloud. Check that the attachment shows the same version and state described in the report.
Replay the written report
Follow your own written steps in a disposable context. If a missing step prevents reproduction, add it. A second person should be able to understand the expected result without guessing. Review names, numbers and negatives in the transcript before submitting. This final replay is more valuable than making an uncertain report sound polished.
Your quick checklist
- Record the real environment and version.
- List the minimum known steps.
- Separate expected and actual behavior.
- Mark suspected causes as hypotheses.
- Remove secrets from evidence before sharing.