Voice Dictation for GitHub Issues and Pull Request Reviews
Use voice dictation to draft the explanatory text in a GitHub issue or pull request review. This workflow focuses on reproduction steps, observed behavior, and actionable comments. OpenTypeless supplies text to a focused desktop field; it does not create issues, post reviews, inspect your repository, or verify a test result for you. The drafts below are illustrative examples.
Prepare a draft field and check insertion
- Configure your STT route and optional LLM polishing route, then test a short phrase in a disposable document. Check both routes before dictating non-public project information.
- Check the recording shortcut before opening GitHub: the v1.1.61 default is Ctrl+/ in hold mode on Windows and Linux, or Fn in toggle mode on macOS. Customize it if it conflicts with your editor or another app.
- Open the appropriate GitHub issue or review composer in your browser and focus the editable field. First test a non-sensitive draft and verify the destination.
- Keep the draft unsubmitted until you have checked names, numbers, links, Markdown, and meaning. Test undo in your browser before relying on a longer insertion.
Dictate a bug report in separate parts
Speak the environment, steps, expected result, and actual result separately. Do not turn a suspected cause into an observed fact. Use an issue template when the repository provides one; fill each requested field and leave unknown details explicit.
Title: filter reset leaves the issue list empty
Environment: [verified app version, OS, and browser]
Steps to reproduce:
1. Open the issue list with at least one visible issue.
2. Apply a label filter.
3. Remove the filter.
Expected: the unfiltered list appears.
Observed: the list remains empty until reload.
Frequency: [recorded observation; unknown if not tested]
Evidence: [link to a non-sensitive screenshot or log]
Possible cause: not confirmed.This is a format example, not a report of an OpenTypeless defect. Replace placeholders with observations you can support; omit private customer data, tokens, and unrelated logs.
Check the bug report before submitting
- Replay the reproduction steps and confirm that another person has enough information to try them.
- Compare dictated identifiers, file paths, versions, URLs, and error strings against their source. Paste exact error text when dictation would risk changing it.
- Keep expected behavior, actual behavior, and your hypothesis in separate fields. Do not add a cause or test outcome merely because a polishing model supplies one.
- Preview Markdown, inspect code fences, and verify the destination repository and issue template before you submit.
Dictate a focused pull request review comment
Start from a line or behavior you inspected in the actual diff. Speak what you observed, why it matters, and a specific question or change request. A dictated review is a text draft; it does not prove the code is correct or that a command was run.
Observation: the reset handler clears the selected label, but the visible list is unchanged.
Impact: users may interpret an empty list as having no matching issues.
Request: could this path also refresh the displayed results?
Verification: please check reset after both an empty and a non-empty filtered result.
Uncertainty: I have not confirmed whether another state update already covers this path.Draft a pull request summary from verified work
- Change: describe the final behavior and point to the relevant part of the diff.
- Reason: explain the concrete user problem the change addresses.
- Validation: report only commands, checks, and results you actually observed. Say “not run” when appropriate.
- Risk: describe the changed behavior a reviewer should inspect and any remaining uncertainty.
Use a polishing prompt that preserves evidence
Format this transcript as a concise GitHub draft.
Preserve identifiers, file paths, quoted error messages, numbers, and negation.
Keep observations separate from hypotheses.
Do not invent reproduction steps, test results, issue links, or causes.
Keep unknown details marked as unknown.
Do not add commands or publish anything.A prompt is an instruction to your selected model, not a guarantee. Compare its output with the transcript and your source material. If the result changes an important detail, correct it or keep the raw draft.
Use dictionary entries as vocabulary
Add recurring project names, APIs, acronyms, and teammate names, then retest them in complete sentences. Dictionary words appear in the LLM polishing prompt; STT-side hint support depends on the chosen speech route. The dictionary does not retrain the recognition model, create command aliases, or guarantee exact identifiers.
Isolate failures by stage
- No recording: check microphone permission and the selected input device.
- Hotkey starts the wrong action: check the recording binding, mode, and application shortcut conflict.
- Transcript arrives but identifiers are wrong: test the speech route and vocabulary, then compare raw and polished text.
- Text arrives in the wrong field or fails to insert: check browser focus, editable-field state, permissions, and undo with a short draft.
- A review includes an invented result: remove it and check the polishing prompt. Verify every statement against the diff and your actual observations.
Finish with a reviewable draft
The workflow is complete when the draft reaches the intended field, its technical details match the evidence, Markdown renders as expected, and you decide whether to submit it. Neither this example nor a successful transcription is a substitute for reviewing the issue or pull request.