The prose around the code
Count what you typed yesterday. Some of it was code. A lot of it was explanation: why a change was made, what a reviewer should look at, what the bug looks like from the user's side, what you want an AI coding assistant to do next. That text matters, and it is the first thing people cut short when they are tired of typing.
Explaining a change out loud is usually faster and more complete than typing it. Reeve turns that explanation into text where your cursor is: hold fn, talk, release.
One line in the terminal
A terminal is a bad place for paragraphs. Reeve checks the app and window you are in before it writes, and in a terminal it writes a single line with no filler. Say this with your cursor inside the quotes of a commit command:
okay so this fixes the race in the session refresh when the token expires in the middle of a request
and the line reads:
$ git commit -m "Fix race in session refresh when the token expires mid-request"The same sentence said in a pull request description in the browser comes out as a full paragraph, because that window has its own rule.
Rules per app and per window
Every app can have its own formatting rule, and a rule can match on the window title as well as the app. That is useful for developers, because the same browser holds very different kinds of writing. A few rules you might set up:
| Where | Rule |
|---|---|
| Terminal | One line, imperative mood, no trailing period |
| Code editor | Short, plain sentences suitable for a code comment |
| Browser, title contains “Pull request” | Paragraphs, with a short summary first and a list of changes |
| Issue tracker | Steps to reproduce as a numbered list |
| Team chat | Casual, short, no sign-off |
You edit the rules in Reeve's settings, so you can tune them to your team's conventions.
Identifiers stay as you wrote them
Dictation tools love to “correct” technical words into English. A function name becomes three words, a CLI tool becomes something that sounds like it. Reeve keeps identifiers verbatim, and when a term does come out wrong, you fix it once and Reeve remembers your version next time. Library names, internal service names and the colleague whose name everyone misspells all end up in that memory.
Commit messages, PRs and review comments
A workflow that works well:
- Stage your changes and start the commit. Say what changed and why, in one breath. Reeve writes the one-liner.
- Open the pull request and talk through the change for thirty seconds: the problem, the approach, what you tested, what you are unsure about. Reeve writes it as paragraphs.
- If the description came out long, mark it, hold the key and say “cut this to five bullet points”. Reeve rewrites the marked text in place.
The same applies to review comments. Saying “I think this breaks when the list is empty, can we add a guard and a test for that” is quicker than typing it, and it reads friendlier than the clipped version you would have typed.
Prompts for AI coding assistants
Long, specific prompts get better results from coding assistants, and long prompts are exactly what people avoid typing. Talk through the task, the constraints and the files involved. For prompts that run for minutes, Reeve sends the audio in slices of about 20 seconds while you talk, so the full text arrives seconds after you stop. See the long dictation guide.
Where your audio goes
No Reeve server ever sees your audio or text. Audio goes from your Mac to the AI provider you chose, under your own key, and Reeve keeps no recordings. Your key is stored in the macOS Keychain. The usual rule still applies: do not dictate secrets, tokens or passwords. Read the privacy page for the full picture.
When a field will not accept text
Some terminals, remote desktops and custom editors swallow synthetic keystrokes. Every result is also placed on the clipboard, so you can paste it with ⌘V if nothing appears.