GitHub Dictation on Windows: PR Review Comments 2026

Speak the explanation. Keep code suggestions and the final review decision under your control.

For GitHub dictation on Windows, open a pull request’s comment box and click inside it. Press Windows key + H, speak your comment, then stop listening and check the text. Use GitHub’s controls to save or submit it. Voice input can enter words, but it shouldn’t decide whether to approve a change. ^[1] ^[2]

This guide covers browser-based pull-request reviews on Windows 11, including inline feedback, pending comments, and review summaries. It’s based on source material and setup steps, not tests of every browser or repository configuration. By Ryan Shrott, founder of DictaFlow. The code-review example below is fictional.

Start in the comment editor, not the diff

Open the pull request and read its summary before you comment. In Files changed, select a line and open the comment box. You can also comment on a range of lines. GitHub’s review quickstart says to choose Start a review to save a comment as pending until you submit it. Only you can see pending comments. ^[1]

Before using voice, type a few characters in the editor, then delete them. This quick check prevents a common setup mistake: selecting a line of code without activating an editable field. A highlighted diff isn’t the comment box.

Press Windows key + H and wait for the listening indicator. Microsoft requires an internet connection, a working microphone, and a cursor in a text box. Click the microphone control to stop before clicking elsewhere. These steps use Windows voice typing, not a GitHub-specific voice integration. ^[2]

Try a one-sentence comment on a practice pull request where you’re allowed to experiment. Leave it pending instead of learning the controls during a production review. Check the text in the editor, then review the comment after you save it. An accurate microphone transcript doesn’t guarantee your feedback landed on the right line.

Dictate the reasoning and paste exact identifiers

Code reviews include two kinds of text. Explanations can usually be written in ordinary prose, but function names, flags, paths, and replacement snippets need to be exact. Copy identifiers from the diff instead of asking speech recognition to guess punctuation and capitalization.

For a fictional retry handler, the comment might say: “The timeout path may retry after a successful charge. Can we return the existing receipt before starting another payment attempt? Please add a regression test for a completed charge followed by a delayed response.”

Record that explanation in one or two short clips. Then add the actual function name or test path from the repository. Check that the final sentence requests a test rather than claiming one already exists. Also, “may retry” is weaker than “always retries.” Changing it makes the concern sound like a stronger finding than the evidence supports.

A comment is more useful when it gives the author something to check. Name the branch you saw and the condition that concerns you. If you haven’t reproduced the behavior, say so. Don’t turn a tentative concern into a definite bug report just because a writing tool favors firm wording.

For your first voice-input trial, don't dictate literal code. To suggest an exact replacement, use GitHub's comment toolbar to insert a suggestion block. Fill it with verified code, then inspect the diff before submitting. Spoken prose that explains a fix isn't an executable replacement. ^[1]

Pending feedback is different from a submitted review

Stop recording before you open the final review panel. Read every pending comment, including those on files that aren’t currently on screen. In your final pass, check whether each comment still applies to the current code and whether an earlier draft repeats a point made later.

GitHub's Submit review flow asks for a summary and a decision. Comment leaves feedback without approving or requesting changes. Approve says the work is ready to merge, and Request changes flags work the author needs to address. Choose the decision using the review controls. Typing approved in the summary won't select that decision for you. ^[1]

Use the summary to state the main finding instead of repeating every inline note. For example: “I still have one question about the retry path.” Keep naming suggestions optional. That shows the author which concern needs attention without making every wording preference a blocker.

Before you submit, check the repository, pull-request number, and review decision you selected. Don’t say submission shortcuts during your test. If the input tool recognizes navigation or editing commands, casual speech can do more than enter text. Microsoft documents both voice commands and ordinary dictation. ^[2]

When a dedicated dictation app is worth trying

If you review text only now and then and it needs little editing, start with Windows voice typing. A paid tool may be worth it if you use the same terms in GitHub, your IDE, issue tracker, and team chat. Compare how long you spend correcting and placing text, not just how fast the transcript appears.

DictaFlow lets you hold a key to dictate and add custom words or text expansions in its Knowledge Base. Its Windows setup guide lists Ctrl + Win as the default trigger. Hold your chosen shortcut, speak, then release it to insert the text. Pick a shortcut that doesn't conflict with your other tools. DictaFlow enters text across Windows; it doesn't inspect a GitHub repository or manage reviews. ^[3] ^[4]

Add a few project names that come up often to the vocabulary, then repeat the same practice comment. This may help recognition, but it won’t check identifiers against the codebase. Check exact names against the diff. App-aware formatting also doesn’t ensure two browser fields get different formatting. ^[3] ^[4]

A new Consumer Pro subscription bought directly through desktop or web costs $9/month or $84/year, which works out to $7/month with annual billing. Store offers and existing subscriptions may have different prices. DictaFlow's facts page lists a Free plan, so try insertion before paying. Prices were checked against the live subscription endpoint on October 27, 2026. ^[3] ^[5]

DictaFlow has native apps for Windows, Mac, iPhone, iPad, and Android, but this guide covers browser setup on Windows, not mobile. Cloud transcription is the default. Local Offline is a separate option on supported devices, but cloud AI cleanup still sends your text and relevant editing context online. Follow your organization’s rules for approved tools when handling confidential code or review material. ^[3]

If text disappears, isolate the field before changing the mic

If the voice tool hears you but doesn’t show any text, try saying a harmless sentence in Notepad. If that doesn’t work either, check the selected microphone, permissions, or input method. If it works in Notepad, go back to GitHub, reopen the comment editor, and check again whether typed characters appear. Note which browser and field failed.

If text appears twice, pause and compare the destination with the transcript before recording again. Copy long comments before opening another file or refreshing the page. If a field is slow to update, don't keep submitting or restart the recording.

DictaFlow normally inserts text in Windows by pasting from the clipboard. Its optional Typing Mode sends characters instead. The setup guide explains how to turn it on and adjust delays for difficult fields. If normal insertion fails, test it in a disposable comment. This doesn’t guarantee GitHub compatibility or give you permission to bypass managed-device restrictions. ^[3] ^[4]

If Windows voice typing handles your reviews well, keep using it. Try DictaFlow if hold-to-talk and reusable terminology would cut down on repeated edits across apps. Either way, check the finished comment in GitHub. Make sure it is on the right line, uses exact identifiers, and reflects your level of certainty. Then check the review decision separately before submitting.