Dictation for technical writers: speak the explanation, type the exact interface

Define the audience, prerequisites, goal, scope, and expected outcome before speaking. Follow the project’s content type and style guide rather than converting an unstructured monologue into instructions afterward.

For a procedure, outline each user action and observable result. For a concept, outline the question, mental model, limits, and links to reference material. Dictation fills this structure; it does not replace it.

Mark code spans, commands, flags, environment variables, API names, paths, versions, UI labels, error messages, links, and quotations as exact. Type or paste them from the current primary source and compare character by character.

Do not execute a dictated command. Review it for destructive operations, secrets, environment, permissions, and working directory, then use an isolated test appropriate to the project.

Preview Markdown and generated pages so headings, lists, tables, callouts, code fences, and links are checked as readers see them. Run available linters, link checks, examples, and documentation builds.

Confirm that screenshots and UI terms match the documented version. If behavior was not tested hands-on, say so rather than turning a source claim into an experiential claim.

Use direct language, meaningful headings, consistent terminology, and short steps with results. Remove throat-clearing introduced by conversational drafting and define unavoidable terms at first use.

Optional AI cleanup can silently alter APIs, scope, or certainty. Preserve a diff, reject changes to exact tokens unless verified, and keep sensitive source content out of unapproved providers.