Most of the emails I rewrite start the same way: a draft that is almost right but still somehow wrong. The point is buried. The tone feels either too stiff or too casual. A request sits in the middle of a long paragraph where no one will find it. I used to spend more time staring at those drafts than I spent writing them.
Then I stopped trying to invent a perfect rewrite every time and built a short, reusable prompt instead. The goal was simple. Give the model just enough instruction to make the email clearer and shorter while protecting the meaning and the voice that already belonged to me. Everything else was optional.
That small prompt has saved more time than any elaborate template I ever collected. Here is the version I still use, why each part exists, and how to adapt it when the situation changes.
The Baseline Prompt
Rewrite this email so it is clearer and shorter while keeping my natural voice.
Put the main request or point near the top.
Remove unnecessary background.
Do not add new information or commitments.
If any sentence could change the original meaning, flag it at the end.
That is the entire core. Five short lines. I keep this as V1 and only add to it when a specific, repeated problem appears.
Why These Five Lines Work
Most rewrite prompts fail for one of two reasons. They either ask the model to “make it better” without defining better, or they overload the instructions until the model starts inventing improvements no one requested.
The baseline above avoids both traps.
“Clearer and shorter” gives a measurable direction without requiring the model to invent a new personality.
“Keeping my natural voice” protects the parts of the draft that already sound like the writer.
“Main request near the top” fixes the most common structural problem in professional email.
“Remove unnecessary background” targets the filler that slows readers down.
“Do not add new information or commitments” stops the model from politely agreeing to things the original writer never offered.
The final flag instruction creates a safety net for meaning drift.
I tested longer versions that included tone adjectives, role descriptions, and formatting rules. Some of them produced nicer-looking paragraphs. None of them consistently outperformed this shorter set on real drafts.
How I Actually Use It
I paste the draft under the prompt and run it once. Then I read the output the same way I would read a colleague’s suggested edit. I keep what helps, change what does not, and ignore anything that feels like the model trying too hard.
Here is a realistic before-and-after from a typical workday.
Original draft:
Hi Jordan,
I hope you’re doing well. I wanted to follow up on the conversation we had last week about the Q3 report timeline. As you know, we’ve been dealing with some delays on the data side and I wanted to make sure we’re still aligned on the delivery date we discussed. I think we said the 15th but I just want to confirm because a few other dependencies have come up on my end. Let me know what works for you. Thanks so much!
Maren
Rewritten with the baseline prompt:
Hi Jordan,
Can we confirm the Q3 report is still due on the 15th?
A few data delays and new dependencies have come up on my side, so I want to make sure the date still works.
Thanks,
Maren
The second version is not more impressive. It is simply easier to answer. That is the point.
Variables Worth Adding (Only When Needed)
I treat every addition as a testable change rather than an automatic improvement. The three variables I add most often are:
Length limit
When the original draft is already long and the reader is senior or very busy, I add one line:
Keep the rewritten email under 80 words.
Tone adjustment
If the draft needs to sound more formal or more direct than my default voice, I name the shift instead of using vague words:
Make the tone slightly more formal while still sounding like me.
Explicit call-to-action placement
For emails that end with a buried ask, I sometimes strengthen the structure:
End with one clear question or request.
I never add all three at once. I change one, compare the result to the baseline, and keep the change only if the improvement is obvious.
Common Failure Modes and How the Prompt Handles Them
Even a short prompt can drift. Here are the problems I see most often and the small adjustments that fix them.
The model softens a direct request.
Some models prefer polite hedging. If the rewrite turns “Please send the file by Friday” into “It would be great if you could send the file by Friday when you have a chance,” I add:
Keep direct requests direct. Do not soften them.
The model invents context.
Occasionally the rewrite adds a reason or background that was never in the original. The “do not add new information” line already covers this, but when it still happens I make the instruction more concrete:
Do not invent reasons, timelines, or background that are not in the original email.
The voice disappears.
If the output starts sounding like a generic template, I temporarily strengthen the voice instruction:
Preserve my sentence rhythm and word choice as much as possible. Prefer short sentences where I used them.
These fixes stay temporary. Once the specific problem stops appearing, I remove the extra line so the baseline stays lean.
A Simple Testing Method for Your Own Drafts
If you want to decide whether this prompt (or any variation) is worth keeping, run a quick comparison.
Take three real emails you have sent or nearly sent in the past month.
Run the baseline prompt on each one.
For each rewrite, ask only two questions:
Is the main point easier to find?
Did the meaning stay intact?
If both answers are yes for at least two of the three emails, the prompt is already useful.
Only then experiment with one added variable at a time.
I still do this check whenever I am tempted to “improve” the prompt with more instructions. Most of the time the original five lines win.
When Not to Use an AI Rewrite
There are moments when the prompt is the wrong tool. I do not use it for:
Messages that carry significant legal, financial, or personnel weight
Emails where the emotional tone is the entire point (apologies, congratulations, difficult feedback)
Drafts that are already clear and only need a quick human polish
In those cases the cost of an unnoticed shift in meaning is higher than the time saved. The prompt is a practical aid for everyday clarity, not a replacement for judgment.
Building Your Own Version
You can start with the exact baseline above and treat it as V1. After you have used it on a dozen real drafts, look at the places where you keep making the same manual edit. Those repeated edits are candidates for a single new instruction.
Add the instruction. Compare. Keep it only if the new version is clearly better across different emails. Discard it if the improvement is small or inconsistent.
That process is slower than downloading a long “ultimate email prompt.” It produces something you actually understand and trust. Over time the prompt becomes less of a magic spell and more of a working method you can adjust when the work itself changes.
Final Working Version I Keep in My Notes
For reference, here is the version that has survived the most rounds of testing for general professional use:
Rewrite this email so it is clearer and shorter while keeping my natural voice.
Put the main request or point near the top.
Remove unnecessary background.
Do not add new information or commitments.
If any sentence could change the original meaning, flag it at the end.
When I need a stricter length limit or a slight tone shift, I add one line underneath and test it. The core stays the same.
Clear and short beats clever and long. Start with the smallest useful version, protect the meaning, and only add complexity when the evidence says it helps.
No notes on this sheet yet.