Dictating pull request descriptions on GitHub

The diff already says what changed. The description exists to say why, and why is prose, which is the part people skimp on because typing it is the last thing between them and a merged branch.

The PR-specific behaviour: the body is pre-filled

If the repository has a file at .github/pull_request_template.md, GitHub loads it into the description field when you open the PR. You are not dictating a document, you are dictating into gaps between headings that already exist. That is easier, not harder, as long as you place the cursor deliberately:

1. Read the template first and decide what goes under each heading before you start talking.
2. Click into the blank line under one heading, dictate that section, stop, then click into the next one.
3. Do not dictate straight through. A spoken new line under the wrong heading buries the test plan inside the summary.

The trap: dictated brackets tick the checklist

Most PR templates are checklists written as task lists. A dictated "open bracket x close bracket" produces a ticked box. So does a stray autocompleted bracket pair. A reviewer reading a template where every box is ticked assumes you ran the checks. Scan the Preview tab for boxes you did not tick on purpose before you open the PR.

The mention and issue pickers behave here exactly as they do in issues: a dictated "at" opens the user autocomplete and a dictated "hash" opens the issue picker. Command+Return submits.

What to dictate and what to type

• Dictate: the motivation, the approach, the tradeoff you accepted and the one you rejected, and the risk you want a reviewer to look at hardest. All of it is prose, and all of it is what makes a review fast.
• Dictate: the test plan as spoken sentences, then format it as bullets afterwards.
• Type: file paths, function names, flag names, version numbers, and anything inside a code fence. Speech gets casing and separators wrong and a wrong identifier sends a reviewer to the wrong file.

Dictate the description

1. Turn Dictation on once: System Settings → Keyboard → Dictation. Full steps in enable dictation on macOS.
2. Open the pull request and click into the description field, section by section.
3. Dictate the prose for that section, then stop before moving the cursor.
4. Type the identifiers and code blocks.
5. Open the Preview tab, check the checkboxes and the mentions, then submit.

If nothing types at all

• GitHub runs in a browser, so the microphone permission belongs to the browser and to the dictation tool, under System Settings → Privacy & Security → Microphone.
• Dictation dead everywhere, not just GitHub: dictation not working on Mac.

One hotkey from the editor to the review

Voice Type inserts the finished text in one go rather than streaming keystrokes, so the autocompletes stay closed, and the same hotkey works in the editor, the terminal, and the review thread: voice typing for Mac.

Keep going

• Dictating GitHub issues without notifying strangers
• Voice typing in VS Code (and the completion engine that edits your comments)
• Dictation in Cursor

Sources

• GitHub Docs: Creating a pull request template for your repository
• GitHub Docs: About task lists
• GitHub Docs: Keyboard shortcuts
• Apple: Dictate messages and documents on Mac