Email voice setup
Use this skill when someone wants their AI to draft emails that sound like them, and the drafts it writes today read as AI-written or get rewritten line by line before they go out. Produces a personal email-voice skill built from the person's own sent mail and their own edits: a register map, rules backed by counts and quoted lines, three test drafts, and a routine that keeps it improving. Also use for "write emails in my voice", "make my drafts sound like me", "my AI emails sound like a robot", "build my email style guide", "teach my assistant how I write".
Applies when a person's AI-drafted emails need heavy editing before they send them. Produces a voice skill the person owns, built from evidence in their own outbox rather than adjectives about their style.
The play
- Ask permission and set the scope. Agree which mailbox, which date range, and that everything read stays in the user's own files. Confirm the user's address so only mail they wrote gets counted.
- Pull the sample: 30 to 40 substantive sent emails from the last one to two months, spread across the kinds of people they write to. What to skip and how to spread it is in references/measurement-checklist.md.
- Collect the rewrites: any AI draft the user edited before sending, with both versions. Diff each one with references/rewrite-diff-worksheet.md. What they cut is the strongest signal in the whole build.
- Count before describing. Run the measurement checklist across the sample and write every finding as a number. "Warm" is not a finding. "One to three exclamation points in 37 of 40 emails" is.
- Reconcile the two sources. The sent mail wins on how often something happens. A rewrite wins for the kind of email it came from. Scope every rule to the register it came from, or one client email ends up setting rules for every vendor note.
- Interview for what the mail cannot show. Ask about ten questions from references/interview-questions.md, three or four at a time, and play back what you heard before moving on.
- Build the register map: one row per kind of recipient, with median length, warmth, greeting, closer and exclamation range. Most people have five to eight. Record the real median length, not the one the user describes.
- Write the skill from references/voice-skill-template.md and save it in the user's own skills folder. Every pattern carries its count and one quoted line from their mail.
- Test it on real mail. Pick three emails the user owes, each in a different register. Draft them with the new skill loaded, have the user mark them up, and fold each fix back in. Stop when the edits are small.
- Set up the loop. Every future rewrite gets diffed and becomes a pattern, not just a log line. Re-sweep the sent mail once a quarter.
Branches:
- Under 20 usable sent emails (new role, new mailbox): build from the rewrites and the interview, mark every rule provisional, and re-sweep at 30.
- Someone else writes part of their mail (an assistant, a shared inbox): exclude it, and ask the user which threads are theirs.
- They write in two languages: one register map per language. Habits rarely carry across.
What good looks like
- First thing I check that most people skip: the length distribution. People describe their emails as longer and more careful than they are. A fifth are often under 50 words, so a skill that defaults to the 300-word email writes the top tenth of their mail.
- The mediocre version: a list of adjectives ("friendly, direct, professional") written from the user's self-description, plus rules from one rewrite applied to every email. It produces drafts that sound like a nicer AI.
- I know it is right when the user sends a test draft with only small edits, and every rule in the skill can point to a count or a line they actually wrote.
- Red flag: a draft more polished than their real mail. Typos, run-on sentences and asides are part of the voice. Smoothing them out is how a draft starts reading as AI-written.
Rules
- MUST ask before reading any mailbox, and keep the sample and the finished skill in the user's own files.
- MUST count only mail the user wrote themselves.
- MUST back every rule with a count or a quoted line, and name the register it applies to.
- MUST write into the finished skill that it creates drafts only and never sends.
- MUST write into the finished skill that a reply stays in its original thread.
- MUST write into the finished skill that it never inserts a link or claims an attachment it has not verified, and leaves a visible placeholder instead.
- NEVER describe the voice from the user's self-description alone.
- NEVER polish out the user's real habits.
- NEVER keep other people's private details in the finished skill beyond what an example needs. Strip names before the skill is shared with anyone.
references/interview-questions.md
Interview questions
Open this at step 6, after the counting. Ask three or four at a time. After each group, play back what you heard in a few lines and let the user correct it. People correct a paraphrase far more readily than they volunteer detail.
Skip any question the sent mail already answered. Ask it as a confirmation instead: "Your mail shows X. Is that right?"
Who and how
- Who do you write to most in a normal week? Name the kinds of people, not individuals.
- Which of those need a different tone from you? What changes?
- Is there anyone you write to more formally than your mail shows, or less?
- What does a good reply from you do for the other person? Listening for: speed, clarity, options, warmth.
What the mail cannot show
- Which links do you send people to book time, and which one goes to whom? Paste them. These become the only links the skill may use.
- Do you put prices in email, or only on calls? How do you round them?
- Are there words or phrases you would never send? Anything an AI draft wrote that made you wince?
- When someone cancels, apologises or goes quiet, what do you do?
- When you say no to something, how do you say it?
- What do you want people to be able to do with your email afterwards? Listening for: forward it internally, act without a call, reply in one line.
About the drafts
- Think of the last AI draft you rewrote. What was wrong with it?
- What would make you send a draft without touching it?
- Is there anything rough about how you write that you want kept? Typos, long sentences, asides.
Close
- What else should a person writing as you know that we have not covered?
Repeat the close until the answer is nothing.
Where the answers go
| Answers | Land in |
|---|---|
| 1 to 4 | the register map |
| 5 | the verified-links list in the draft mechanics |
| 6, 8, 9 | patterns, each with its register |
| 7, 11 | the avoid list |
| 10, 12 | what good looks like, at the top of the skill |
| 13 | the "keep the rough edges" rule |
references/measurement-checklist.md
Measurement checklist
Open this at steps 2 and 4. It covers which emails go in the sample and what to count across them. Every line here ends as a number in the finished skill.
Building the sample
Take 30 to 40 sent emails from the last one to two months. Older mail drifts: roles, clients and habits change.
Leave out:
- Auto-replies, calendar notices, receipts and anything sent by a tool on the user's behalf.
- Forwards with no added text, and replies that are one word ("Thanks!").
- Emails that are mostly quoted text from someone else.
- Mail written by an assistant or a shared inbox.
Keep the one-line replies that say something ("No problem at all, talk Thursday"). They are the most common email most people send, and leaving them out makes the voice look longer and more formal than it is.
Spread the sample across recipients. Aim for at least three emails in each kind the user sends often:
| Kind of recipient | Examples |
|---|---|
| Client, active work | updates, plans, deliverables, scope changes |
| Prospect | follow-up after a call, proposals, pricing |
| Someone they coach or manage | check-ins, feedback, missed meetings |
| Partner or boss | contract changes, reporting, asks |
| Introductions | ones they make, ones they receive, replies to the person who introduced them |
| Vendor or admin | support requests, billing, platform issues |
| Short replies inside a live thread | scheduling, reactions, quick answers |
Under 20 usable emails: mark every rule provisional and re-sweep when there are 30.
What to count
| Measure | How to record it | What it usually decides |
|---|---|---|
| Length | words per email: median, and the share under 50 and over 300 | the default length per register |
| Greeting | each form with its count, including no greeting at all | the greeting rule, per register |
| Closer line | each line before the sign-off with its count | a short list in order of frequency |
| Sign-off | first name, full name, initials, none, with counts | when the full name appears (often vendor mail only) |
| Exclamation points | per email: zero, one, two to three, more | whether warmth is the default or the exception |
| Dashes | long dashes per email; short dashes in ranges | whether a dash in a draft is a tell |
| Paragraph length | sentences per paragraph, words per sentence | how dense a draft may get |
| Lists | numbered versus bulleted, and what each is used for | often: numbers when each item needs an answer |
| Bold | where it appears | labels, the one real ask, or never |
| Repeated phrases | any phrase in three or more emails, with its count | the phrases the skill should reach for |
| Advice verbs | "I'd", "you should", "I recommend", with counts | how the person gives advice |
| Asks | how a request is worded and whether it carries a softener | the ask pattern |
| Apologies | the first line after someone else apologises or cancels | a reflex the skill should copy exactly |
| Money | whether prices appear in email, how they are rounded | the price rule |
| Typos and run-ons | count them, do not fix them | a reason not to polish |
| Links | which booking or document links appear, and where | the verified-links list, confirmed in the interview |
Writing findings
Write each finding with its count and its scope: "Greeting is 'Hi' or 'Hey' plus a first name in 38 of 40. 'Hey' goes to people they know, 'Hi' to new contacts and groups." Then quote one line from the mail as the example. A finding with no count is an impression, and impressions are what the skill exists to replace.
references/rewrite-diff-worksheet.md
Rewrite diff worksheet
Open this at step 3, and again every time the user edits a draft after the skill is live. A rewrite shows what the person refuses to send, which the sent mail alone cannot show.
Finding the rewrites
- Ask the user for two or three AI drafts they edited, with the version they sent.
- Or search their drafts and sent mail for near-identical pairs written within a day of each other.
- Or skip this step and pick it up at step 9, where the test drafts become the first rewrites.
Diffing one rewrite
Go line by line and sort every change into one of five columns:
| Change | What to record | Example of what it becomes |
|---|---|---|
| Cut | the exact words removed | an avoid-list entry |
| Added | the exact words added | a pattern, or a phrase to reach for |
| Softened | before and after | an ask or a deadline rule |
| Hardened | before and after | where the person is blunter than the AI |
| Moved | what moved and where | an order rule (commitments before asks, price early) |
Then answer three questions about the whole email:
- What kind of recipient was it? The rule belongs to that register until the sent mail shows it holds elsewhere.
- Did the person give a reason, in the edit or out loud? A stated reason outranks an inferred one.
- Did they leave something rough on purpose: a typo, a run-on, a repeated phrase? Record it as kept, so the next draft does not smooth it away.
Turning the diff into the skill
- A change seen once is a pattern for that register, marked with how many times it has been seen.
- A change seen in two different registers becomes a general rule.
- When a rewrite and the sent mail disagree, the sent mail wins on frequency. The rewrite still wins for the exact kind of email it came from.
- Every change goes into the patterns section. A learning-log line alone is not read at draft time, so it does not change the next draft.
What diffs usually turn up
These come up often enough to check for on purpose:
- The AI draft was longer than anything the person sends to that recipient.
- The AI used a word the person never uses ("leverage", "seamless", "unlock").
- The AI wrote an ask as an instruction where the person writes it as an offer.
- The AI committed someone else's time ("my colleague and I will review it").
- The AI apologised at length where the person apologises in three words.
- The AI used a link from the signature or an old thread that was not the right one.
- The AI polished away a habit the person keeps on purpose.
references/voice-skill-template.md
Voice skill template
Open this at step 8. It is the shape of the skill this build produces. Fill every section from the counts, the diffs and the interview. Save it in the user's own skills folder under a name like <their-name>-email.
Frontmatter
---
name: <their-name>-email
description: Load whenever drafting an email for <name>: client updates, follow-ups, introductions, coaching, partner and vendor mail, or any message sent from their inbox. Not for posts or newsletters.
---
Sections, in this order
1. Evidence base
One paragraph: how many sent emails and how many rewrites the skill is built on, the date range, and which source wins when they disagree.
2. Draft mechanics
Copy these in as written. They are the rules that stop a voice skill from doing damage:
- Drafts only, always. Never send, even when asked to "send them". The person sends everything themselves.
- A reply stays in its original thread, created as a reply to the message it answers.
- Editing a reply draft can detach it from its thread in some mail clients. After any edit, check the draft still sits in the thread. If it detached, delete it and recreate it as a reply.
- Never insert a link that is not on the verified-links list. Write
insert link hereinstead. - A link in the email signature is not a booking link unless the person says it is.
- Never say a file is attached unless it is. Write
[attach file here]. A file the agent built and attached in the same step counts as verified. - The verified-links list: each link, what it is for, and who it goes to.
3. Register map
A table with one row per register: who, median length, warmth, greeting, closer, exclamation range. Then the median length across all mail, and the share under 50 words. Pick the register before writing a word.
4. Mechanics of the page
Greeting, paragraph length, lists, bold, sign-off, closer lines in order of frequency, dashes, exclamation points. Each with its count.
5. Patterns
Numbered. Each pattern has:
- a name the person would recognise,
- the register it applies to,
- the count behind it (sent mail) or the rewrite it came from,
- one quoted line from their real mail.
Common pattern areas to check for: how they open after someone apologises, how they ask for things, how they give advice, how they say no, how they show proof, how they handle money, how they make and answer introductions, how they schedule.
6. Avoid list
Words, phrases and moves the person cuts, each with where it was seen. Include "over-polishing" if their real mail has typos and run-ons.
7. Examples
Three to five real emails, one per register, with names and private details changed if the skill will be shared. Under each: why it is a good example.
8. How to grow this skill
- Every rewrite: diff it, add the change to Patterns with its register, then log it.
- Every quarter: re-sweep 30 to 40 sent emails and correct any rule the counts no longer support.
- A rule from one email type stays scoped to that type until the sent mail shows it holds elsewhere.
9. Learning log
A table: date, source (rewrite or sweep), what changed in the skill.