Skip to content
SpeakribeGet Speakribe
Use case

Dictation for Linear

The difference between a useful issue and a useless one is the description, and the description is the part everybody skips. Speaking it takes twenty seconds, which is roughly the point at which people stop skipping it.

Why it helps here

Issues get filed as a title and nothing else, because writing the repro steps and the context is a chore at the exact moment you are trying to get back to what you were doing. Two weeks later nobody knows what the issue meant.

Descriptions actually get written

The cost of a proper description drops far enough that writing one stops being a decision.

Comments and updates too

Status updates and handover comments are the other place issues rot. Same shortcut, same speed.

No plugin, no account

Speakribe types into the focused field, so there is nothing to install into Linear and nothing to authorise.

Things people say into Linear

  • “Repro: open the settings page, switch the toggle twice quickly, and the panel renders empty until reload.”
  • “Context: this came from a customer report, it affects anyone on the legacy plan, and there's no workaround.”
  • “Blocked on the API change landing first. Once that ships this is about an hour of work.”
  • “Closing this as won't-fix. The underlying behaviour changed upstream, so it no longer reproduces.”

Setting up for Linear

Linear is built around a keyboard, more so than anything else on this list, and that is the whole setup consideration: pick a binding that does not collide with a keymap where almost every single letter already does something.

  1. Take modifier-only seriously here

    Linear binds bare letters — C creates an issue, and a stray keystroke in the wrong context genuinely changes state. A modifier-only chord cannot collide with any of it, which is a stronger argument in Linear than in any other app here.

  2. Open the description field before speaking

    Creating an issue leaves focus in the title. Tab into the description, or click it, before you start — otherwise a paragraph of description becomes an extremely long issue title.

  3. Add your team's vocabulary

    Project names, service names, the initialisms in every issue you write. Add them to the custom-words list in settings; an issue tracker is close to pure jargon, and this is the app where seeding it pays back fastest.

  4. Dictate the description, type the metadata

    Labels, assignee, estimate, project — all still keyboard. Speak the part that is prose and use Linear's shortcuts for the rest, which is the split that keeps its keyboard-first workflow intact.

One dictation, start to finish

A bug description, spoken in about twenty seconds. Compare it with what actually gets filed when the description costs two minutes of typing: the title, and nothing else.

You said
When you filter the issue list by assignee and then navigate into an issue and come back, the filter is cleared but the URL still has the filter parameter in it. So the list you're looking at doesn't match the URL, and refreshing gives you a different list than the one on screen. It's been happening since we moved to the new router. Not urgent but it's confusing when you share a filtered link with someone.
What landed

When you filter the issue list by assignee and then navigate into an issue and come back, the filter is cleared but the URL still has the filter parameter in it. So the list you're looking at doesn't match the URL, and refreshing gives you a different list than the one on screen. It's been happening since we moved to the new router. Not urgent but it's confusing when you share a filtered link with someone.

  • Steps, actual behaviour, when it started, and severity — all four, because saying them cost nothing. This is the difference the section is about: not better writing, just writing that exists.
  • "URL" and "router" came through fine. An internal service name would not have, which is what the custom-words list is for in a tracker full of them.
  • One paragraph, no bullets. Linear supports markdown, but none of it is spoken — the structure is a pass you make afterwards, if you want it.

What it won't do in Linear

No markdown by voice

Linear's description field takes markdown; Speakribe does not speak it. Bullets, headings and code blocks are typed afterwards, and saying "bullet point" writes the words.

It cannot set any field

Assignee, label, priority, project, estimate: none are voice-driven. Speakribe writes into the field you have focused and knows nothing about Linear's data model.

Bare-letter shortcuts are a real hazard

Linear acts on single keystrokes in ways most apps do not. Dictating with the wrong thing focused does not just lose the text, it can create or modify an issue — which is the strongest argument on this page for a modifier-only binding.

Unlisted service names come back wrong

Internal names are the standard miss, and in a tracker they are most of the sentence. The fix is the custom-words list, and it is worth doing before you file fifty issues, not after.

Questions people actually ask

Does it work in Linear's desktop app?
Yes, and in the browser. It types into whichever field has focus.
Can I dictate markdown formatting?
It writes prose; Linear's own markdown shortcuts still apply to the text afterwards.
Will it get technical terms right?
Mostly. Project-specific names are the usual exception, and the app has a custom-words list to teach it those.
Can it set the assignee or labels for me?
No. Speakribe types into the focused field and has no knowledge of Linear's data model. The description is the part it writes; everything else stays on Linear's own keyboard shortcuts, which are faster than speech anyway.
Which shortcut should I use with Linear?
A modifier-only one, more firmly than in any other app here. Linear acts on bare letters, so a stray keystroke can create or change an issue rather than simply doing nothing.

Ready to stop typing?

One payment. Every future update included.