This month I gave a lightning talk at Jane’s Product Summit about how I use AI to write for me without it sounding like AI. Seven minutes goes by pretty fast, so I wanted to write up the longer version here, with a bit more of the how.
Here’s the short version: I had Claude build a style guide out of my own writing, and then I added a loop so every correction I make gets written down as a rule. It reads those rules every time it writes for me. A couple of months in, the drafts sound a lot more like me, and they keep getting closer.
Same Doc, Twice
Here’s a paragraph from a platform vision doc I wrote back in September, the way AI first drafted it for me:
Teams compose offerings, they don’t extend them. Custom things are how platforms die, because five ways to run a worker means owning all five forever. A gap in the catalogue gets handled as a catalogue decision.
And here’s the version I actually sent:
Offerings are composed, and they’re open to contribution. Uncontrolled divergence is how platforms die, because five private workarounds become five ways to run a worker, and then somebody owns all five forever. So a gap in the catalogue gets raised as a catalogue decision, in the open, with the team that hit it.
Same point. The first one is fine, honestly. It’s competent, and if it’s a summary I’m reading myself I don’t really care. But it locks teams out, it blames the team for the problem, and “gets handled” leaves you wondering handled by who? When something goes out under my name, people can tell it wasn’t me, and so can I.
The Setup
So I built a voice guide out of my own examples of writing. I had Claude sift through Slack messages, emails, and Notion docs that I wrote, and produce a Claude skill that gets read every time it’s writing with me.
That gets you most of the way on day one. What makes it even better is the loop that learns and follows your tone as it changes over time.
The Loop
It’s four steps, every draft:
- Draft. Claude writes using the guide.
- Correct. I fix what sounds off, or edit the draft myself and have Claude compare it against what it wrote.
- Capture. Every voice correction gets written down as a rule in a separate staging file, with the date and the kind of writing it’s for.
- Promote. Once a rule shows up twice, it moves into the main guide.
The kind of writing matters a lot more than I expected. My Slack voice and my Notion doc voice are almost completely different people, so a rule learned from a Slack message is often wrong for a design doc.
The important bit is deciding which corrections count. “This is too formal” or “I’d never say that” counts. “Change three weeks to four” is just a fact fix, so it doesn’t.
There’s one more rule that ended up being the most important one: if a new correction fights with the guide, Claude has to stop and ask me, instead of quietly deciding how I write.
Here’s roughly what an entry in the staging file looks like:
### 2026-09-17 - Use plain working words, never analyst or academic register
- **Register:** all
- **Signal:** "words like 'corpora' and 'descending fidelity' do not meet my tone"
- **Rule:** Write like someone explaining it at a desk. When a plain word
exists, use it: corpora -> sources, in descending fidelity -> best first.
- **Confirmations:** 1A Few Real Rules
A few of my favourites, straight out of the file:
- Use plain working words. I got a draft back that said “corpora” and “in descending fidelity”. I have never said “corpora” out loud in my life. Those became “sources” and “best first”.
- State boundaries as an offer of help. Claude wrote “if it isn’t your service code, it isn’t your problem.” Accurate, kinda cold. Now it says “if it isn’t your service code, we’re here to help fix it.”
- Avoid the “it’s not X, it’s Y” cadence. I think everyone has read about a hundred of those this year.
The One That Taught Me the Most
The rule that taught me the most was about the em dash.
I’ve always used em dashes as a vocal pause, the spot where I’d take a breath if I were saying it out loud. The original guide picked up on that and called it, and I’m quoting here, “his signature mark”. Which, fair.
Then the drafts started coming back reading like AI, because that’s how most people see em dashes now, rightfully so. So I corrected it:
I’m still finding a lot of em-dashes which I do use, but I would prefer to leverage commas more heavily in those spaces to read less like AI
The loop noticed that correction contradicted the guide, and it asked me before changing anything. I said yes, and the rule got promoted: commas for the pause, one or two em dashes a doc at most.
The guide was accurate to how I used to write. The loop moved it to how I want to come across today. That’s the whole design in one example.
Seventeen rules in the first two months or so, all promoted into the guide. Each one is a correction I never have to make again.
Where I Actually Use It
Day to day, this shows up in Notion docs, Slack announcements, PR descriptions, and the rare email. Regular Slack messages and replies I still write myself. Sometimes I’ll ask AI to sanity check them, but it doesn’t write them for me.
It also doesn’t do my thinking. The guide handles how something sounds. What the doc says, what gets cut, and any judgement call in it are still mine, and every draft gets read and edited by me. The corrections are kind of the proof of that. The loop just stops me from making the same correction twice. A ghost writer that erases your voice defeats the whole point.
Build Your Own
If you want to try this yourself:
- Gather writing from before you used AI. This step matters most. Anything that’s been through AI teaches the guide the AI’s voice instead of yours, and since that’s getting harder to avoid, go further back than feels necessary. Old Slack messages and docs are the safest bet. You can have Claude help dig them up, that’s what I did.
- Have the AI build a style guide from it, split by where you write (like Slack, docs, and email), with real quotes as evidence.
- Add a second file just for corrections.
- Wire up the loop. Capture corrections as rules, promote after two similar corrections, and ask before contradicting the guide.
Here’s the starter prompt I put together for the talk. Paste it into Claude (or whatever you use) and answer its questions. It walks you through gathering your writing, building the guide, checking it with you, and setting up the loop.
I want you to build a personal voice guide from my own writing, so anything you draft for me sounds like me. Then I want that guide to keep improving every time I correct one of your drafts.
Work through the steps below in order. Where a step says to stop, stop and wait for me.
## Step 1: Ask me first
Before gathering anything, ask me:
1. My name, my role, and who usually reads what I write.
2. Where I write (for example Slack, docs, email, PR descriptions, presentations) and roughly how much of each.
3. When I started using AI to help with my writing. This is the cutoff date for Step 2.
4. Whether you can pull my writing through connected tools, or whether I'll paste samples in.
5. Anything I already know about how I write, or habits I want to stop.
## Step 2: Gather writing I wrote myself
The guide is only as good as the samples, so collect writing I wrote without AI help.
- Prefer writing from before my cutoff date, and go back as far as you can.
- After the cutoff, only include pieces I confirm I wrote myself. Quick chat messages are usually safe.
- Only include writing I authored. Skip anything written by someone else, forwarded, quoted, or pasted in from another source.
- Skip anything containing patient, customer, or other sensitive personal information, and never quote it in the guide.
- Aim for range: lots of short messages, at least 5 longer docs, and at least 20 emails, or whatever mix matches where I actually write.
Then screen what you gathered for signs it went through AI: heavy em dash use, "it's not X, it's Y" phrasing, tidy lists of three, polished summary paragraphs, and words I don't normally use. Set those pieces aside.
Report back with how many samples you have per medium, the date range they cover, and how many you set aside and why. Stop and wait for me to confirm before Step 3.
## Step 3: Build the voice guide
Analyze the samples and write the guide as a file called voice-guide.md. Back up every trait with a real quote from my writing, so I can check your work.
Include:
1. A register selector. Work out which distinct voices I use (most people have at least a quick-chat voice, a document voice and an email voice) and when to use each. Registers should not blend.
2. Traits that hold everywhere: how I hedge, what I'm confident about, humour, warmth, punctuation habits, and favourite words and phrases.
3. Rules for each register: rhythm and sentence length, structure and formatting, openers and closers, and how I give feedback, ask for things, agree, disagree and deliver bad news.
4. A short checklist per register, to run before handing any draft back.
5. Anti-patterns: things that would make a draft obviously not me.
6. A sources line: what the guide was built from and the date range.
This guide will mostly be read by AI, so be precise and complete, and spell out edge cases.
## Step 4: Check it with me
Before finalizing, show me:
- The five most distinctive traits you found, each with a quote.
- Any habits from my older writing that might read as AI-written today (heavy em dashes are the common one). Ask whether I want to keep them or have the guide move away from them.
- Anything you weren't sure about.
Update the guide based on my answers.
## Step 5: Set up the improvement loop
Create a second file called learned-refinements.md. It's a staging area for corrections, kept separate from the guide. Use this entry format:
### YYYY-MM-DD: <the rule, written as a rule>
- Register: which voice it applies to, or all
- Signal: what I said or changed
- Rule: what to do differently next time
- Confirmations: 1
Then write a third file, how-to-use.md, with instructions for any AI drafting on my behalf. It should say:
- Read both files before writing anything, even a one-line reply. When the refinements and the guide conflict, the refinements win, since they're newer.
- Pick the register before drafting.
- Watch for tone corrections while working with me. A correction counts when it's about voice: "too formal", "I wouldn't say that", me rewriting your phrasing, or me praising a specific phrasing. Fact fixes like "change 3 weeks to 4" don't count.
- When a correction comes up, add it to the refinements file in the same session. Write it as a rule, with today's date and the register, and tell me in one line what you captured. If an entry already covers it, sharpen that entry instead of adding a near-duplicate.
- When a rule has been confirmed twice, in two separate sessions or by me saying so, move it into the right section of the voice guide and mark the entry [promoted YYYY-MM-DD].
- If a new rule contradicts the guide, tell me and ask before changing the guide. Never silently rewrite or delete anything in it.
- You handle the voice. I decide what a piece says, what gets cut, and any judgement or assessment in it, and I read and edit every draft before it goes anywhere.
## Step 6: Test drive
Ask me for a topic, then write one short sample in each register and ask me to correct them. Capture my corrections as the first entries in the refinements file.
When we're done, tell me where to put the three files in the tool I'm using so they get read every time I ask for writing. If the tool can't edit files itself, tell me how to add new refinements by hand.Then correct your first ten drafts very closely, on purpose, even the small stuff. And a heads up, your old writing might have habits that read as AI now, like my em dashes. Better to make that call early, before the guide locks them in.
Wrapping Up
If you remember one thing from this, it’s that every correction you make is worth keeping, so write it down somewhere the AI will read it next time.
I’d love to hear how it goes if you build one of these, especially what your first few rules end up being!