How to Proofread GitHub Comments and PR Descriptions Without Changing Code

The short answer

GitHub issue comments, PR descriptions and review comments are all plain textarea fields, so you can correct them with a browser extension. The catch is that those fields contain Markdown source, including code you do not want touched.

The reliable workflow is to keep prose and code separate. Write the prose part in the textarea, run the correction, read the popup line by line for anything that changed inside a code fence or an inline identifier, and only then Apply. If the description is code-heavy, draft the prose in a scratch tab instead and paste the final Markdown into GitHub.

Which GitHub editors work

GitHub has several different editors, and they are not all the same kind of field. We tested each separately in October 2026 on current stable Chrome, Edge and Firefox under Windows 11.

The safe workflow for a PR description

1. 1

   Write the prose sections first, without code

   Get 'What changed', 'Why' and 'How to test' written in plain sentences. Leave placeholders where the code blocks will go.

2. 2

   Click the One Shot Fix toolbar icon

   The extension is invoked from the browser toolbar only. In Chrome and Edge, pin it from the puzzle-piece menu if it is hidden. In Firefox, use Customize Toolbar.

   There is no keyboard shortcut and no GitHub-specific right-click item, so you cannot trigger it from inside the editor.

3. 3

   Read the popup output line by line

   The popup shows corrected plain text with no diff highlighting. Scan for three things: anything inside backticks that changed, any hyphen or dash at the start of a line that changed, and any URL that changed.

4. 4

   Click Apply

   The corrected Markdown replaces the textarea contents. Nothing is submitted — you still click 'Create pull request' or 'Comment' yourself.

5. 5

   Paste your code blocks in last

   Adding code after the correction pass means the code never went through it. This is the single most effective habit for avoiding corrupted snippets.

6. 6

   Use GitHub's Preview tab

   Before submitting, switch to Preview. A correction that quietly ate a backtick or a list dash shows up immediately as broken rendering.

What a good correction looks like

A failure example you should expect

Here is what goes wrong when you run a correction over a description that already contains code. This is a real class of failure, not a hypothetical one.

## What changed

Moved the retry logic out of `fetchUser()` and into a seperate
`withRetry()` helper.

```ts
const result = await withRetry(() => fetchUser(id), { attempts: 3 });
```

Run `npm test -- --grep retry` to verify

Even with a protected-words list, treat fenced code blocks as off-limits. The correct habit is to add them after the correction pass, as in step 5 above.

Markdown details worth checking by hand

These are the Markdown constructs a prose-oriented correction is most likely to disturb. None of them is a grammar error, and none of them should change.

The Preview tab catches nearly all of these in one glance. Make it a habit rather than an afterthought.

Where this breaks down

Before you open your next PR

Frequently asked questions