Voice-to-text for commit messages and PR descriptions

Explaining a change aloud can produce a useful first draft of a commit message or pull request description. The work is checking that the explanation matches what changed. A spoken intention such as “this should fix retries” is not evidence that the patch fixed them.

This guide combines an editorial workflow with Git and GitHub documentation checked on September 11, 2026. The message examples are illustrative, not transcripts from a recorded dictation or results from a real product fix. For requests sent before coding, use the separate Cursor voice-prompt guide.

Begin with the actual change

Before drafting a commit message, inspect the files and hunks you staged. A commit message should describe that snapshot, which may be smaller than everything still changed in your working tree.

After staging the intended files using your normal workflow, these read-only commands help inspect the staged scope:

git diff --cached --stat
git diff --cached

For a PR description, inspect the pull request's full diff against its intended base branch. Do not assume the latest commit alone covers everything in the PR. Read any existing repository template and contribution instructions before choosing a format.

Say three things in a plain text editor: what triggered the problem, what now happens, and why that behavior is appropriate. Leave exact filenames and issue numbers to typing or copying if dictation does not preserve them reliably.

Turn an explanation into a focused commit message

Imagine a patch that really stops retries after HTTP 401 while leaving rate-limit handling unchanged. A spoken draft might be:

We were retrying requests even when authentication had failed. This change stops that retry path for 401 responses and keeps the existing rate-limit behavior.

A reviewed message for that illustrative patch could be:

Stop retries after authentication rejection

Return the HTTP 401 response without another retry.
Preserve the existing rate-limit handling.

Use this only if the staged diff actually does those things. The example does not claim tests passed. If the patch changes a different status code, retry policy or failure path, rewrite the explanation instead of keeping an attractive summary.

Download the commit message template to replace the placeholders with your own change. Keep the subject specific and put useful rationale in the body. You do not need a fixed number of paragraphs for a one-line fix.

Follow the repository's commit convention

If the project uses Conventional Commits, a subject may use the form fix(retry): stop retries after authentication rejection. The specification distinguishes fix, feat and breaking-change markers; choose them from the actual behavior and project rules.

Do not dictate feat simply because the change is new to you, or add a breaking-change marker to make the message look thorough. A repository that uses ordinary imperative subjects does not need a new convention for this workflow.

For recurring mistakes in tool names, use the developer dictionary guide. Still check punctuation, scope names, issue numbers and casing in the final text.

Pass the reviewed message to Git as a file

Save the finished message as commit-message.txt in the parent directory of the repository for the following example. Confirm that location is appropriate on your machine. The file is outside the tracked working tree, so it will not accidentally become part of the staged patch.

From the repository root, after reviewing the staged diff:

git commit --file ../commit-message.txt

The Git commit reference documents --file as reading the message from a file. This command creates a local commit from the staged changes; it does not stage every modified file, create a GitHub PR or push a branch. Repository hooks and signing requirements still apply.

Using a file also avoids assembling a shell command containing dictated prose and nested quotes. Read the file before running the command. If you use an editor or Git client instead, put the same reviewed text into its message field.

The read-only commands and file-based commit were checked in an isolated temporary Git repository for this article. That verifies the Git workflow, not speech recognition or the correctness of the illustrative retry patch.

Give the PR reviewer the context they need

A PR body can cover several commits and should explain the resulting behavior of the whole change. Start with the concrete trigger and outcome, then include validation that was actually performed and any remaining limitation relevant to review.

Use the PR description template as an optional starting point. It separates the problem, resulting behavior, verification and remaining questions. Replace every placeholder; do not check off a test merely because you intend to run it.

GitHub's pull request template documentation supports .github/pull_request_template.md, among other locations. A repository template becomes available to collaborators after it is merged into the default branch. Downloading this sample alone does not install it in your project; adapt the project's existing template if it has one.

Dictate into a draft editor or the PR body field, then read the complete description before publishing. If Flow produced text but did not insert it, recover it using the text insertion troubleshooting guide instead of re-speaking and accidentally losing a qualification.

Verify the claims before sending

Compare every behavior claim with the diff. Distinguish “tested,” “not tested” and “expected”; include the exact check and observed result when useful. If a test failed, report the relevant failure rather than allowing cleanup to turn it into a success statement.

Check references, version numbers and negations manually. Remove conversational filler and unrelated implementation history. If the scope changed during development, rewrite the subject and PR opening around the final change.

To judge whether voice helps, compare total drafting and correction time for similarly sized changes. A longer spoken description is not automatically a better review artifact. The useful output is a short, accurate account that another developer can verify against the code.

If your voice note also contains follow-up work, the n8n transcript workflow keeps those task candidates separate from the commit message.