Proofread Business Emails with Claude Code: Tone, Register, and Natural English

Use Claude Code to fix unnatural phrasing and mismatched register in business emails — with a two-pass workflow that builds your English intuition over time.

If you write business emails in English as a non-native speaker, you already know the problem: the grammar checks out, but something still feels off. "I will do my best effort to finish the report until Friday" is technically parseable, but no native English speaker writes that. Claude Code bridges that gap — not just catching grammar mistakes, but flagging unnatural phrasing and mismatched register. Here's the workflow I've been using.

Section 1: The Problem — Direct Translation Sounds Like Direct Translation

The most dangerous mistake isn't a grammar error. It's literal translation from your native language into English. The sentence structure is valid, the words exist, but a native reader immediately senses something mechanical about it.

Take this example I actually tested:

Dear Mr. Smith,
I will do my best effort to finish the report until Friday.
Please understand that our team is very hard working on this project.

Three problems in two sentences. "Do my best effort" is a mashup of "do my best" and "make every effort." "Until Friday" should be "by Friday" — until implies an ongoing action up to that point; by sets a deadline. "Very hard working" reads like a direct lift from a Korean phrase.

The fix isn't just swapping words — it's understanding why the phrasing fails. That diagnosis step matters.

Here's the command I ran (on a Mac with Claude Code, response came back in under 4 seconds):

claude "Proofread the following business email. It's a formal email to a global client. \
For each issue, explain: (1) the awkward phrasing, (2) the register mismatch, \
(3) the natural native-speaker alternative. Then output the full corrected version.

[Original]
Dear Mr. Smith,
I will do my best effort to finish the report until Friday. \
Please understand that our team is very hard working on this project."

Claude's output breaks down each problem before handing you the corrected version. You see what changed and why — which is the part most proofreading tools skip entirely.

Section 2: The Fix — Register Is the Whole Game

Grammar is table stakes. Register is what separates a usable email from a great one. The same information lands completely differently depending on whether you're emailing a CEO, a peer, or a cross-department senior manager you've never met.

If you don't specify register, Claude picks one. Sometimes it guesses right. Often it doesn't. Always tell it explicitly.

I use three tiers:

Tier	When to use	Example recipient
formal	Executive stakeholders, legal/compliance, first cold outreach	C-suite, external legal counsel
semi-formal	Cross-functional colleagues, senior managers in other departments	A senior PM you've emailed twice
casual	Direct teammates, close collaborators	Your squad's Slack message

Here's the command pattern that works best for the middle tier — the one I use most:

claude "Proofread the email below with a semi-formal tone. \
Context: this is a collaboration request to a senior manager in another department — \
not my direct boss, but more senior than me. Keep it professional without being stiff. \
Output a side-by-side before/after comparison.

[Email]
..."

The before/after format is intentional. Seeing both versions next to each other helps you internalize what changed, not just accept the output blindly.

Section 3: Two-Pass Workflow — Diagnose First, Correct Second

The biggest mistake I made early on: asking for the corrected version in a single prompt. You get clean output, but you have no idea what you did wrong. Next email, same mistakes.

What worked for me was splitting it into two passes:

Pass 1 — Diagnosis only:

claude "Pass 1 only: List every awkward, unnatural, or register-inappropriate phrase \
in the email below. Do not rewrite anything yet. Just diagnose. \
Explain each issue in one sentence.

[Email]
..."

Pass 2 — Correction based on the diagnosis:

claude "Pass 2: Using the issues identified above, output a fully corrected version \
of the email. Keep the same intent and structure, just fix what we flagged."

Why does this work better? The diagnosis pass forces you to engage with the actual problems. You start recognizing patterns — the preposition errors, the Japanese/Korean calque phrases that sneak in, the over-reliance on passive voice in formal contexts. After a few weeks of this, you start catching these issues yourself before you even run the command.

Here's a gotcha I hit: if you do both passes in the same prompt, Claude sometimes rationalizes its own corrections and softens the diagnosis. Separate prompts give you sharper, more honest feedback.

Section 4: Variations and Gotchas

Lock in your context once with CLAUDE.md

Running long context prompts every time gets old fast. If you're in a B2B SaaS company emailing US and European partners, just write that once:

# Email Context

- Company type: Global B2B SaaS
- Primary recipients: US and European partner contacts
- Default tone: semi-formal
- Industry: [your vertical]
- My role: [your role, so Claude calibrates seniority]

Drop this in your project's CLAUDE.md. From that point on, every claude session in that directory starts with that context loaded. You stop re-explaining the situation every time and your prompts shrink from five lines to one.

Environment differences

Environment	Behavior
macOS terminal (tested)	Response in under 4 seconds for single-email proofread
Docker / remote dev	Add --no-tty if piping email content from a file
n8n workflow	Wrap the claude invocation in an Execute Command node; capture stdout for the corrected version

Pitfalls to avoid

• Don't skip the register specification. "Proofread this" with no context produces middle-of-the-road output that often lands in no-man's-land — too casual for a formal thread, too stiff for a teammate.
• Don't feed Claude a 400-word email and ask it to "fix everything." Break it into sections or use the two-pass approach; longer inputs produce vaguer diagnoses.
• Don't ignore the explanation. If Claude flags "I hope this email finds you well" as filler and suggests removing it — that's a real native-speaker preference. Note it.

Closing

The leverage here isn't proofreading speed — it's that specifying context (register, relationship, purpose) transforms Claude from a grammar checker into something closer to a native English colleague reviewing your draft. The two-pass approach builds that sensitivity over time rather than just producing one-off clean output.

Next step: if you send similar email types repeatedly(status updates, collaboration requests, escalation notices), build a small library of CLAUDE.md snippets for each type. One command, consistent output, zero re-explaining.

---

🐦 Faster updates on X: @baegseungh7061
📚 More in this series: Code Intro
💌 Subscribe: Follow on X or grab the RSS