[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"article-doc:cookbook\u002Fhow-to-use-lanson-flow-with-github:en":3},"---\ntitle: \"How to Use Lanson Flow with GitHub\"\ndescription: \"Dictate GitHub issues, PR descriptions, and commit messages with Lanson Flow — LiveFinal so long write-ups finish with you, not after you stop.\"\nlang: \"en\"\n---\n\n# How to Use Lanson Flow with GitHub\n\n> **Short version:** GitHub is where developer intent becomes durable text — issues, PR descriptions, review comments, commit messages. [Lanson Flow](https:\u002F\u002Fflow.lansonai.com\u002F) 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 \u002F `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.\n\n## Why GitHub + voice is a real workflow (not a demo)\n\nCode review and issue tracking fail when the writing is thin:\n\n- Issues that state reproduction steps, expected vs actual, and impact\n\n- PR bodies that explain *why*, test plan, and risk — not only the diff\n\n- Review comments that teach the next change instead of “nit”\n\n- Commit messages that future-you can search\n\n- Discussion \u002F RFC comments that capture decisions\n\nTyping those well competes with finishing the code. Speaking them is closer to how you already explain the change to a reviewer.\n\nThis Cookbook closes the loop after the IDE guides ([Cursor](\u002Farticle\u002Fcookbook\u002Fhow-to-use-lanson-flow-with-cursor) \u002F [VS Code](\u002Farticle\u002Fcookbook\u002Fhow-to-use-lanson-flow-with-vs-code)): same LiveFinal contract, GitHub surfaces.\n\nCompetitors publish adjacent “write around code” guidance. The useful question for Lanson Flow is narrower:\n\n> **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?**\n\nThat is what **LiveFinal** is for.\n\n> **Speak continuously. Your text finishes with you.**\n\n## Why Lanson Flow fits coding workflows\n\nLanson Flow is **optimized for coding scenarios** — not as an IDE plugin, but as voice writing that understands how developers speak:\n\n1. **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.\n\n1. **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.\n\n1. **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.**\n\n1. **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.\n\nStill the same contract: **focus the text field, then speak.** No Screen Reader Mode setup, no voice `@file` tagging, no invented IDE integrations.\n\n---\n\n## What you need before you start\n\n1. **GitHub** access (web, and optionally `gh` CLI \u002F desktop Git UI) to the repos you write in.\n\n1. **Lanson Flow** from [flow.lansonai.com](https:\u002F\u002Fflow.lansonai.com\u002F) — free to try, with a **weekly free quota**.\n\n1. **A device where Flow can insert text at the cursor** — iPhone\u002FiPad are the prominent surfaces on the product site; **Mac has limited-availability \u002F beta messaging** (macOS 13.0+). Confirm current desktop availability before you promise a Mac-first workflow to a team.\n\nFlow is designed as **voice input into the apps you already use** — text lands where the keyboard \u002F cursor is. Treat that as the contract: **focus the GitHub field (or commit \u002F `gh` prompt), then speak.**\n\nThis guide does **not** claim a GitHub App, Action, review bot, or IDE plugin. Flow does not merge PRs or review code.\n\n---\n\n## The basic loop (web, commit box, CLI)\n\n1. Click into the text field: issue body, PR description, comment box, commit message, `gh` interactive prompt, etc.\n\n1. Start Lanson Flow the way your device expects (keyboard \u002F Flow control on that platform — verify in-app; shortcuts can change).\n\n1. **Speak the whole thought** — context, why, test plan, risks, ask for reviewers.\n\n1. 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.\n\n1. Skim once (especially for public repos), then Submit \u002F Commit \u002F Comment — or keep editing by voice or keyboard.\n\nIf a terminal or embedded editor is picky about insertion, paste once and continue.\n\n---\n\n## Where to use Flow with GitHub\n\n### 1) Issues — reproducible and kind\n\nFocus the issue body and dictate:\n\n> “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.”\n\nLiveFinal matters because good issues are **long enough to save a round trip**.\n\n### 2) Pull request descriptions — the *why* and the test plan\n\nOpen the PR description field (template welcome) and speak:\n\n> “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\u002Fa.”\n\nYou are still the author of the change. Voice speeds **intent capture**.\n\n### 3) Review comments\n\nOn a diff line, focus the comment box:\n\n> “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.”\n\nShort comments can be typed; voice helps when the explanation needs two or three sentences of teaching.\n\n### 4) Commit messages\n\nIn your Git UI, IDE Source Control, or `git commit` editor, focus the message and speak the why:\n\n> “Fix webhook double-charge on retry by transactional idempotency check.”\n\nFor longer bodies after a subject line, speak a second paragraph with context and follow-ups.\n\n### 5) `gh` CLI and terminal workflows\n\nIf you use `gh issue create`, `gh pr create`, or interactive prompts, focus the terminal \u002F editor that opens and dictate there. Same LiveFinal loop; same paste fallback if the TTY is sticky.\n\n### 6) Discussions \u002F RFC threads\n\nLong-form GitHub Discussions benefit from the same continuous speaking pattern as Notion specs: structure said out loud, skim, post.\n\n---\n\n## Writing tips that work better when you speak\n\n**Prefer complete briefs over telegraphic titles.** Reviewers handle structured speech well. Include risk and test plan you would skip at 40 WPM.\n\n**Say structure out loud.** “Summary… Why… Test plan… Risk… Follow-ups…” — then adjust Markdown headings if needed.\n\n**Keep keyboard for Markdown and reviewers.** Type `code`, `@reviewer`, and checklist boxes; speak the prose around them.\n\n**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.\n\n**Public repo hygiene.** Skim for secrets, customer names, and internal URLs before you Submit.\n\n---\n\n## LiveFinal: why long GitHub writing is the point\n\nTraditional voice input often feels like:\n\n**record → stop → process → clean up → paste**\n\nThe longer the PR body, the longer the end wait — exactly when you want to request review and move on.\n\n**LiveFinal** inverts that:\n\n> 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.\n\nSo:\n\n> **Long dictation does not create a long wait at the end.**\n\nThat maps cleanly to GitHub:\n\n| GitHub job | Why LiveFinal helps |\n| --- | --- |\n| Long PR descriptions | Speaking length should not become end-wait length |\n| Detailed issues | You can include full repro without rationing words |\n| RFC \u002F Discussion posts | Multi-minute thoughts stay interactive |\n| Iterative review replies | Each comment finishes with you |\n\n---\n\n## Context-aware voice writing (the second layer)\n\nLiveFinal answers *when* writing finishes. The second layer is *what kind of writing* lands on GitHub.\n\nLanson 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**.\n\nIn practice on GitHub, that means you can speak like a human:\n\n- false starts mid-explanation\n\n- mixed technical nouns and ticket IDs\n\n- conversational review coaching\n\n…and aim for **reviewable Markdown prose**, not a transcript you must fully rewrite before reviewers arrive.\n\nDo not oversell: always skim before posting on public or customer-shared repos.\n\n---\n\n## Multilingual use case\n\nIf you think in one language and want GitHub text in another, Flow’s multilingual path is a strong **use case**:\n\n> **Speak in your language. Write in any language.**\n\nUseful for bilingual teams drafting English PR bodies while reasoning aloud in another language.\n\nDo **not** position Lanson Flow as “a translation keyboard for GitHub.” Translation\u002Fcross-lingual output supports LiveFinal writing; it is not the product identity.\n\n---\n\n## Fair boundaries: what this Cookbook does not claim\n\n| Claim type | This guide |\n| --- | --- |\n| Speak into GitHub text fields \u002F commit boxes \u002F `gh` prompts | Yes — focus field, use Flow |\n| LiveFinal continuous finalization | Core product contract |\n| Context-aware cleanup for issues \u002F PRs \u002F commits | Second-layer product story |\n| Official GitHub App \u002F Action \u002F review bot | **Not claimed** |\n| Auto code review or merge | **Not claimed** |\n| IDE symbol \u002F `@file` voice tagging | **Not claimed** |\n| Exact free-quota numbers | Soft only — verify `\u002Fpricing` |\n\nCompetitors such as [Wispr Flow](https:\u002F\u002Fwisprflow.ai\u002Fuse-cases), [Superwhisper](https:\u002F\u002Fsuperwhisper.com\u002Fvoice-coding), and [Typeless](https:\u002F\u002Fwww.typeless.com\u002F) are legitimate options with different optimizations. Choose on job-to-be-done. Coexistence is fine.\n\n---\n\n## A 10-minute practice path\n\n1. Open a sandbox repo (or a draft PR).\n\n1. Dictate a **full PR description** (why \u002F what \u002F test plan \u002F risk). Note whether end wait felt tied to speaking length.\n\n1. Open **New issue** and dictate reproduction steps + expected\u002Factual.\n\n1. Dictate a **commit message** for a tiny local change.\n\n1. Optionally try `gh pr create` \u002F an interactive editor and confirm paste behavior in your terminal.\n\nIf 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](https:\u002F\u002Fflow.lansonai.com\u002F).\n\n---\n\n## FAQ\n\n### Does GitHub have built-in dictation?\n\nNot 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.\n\n### Will Flow review or merge my PR?\n\nNo. Flow turns speech into writing in the focused field. **You and your reviewers** still own code quality and merge decisions.\n\n### Is this only for web GitHub?\n\nNo. 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](\u002Farticle\u002Fcookbook\u002Fhow-to-use-lanson-flow-with-cursor) \u002F [VS Code](\u002Farticle\u002Fcookbook\u002Fhow-to-use-lanson-flow-with-vs-code) Cookbook articles.\n\n### What about privacy \u002F secrets in issues?\n\nFollow 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 \u002F data statements on the product site before enterprise rollout.\n\n---\n\n## Start here\n\n1. Get Lanson Flow: [flow.lansonai.com](https:\u002F\u002Fflow.lansonai.com\u002F)\n\n1. Focus a GitHub PR description or issue body.\n\n1. Speak a complete write-up — and notice whether the text finishes **with** you.\n\n> **Speak continuously. Your text finishes with you.**\n\nThat is the Cookbook thesis for GitHub. Everything else is practice.\n\n",1790717964350]