Technical Writing Proofreading

Technical Writing Proofreading reviews English technical documents for publication-ready language without rewriting their content. It preserves the author’s voice, structure and argument. Suspected factual errors are flagged for confirmation rather than silently changed. The result is a specific correction checklist, not a rewritten document or a claim of perfect prose.

First read the whole document to identify its type and tone. A tutorial can be conversational; an API reference needs precision. Build a terminology list, checking whether a concept appears under multiple names. Use the document’s most frequent form and note that decision in the checklist. An external glossary applies only when the user supplies one.

Use it when asked to proofread, polish or review an English technical document, README or blog draft, or check consistent jargon. It does not rewrite paragraphs, strengthen arguments, fact-check technical claims or review other languages, translations or localization. A poorly argued document retains that limitation after proofreading. A wordy paragraph receives specific sentence-level findings rather than reconstruction.

The input is the complete document with enough context to identify its audience, form and terminology. Review paragraph by paragraph within six categories.

For spelling, look for transposed letters, doubled words and confused pairs such as affect/effect, its/it’s and complement/compliment. For grammar, check subject-verb agreement, consistent procedural tense, dangling modifiers and articles before singular countable nouns. For punctuation, check consistent Oxford commas, compound-adjective hyphens, spacing after periods and consistent dash-versus-parenthesis usage.

For inline code and proper nouns, commands, file names and paths belong in backticks, while GitHub and JavaScript retain their official casing. For sentence style, prefer active voice, remove filler such as basically, simply, just and very, and keep one idea per sentence. For structure, headings and list items use parallel forms, procedures use imperative numbered steps and acronyms are expanded at first use.

Each checklist item gives Original, Suggestion and Reason with line numbers or short quotes. Mark uncertain statements [verify] instead of forcing a correction. A suspected contradiction of a usual definition remains a request to confirm, not an invented replacement fact. Finish with total item count and a distribution covering typos, grammar, terminology and style, including other identified categories where needed.

The workflow operates on supplied prose and returns the checklist. It claims no external publishing or repository-editing integration. Perform one pass; do not extend the assignment into repeated polishing. A checklist with no defects is a valid deliverable.

The supplied example input is:

This function will be called by the system after the data is ready, you can use it to basically handle the registration of the callback, the timeout is 5 s, examples on github can be referenced.

That example illustrates passive voice, filler, terminology, a run-on sentence and proper-noun casing. Its timeout is illustrative input, not a performance specification. Avoid both typos-only checks that miss terminology and structure, and unsupported factual corrections that introduce new errors.