I Built a Personal Writing Editor Gem — Here's What It Actually Does

Keywords: writing editor, AI editor, Gemini Gem, technical writing, runbook editing, voice preservation, second-pass editing

Reading time: ~7 minutes

Most of what I write professionally is technical documentation — runbooks, change records, network diagrams with explanations, internal incident reports. I write clearly enough for my purposes, but I want a second pass on anything going outside the team: client-facing documentation, blog posts, anything with a wider audience.

For years the second pass was either a coworker asking them to read it (costly in their time) or just my own re-reading (unreliable because I see what I meant to write, not what's on the page). My Personal Writing Editor Gem handles the second pass now. It edits my drafts the way a thoughtful editor would — not just catching grammar errors, but flagging where I've buried the point, where my tone is off for the audience, or where a paragraph reads as confusing even if every sentence is technically correct.

The Problem I Was Trying to Solve

Three specific patterns kept showing up in my writing without an editor:

First, sentences that were technically correct but confusing. I'd write "the routing change was implemented via configuration updates to the edge devices, with verification performed through subsequent traffic analysis" — which is accurate, but requires the reader to parse it twice. A simpler version ("we updated the edge devices and verified by watching traffic") would have been clearer without losing meaning.

Second, paragraphs where I buried the key point. I'd write three sentences of background before getting to what the reader actually needed to know. In a runbook that might be fine — context is the point. In a status update or client email, it wastes the reader's time.

Third, tone mismatch with audience. A document going to internal engineers could be terse and assume context. The same content going to a client needed a softer opening, more explanation, less assumed knowledge. I'd often write once and reuse, not adjusting tone — which made client-facing docs feel cold and internal docs feel over-explained when shared.

Generic grammar checkers catch spelling and obvious errors. They don't catch any of those three. I needed something that understood the difference between "correct" and "clear," and that knew which audience I was writing for.

What I Tried First (and Why It Wasn't Enough)

My first attempt was a checklist I kept next to my desk: "Is the first sentence clear? Is the key point in the first paragraph? Does this match the audience?" The checklist helped marginally, but I forgot it under deadline pressure and applied it unevenly across documents.

Second attempt was using the spell-checker in my editor for grammar. It catches "their/there" errors. It doesn't tell me that my third paragraph contradicts my first.

Third attempt was a generic "rewrite this for clarity" prompt in regular Gemini. This worked better than the first two but didn't remember my voice or my typical audience. Every session I had to re-explain that I was an IT infrastructure professional who writes for both technical and non-technical readers, and the prompt drifted mid-document.

What I wanted was a dedicated editor that already knew my context — my typical document types, my audience range, my voice preferences — and that I could paste any draft into without re-explaining.

The Personal Writing Editor Gem did exactly that.

The Gem I Use

Here's the core of the instructions I saved into the Gem:

You are my professional writing editor. You understand both technical and general audiences. When I share text to edit:

  • Improve clarity and flow without changing my voice
  • Flag sentences that are technically correct but confusing
  • Tell me if the key point is buried past the first paragraph
  • Calibrate tone to the audience I specify (internal engineers, clients, general public)
  • Suggest cuts where I'm being wordy — don't add words unless necessary
  • Ask which audience before editing if I don't specify

My context: IT infrastructure professional. I write technical documentation (runbooks, change records, postmortems) and external content (blog posts, client communications). My default voice: direct, minimal jargon, prefers shorter sentences.

The "ask which audience before editing if I don't specify" rule turned out to be more useful than I expected. It catches the cases where I'd paste a draft without thinking about who would read it — which is most of the time when I'm rushing. The Gem pauses and asks, which makes me slow down for the two seconds it takes to answer.

Two Real Examples — Before and After

These are based on actual documents I edited. Specific technical content is changed but the structure and tone transformations are real.

Example 1: Internal Runbook → Client Update

Situation. I'd written an internal runbook section about a routing change. The same underlying information needed to go to a client as a status update. I copied the internal text and asked the Gem to adapt it for client audience.

Internal draft (too technical for client):

The routing change was implemented via configuration updates to the edge devices, with verification performed through subsequent traffic analysis. The BGP session re-establishment completed within the maintenance window. No packet loss was observed during the failover period based on the flow telemetry data. The post-change validation confirmed all advertised prefixes were reachable from the monitoring vantage points.

Gem's client-facing version:

The routing change completed successfully during the maintenance window. Service was not interrupted during the failover. We've verified the new routing is working correctly across all locations.

What the editor did. It cut roughly 70% of the words without losing the meaningful content for a client audience. It removed jargon ("BGP session," "advertised prefixes," "flow telemetry"). It led with the outcome the client cared about (success, no interruption). It kept the verification step but stated it in language a non-technical reader could parse.

What I changed. Almost nothing. The client version was usable as-is.

Example 2: Blog Post Draft — Buried Point

Situation. I had written a blog post draft where the conclusion — the actual recommendation I wanted readers to take away — was in the fourth paragraph. The first three were setup. The reader would have to scan most of the article to find the point.

What I asked the Gem:

"Review this draft. The recommendation is buried — flag if the key point is past the first paragraph."

Gem's response:

Structural feedback:

Your actual recommendation appears in paragraph 4. For a reader who only reads the first paragraph — and most online readers don't get further — they'll have read setup but missed the takeaway.

Two options: (1) move the recommendation to the end of paragraph 1, or (2) add a one-sentence summary at the top: "The short version: [recommendation]. Here's why."

I recommend option 2 for this article. The setup is doing work — it provides context the recommendation depends on — so cutting it would weaken the argument. A summary line at the top preserves both.

Line-level edits (sample, 3 of 12):

— Para 2, sentence 2: "relies on" → "depends on" (clearer)

— Para 3, sentence 4: cut — restates point already made in para 2

— Para 5, last sentence: split into two for readability

What the editor got right. It caught the buried-point problem first and addressed it structurally before line edits. The two options it offered weren't arbitrary — option 2 was specifically justified by the structure of the article, which the editor had obviously read. Line edits were concrete and minimal.

What I changed. About 30% — I added the summary line at the top, took most of the line edits, and rewrote one paragraph that the editor flagged as redundant. The structural diagnosis was the most useful part.

Where This Works and Where It Doesn't

After about a year of use, here's an honest assessment.

It works well for:

  • Adapting one document for multiple audiences. Internal-to-client or technical-to-general transformations.
  • Cutting wordy drafts. When I've over-explained and need help tightening.
  • Catching buried points. The structural feedback is more useful than line-level edits for documents where the order is the problem.
  • Quick review of routine writing. Status updates, change records, short client emails.

It doesn't work well for:

  • Highly creative or stylistic writing. If the goal is a specific voice or aesthetic, the editor's instinct to "improve clarity" can flatten distinctive phrasing.
  • Documents where I haven't yet decided what I want to say. The editor optimizes whatever's on the page. If the underlying thinking is unclear, the editor produces a clearer version of unclear thinking.
  • Substantive technical review. The editor doesn't know whether my technical content is correct — only whether the writing is clear. Technical accuracy still needs a subject-matter review.
  • Documents with strong institutional voice requirements. If the legal team or marketing team has approved specific phrasings, the editor will suggest changing them.

How to Set This Up

Five-minute setup:

  1. Create the Gem and paste the instructions from the previous section.
  2. Edit the "My context" paragraph to match your writing — what you write, who reads it, your default voice.
  3. Test it with three drafts: one that's working, one that needs editing, one where you're not sure what's wrong. See how the Gem handles each.
  4. Adjust the instructions based on what you see. If the editor keeps suggesting changes you don't want, add a rule to the Gem that addresses it.
  5. Use it for at least two weeks before judging. The first few drafts will feel awkward because you're adjusting to having an editor on call. By the third week, it becomes routine.

The most common mistake is over-editing the Gem's instructions upfront. Start with the template above and refine as you use it. The Gem that evolves with your actual writing practice is more useful than the one you spent an hour perfecting before using.

A Note on Voice

An editor that flattens your voice is worse than no editor at all. The Personal Writing Editor Gem works because it has the explicit "improve clarity without changing my voice" rule, and because I've refined the instructions over time to keep its suggestions within my own style. If you find the editor is making your writing sound generic, the fix is usually in the instructions — not in abandoning the tool.

For me, the Gem has cut my editing time on most documents by half or more, and the structural feedback has changed how I draft — I now write with the first-paragraph rule in mind from the start, which means less revision later.

Related Reading

Sources

— Justin

📅 First published: 2026-05-05 | 🔄 Last updated: 2026-06-21