How to Use Lanson Flow with GitHub
Short version: GitHub is where developer intent becomes durable text — issues, PR descriptions, review comments, commit messages. Lanson Flow is an AI voice keyboard built around LiveFinal: text is formed, corrected, and finalized while you speak, so long dictation does not create a long wait at the end. Use Flow to speak into GitHub’s text fields (and the commit boxes / gh prompts around them). Context-aware writing comes second. Optimized for coding scenarios: programming terminology and domain proper nouns with no setup, environment-aware correction, and Content Shield learning proper nouns from recent input. Multilingual output is a strong use case on top — not the product definition.
Why GitHub + voice is a real workflow (not a demo)
Code review and issue tracking fail when the writing is thin:
Typing those well competes with finishing the code. Speaking them is closer to how you already explain the change to a reviewer.
This Cookbook closes the loop after the IDE guides (Cursor / VS Code): same LiveFinal contract, GitHub surfaces.
Competitors publish adjacent “write around code” guidance. The useful question for Lanson Flow is narrower:
When I finish a long PR description out loud, is the writing already finished with me — or do I wait for another full cleanup pass?
That is what LiveFinal is for.
Speak continuously. Your text finishes with you.
Why Lanson Flow fits coding workflows
Lanson Flow is optimized for coding scenarios — not as an IDE plugin, but as voice writing that understands how developers speak:
1. Programming terminology and domain proper nouns — no setup required. Speak idempotency, upsert, webhook, service names, ticket IDs. You do not need a vocabulary import ritual or a marketplace extension for Flow to handle technical nouns.
1. Environment-aware correction. Flow automatically detects the current environment and applies targeted correction so what you speak lands as usable writing in the field you focused.
1. LiveFinal — long spoken instructions finish with you. Progressive finalization while you speak: no matter how long the instruction, input completes as you finish. Long dictation does not create a long wait at the end.
1. Content Shield learns proper nouns from recent input. From what you just said, Flow automatically understands and saves commonly used proper nouns — product names, symbols you keep repeating, team jargon — so later dictation stays consistent.
Still the same contract: focus the text field, then speak. No Screen Reader Mode setup, no voice @file tagging, no invented IDE integrations.
What you need before you start
1. GitHub access (web, and optionally gh CLI / desktop Git UI) to the repos you write in.
1. Lanson Flow from flow.lansonai.com — free to try, with a weekly free quota.
1. A device where Flow can insert text at the cursor — iPhone/iPad are the prominent surfaces on the product site; Mac has limited-availability / beta messaging (macOS 13.0+). Confirm current desktop availability before you promise a Mac-first workflow to a team.
Flow is designed as voice input into the apps you already use — text lands where the keyboard / cursor is. Treat that as the contract: focus the GitHub field (or commit / gh prompt), then speak.
This guide does not claim a GitHub App, Action, review bot, or IDE plugin. Flow does not merge PRs or review code.
The basic loop (web, commit box, CLI)
1. Click into the text field: issue body, PR description, comment box, commit message, gh interactive prompt, etc.
1. Start Lanson Flow the way your device expects (keyboard / Flow control on that platform — verify in-app; shortcuts can change).
1. Speak the whole thought — context, why, test plan, risks, ask for reviewers.
1. Stop when you are done. Under LiveFinal, input should complete with you — finishing the remaining tail, not starting a fresh end-of-utterance rewrite. No matter how long the spoken instruction, long dictation does not create a long wait at the end.
1. Skim once (especially for public repos), then Submit / Commit / Comment — or keep editing by voice or keyboard.
If a terminal or embedded editor is picky about insertion, paste once and continue.
Where to use Flow with GitHub
1) Issues — reproducible and kind
Focus the issue body and dictate:
“Summary: checkout double-charges when the client retries the webhook. Steps: enable retry storm in staging, send two deliveries with the same event ID, observe two charge rows. Expected: one charge. Actual: two. Impact: billing correctness. Happy to take this if nobody owns payments this sprint.”
LiveFinal matters because good issues are long enough to save a round trip.
2) Pull request descriptions — the why and the test plan
Open the PR description field (template welcome) and speak:
“Why: webhook retries double-charged because idempotency lived outside the charge transaction. What changed: move the idempotency upsert into the same DB transaction; add regression test for concurrent deliveries. Test plan: unit test included; manual retry storm on staging. Risk: medium — payments path; rolled out behind flag payments_idempotency_v2. Screenshots: n/a.”
You are still the author of the change. Voice speeds intent capture.
3) Review comments
On a diff line, focus the comment box:
“Can we keep the public error message stable for clients? Internally logging the raw upstream code is fine — just don’t leak it in the JSON body.”
Short comments can be typed; voice helps when the explanation needs two or three sentences of teaching.
4) Commit messages
In your Git UI, IDE Source Control, or git commit editor, focus the message and speak the why:
“Fix webhook double-charge on retry by transactional idempotency check.”
For longer bodies after a subject line, speak a second paragraph with context and follow-ups.
5) gh CLI and terminal workflows
If you use gh issue create, gh pr create, or interactive prompts, focus the terminal / editor that opens and dictate there. Same LiveFinal loop; same paste fallback if the TTY is sticky.
6) Discussions / RFC threads
Long-form GitHub Discussions benefit from the same continuous speaking pattern as Notion specs: structure said out loud, skim, post.
Writing tips that work better when you speak
Prefer complete briefs over telegraphic titles. Reviewers handle structured speech well. Include risk and test plan you would skip at 40 WPM.
Say structure out loud. “Summary… Why… Test plan… Risk… Follow-ups…” — then adjust Markdown headings if needed.
Keep keyboard for Markdown and reviewers. Type code, @reviewer, and checklist boxes; speak the prose around them.
One job per dictation when iterating. Dictate the PR body first. After CI fails, dictate a follow-up comment — don’t mash five topics into one paste.
Public repo hygiene. Skim for secrets, customer names, and internal URLs before you Submit.
LiveFinal: why long GitHub writing is the point
Traditional voice input often feels like:
record → stop → process → clean up → paste
The longer the PR body, the longer the end wait — exactly when you want to request review and move on.
LiveFinal inverts that:
While you speak, text is continuously formed, corrected, and finalized. When you stop, input should complete with you — finishing the remaining tail, not starting another full processing pass. No matter how long the spoken instruction, long dictation does not create a long wait at the end.
So:
Long dictation does not create a long wait at the end.
That maps cleanly to GitHub:
| GitHub job | Why LiveFinal helps |
|---|---|
| Long PR descriptions | Speaking length should not become end-wait length |
| Detailed issues | You can include full repro without rationing words |
| RFC / Discussion posts | Multi-minute thoughts stay interactive |
| Iterative review replies | Each comment finishes with you |
Context-aware voice writing (the second layer)
LiveFinal answers when writing finishes. The second layer is what kind of writing lands on GitHub.
Lanson Flow is not “raw Whisper into the PR box.” Public product framing emphasizes context-aware voice writing: cleanup of fillers, grammar, entities, and continuity across what you already said — supported architecturally by ideas such as StableStream (committed text should stay stable), Content Shield (recognition alone is not enough — and from recent input it automatically understands and saves commonly used proper nouns), and rolling context.
In practice on GitHub, that means you can speak like a human:
…and aim for reviewable Markdown prose, not a transcript you must fully rewrite before reviewers arrive.
Do not oversell: always skim before posting on public or customer-shared repos.
Multilingual use case
If you think in one language and want GitHub text in another, Flow’s multilingual path is a strong use case:
Speak in your language. Write in any language.
Useful for bilingual teams drafting English PR bodies while reasoning aloud in another language.
Do not position Lanson Flow as “a translation keyboard for GitHub.” Translation/cross-lingual output supports LiveFinal writing; it is not the product identity.
Fair boundaries: what this Cookbook does not claim
| Claim type | This guide |
|---|---|
Speak into GitHub text fields / commit boxes / gh prompts | Yes — focus field, use Flow |
| LiveFinal continuous finalization | Core product contract |
| Context-aware cleanup for issues / PRs / commits | Second-layer product story |
| Official GitHub App / Action / review bot | Not claimed |
| Auto code review or merge | Not claimed |
IDE symbol / @file voice tagging | Not claimed |
| Exact free-quota numbers | Soft only — verify /pricing |
Competitors such as Wispr Flow, Superwhisper, and Typeless are legitimate options with different optimizations. Choose on job-to-be-done. Coexistence is fine.
A 10-minute practice path
1. Open a sandbox repo (or a draft PR).
1. Dictate a full PR description (why / what / test plan / risk). Note whether end wait felt tied to speaking length.
1. Open New issue and dictate reproduction steps + expected/actual.
1. Dictate a commit message for a tiny local change.
1. Optionally try gh pr create / an interactive editor and confirm paste behavior in your terminal.
If Mac desktop access is still limited on your account, run the same loop on the device Flow currently supports for you, or request Mac beta access via the path shown on flow.lansonai.com.
FAQ
Does GitHub have built-in dictation?
Not as a full replacement for a system voice keyboard. Most setups use an OS-level or keyboard-level tool that inserts text into GitHub’s inputs (or into your Git commit editor). Lanson Flow is that kind of input surface.
Will Flow review or merge my PR?
No. Flow turns speech into writing in the focused field. You and your reviewers still own code quality and merge decisions.
Is this only for web GitHub?
No. The same loop works anywhere a commit message, issue body, or gh prompt accepts keyboard input — including IDE Source Control boxes covered in the Cursor / VS Code Cookbook articles.
What about privacy / secrets in issues?
Follow your company’s policy for any cloud voice tool. Do not dictate tokens, private keys, or customer data into issues or PRs. Re-read Lanson’s current privacy / data statements on the product site before enterprise rollout.
Start here
1. Get Lanson Flow: flow.lansonai.com
1. Focus a GitHub PR description or issue body.
1. Speak a complete write-up — and notice whether the text finishes with you.
Speak continuously. Your text finishes with you.
That is the Cookbook thesis for GitHub. Everything else is practice.