Voice workflows

Write pull request descriptions by voice

Review the diff first, then dictate the problem, the change in behavior, and the validation into the pull request description. Edit the draft against the code and test output. A useful PR description tells a reviewer what changed and how to assess it.

By WhisperJot · Documentation reviewed

Collect the facts

Explain the final implementation. The reviewer does not need the history of every attempted solution unless an abandoned approach explains an important tradeoff.

  1. Read the final diff, including tests and configuration changes.
  2. Identify the user action that previously produced the problem and what happens after the change.
  3. Run the relevant checks and keep their exact names and results. Mark unrun checks explicitly.

Dictate a draft into the description field

Click into the PR body or a local Markdown draft. Speak the explanation in short paragraphs, then add headings and code formatting manually if needed. This example is fictional; replace the behavior and validation with what your change actually does.

Illustrative example — edit before using
Submitting the signup form twice could start duplicate requests. The submit button now stays disabled while a request is pending and becomes available again after an error.

Validation: [paste the checks you ran and their results].

Limitations: [describe any relevant behavior that remains untested].

Make the description reviewable

WhisperJot transcribes your explanation; it does not inspect the repository or execute tests as part of dictation. If an AI assistant helps summarize a diff, you still need to verify the summary against the actual change.

  1. Compare every claim with the diff. Remove any behavior that was planned but did not ship.
  2. Verify function names and paths after dictation. Format identifiers as code using the editor.
  3. Distinguish automated checks from manual observations, then preview the description before publishing.

Questions

Can I dictate Markdown?

You can dictate the prose into a Markdown field. Review headings, lists, backticks, and links in the preview; exact markup may be easier to enter with the keyboard.

Should I list every test in the PR?

Include the checks that support the change and any relevant gaps. Use actual results. A concise validation statement is more useful than a long list of unrelated checks.

Sources and related guides

Product behavior is based on the documentation below, reviewed 2026-09-09. Examples are authored illustrations; measurement worksheets are for your own observations.

Keep going