When a proofreading request comes back as a rewrite: keeping the original wording

The night before a client site went live, I pasted their profile text in and wrote one line: please check this for typos. What came back was not a list of typos. It was a cleaner version of the whole paragraph.

It read well. But the phrases the client had chosen to sound a little more formal had been swapped for plainer ones, and two short sentences they had deliberately left apart were now joined into one.

The meaning barely moved. The voice did.

For a while I accepted those rewrites, because the returned text was easier to read than the original. Then I would come back a few days later and no longer remember which words had been theirs. The person asking is the one who decides what may be touched. That is the single rule I hold to now, whatever the document is.

"Proofread this" turns out to be a very wide request

Finding typos. Normalising spelling and punctuation. Fixing grammar. Improving readability. Reordering paragraphs. Every one of those is proofreading. In my head the request meant "typos only", but the phrase itself never said so.

So when the scope is unstated, the request resolves in the most helpful direction available — which is to do all of it.

Most of what felt like unwanted rewriting was really me never naming a boundary. Once I saw that, the thing I added to my prompts stopped being "please be careful" and started being "how far".

This is not a Japanese-language problem, though it shows up most sharply there. As an indie developer I push store descriptions for my wallpaper and healing-sound apps through several languages, and the same drift happens in every one of them. Japanese just makes it louder, because politeness level and sentence endings carry so much of the writer's personality.

Fix the shape of the output first

The line that changed the most was not a politer request. It was a constraint on the output format.

Please proofread the following text.
 
[Output format]
Do not output the body text. Return only the findings, as a table with these columns:
- number
- original (quote only the span in question)
- type (typo / spelling / inconsistency / grammar / other)
- reason
- suggestion
 
[Text]
(paste the body here)

Once the body text is part of the output, the work becomes "produce a corrected version". Ask for findings only, and the decision to apply each one stays on your desk. The shape of the output decided the nature of the work far more than the tone of my request ever did.

What comes back looks like this.

| no | original    | type          | reason                              | suggestion   |
|  1 | recieve     | typo          | misspelling                         | receive      |
|  2 | e-mail      | inconsistency | body text also uses "email"         | email        |

Since adding "do not output the body text", a full replacement has almost never come back to me.

Declare three layers, and what happens to each

"Change nothing" is not useful either, because then the real typos survive. So I split edits into three layers and state the default handling for each before asking.

Four lines go into the prompt.

[Scope]
- Surface (typos, spelling, capitalisation, number formatting): fix these directly.
- Word choice (synonyms, repetition): suggest alternatives only. I decide.
- Structure (sentence endings, word order, splitting/merging, paragraph order): do not touch.

Three layers rather than two, because a binary choice always costs something. Hand over everything and the text stops sounding like its author. Hand over nothing and the typos ship. Surface goes out, structure stays home — that is the line that has felt right to me.

Show one pair: what to change, what to keep

Telling a model to "preserve the polite tone" leaves the definition of polite entirely open. A phrasing I chose for warmth can reasonably be read as padding.

An example pair travels faster than an explanation.

[Voice examples]
Change: "e-mail" -> "email" (house style)
Keep:   "I would rather not" -> "I don't want to" (the hedge is intentional)

Two lines, and the suggestions to flatten my hedges stopped appearing.

Pick the example from whatever has annoyed you most in the past. For me it was sentence endings; for someone else it might be comma placement, or sentence fragments used on purpose. One pair is usually enough, two at the most. Past three, the examples start steering the whole review and the findings thin out.

Count something before you read the findings

Before I read the table at all, I check two things: whether the number of paragraphs and sentences has changed, and whether the distribution of sentence endings has changed.

If you would rather not write code, your editor's find-and-count is plenty — search for the endings or phrases you use most and compare the counts before and after. A large swing means the structure was touched.

If you do want to measure it, a short script covers it.

import re
from pathlib import Path
 
# Longer endings first, so they match before their shorter substrings.
ENDINGS = ["I would rather", "I think", "we can", "it is", "there is"]
 
 
def ending_counts(text: str) -> dict:
    """Count the phrases you care about, to compare a draft before and after review."""
    sentences = [s.strip() for s in re.split(r"(?<=[.!?])\s+", text) if s.strip()]
    counts = {phrase: 0 for phrase in ENDINGS}
    counts["sentences"] = len(sentences)
    for sentence in sentences:
        lowered = sentence.lower()
        for phrase in ENDINGS:
            if phrase.lower() in lowered:
                counts[phrase] += 1
                break
    return counts
 
 
before = ending_counts(Path("draft_before.txt").read_text(encoding="utf-8"))
after = ending_counts(Path("draft_after.txt").read_text(encoding="utf-8"))
 
for key in before:
    if before[key] != after[key]:
        print(f"{key}: {before[key]} -> {after[key]}")

The output reads like this.

I would rather: 6 -> 1
we can: 3 -> 8
sentences: 41 -> 36

Three lines like that, and you are looking at a rewrite rather than a proofread. You know it before spending twenty minutes weighing individual suggestions.

Swap the phrase list for your own habits. Mine leans on hedges, so those go first; if you write in fragments, counting lines that do not end in a period will tell you more.

How detailed the findings are also depends on which model you hand the job to. A short document's surface check runs perfectly well on a lighter model, and I wrote up how I make that call in Claude Sonnet 4.6 vs Opus 4.6 — A Task-by-Task Selection Guide From Daily Use. For holding a voice steady across several languages at once, Automating Multilingual App Review Replies with Claude API is the closer piece.

Start with a single paragraph, asked for as findings only with no body text. One paragraph takes a couple of minutes to review in full, and whichever finding makes you think "I did not want that one" becomes the next line you add to the prompt.

I still hesitate over how much to delegate when a client's draft is in front of me. If any of this helps you keep more of your own words, I am glad. Thank you for reading.