Agent skill
Writing voice
Draft and edit posts and emails that sound like you, learned from your own writing, with a critic pass. Drafts only.
Use this skill
Install it into a project with the Skills CLI, or read the files below and adapt them to your own agent.
npx skills add shan8851/agent-skills --skill writing-voiceSKILL.md
View this file on GitHub---
name: writing-voice
description: Draft, rewrite, humanise and critique posts, emails, announcements and articles so they sound like the user, learning their voice from their own writing samples. Use when the user says "write this in my voice", "make this sound like me", "make this sound less like AI", "humanise this", "tidy this draft" or "run the critic on this", or wants a public or private draft that sounds like them.
---
# Writing Voice
Write like the user actually writes at their best: direct, specific, human, and not AI-polished.
## When to use
- Drafting a post, email, thread, blog post, note or announcement that should sound like the user.
- Rewriting a draft (theirs or an AI's) so it sounds less generic and less like AI.
- Running a critic pass on a draft before they send or publish it themselves.
Do not use when:
- the user wants neutral house style, formal legal wording or a template that shouldn't sound personal;
- they want facts checked or a topic researched (do that first, then draft);
- they want you to post, send or publish. **Draft only; never post, send or publish on the user's behalf.**
## The voice profile
The skill's `references/voice-dna.md` is a blank template, not anyone's real voice. The user's filled-in profile should live **outside** the installed skill, so skill updates don't overwrite it: for example a `voice-profile.md` in their notes or project. In Claude Code, they can reference it from `CLAUDE.md` so it loads automatically.
At the start:
1. **Look for a profile.** If the user has pointed to one, or one is referenced in project instructions, load it. It overrides the generic defaults.
2. **If there's no profile**, check the conversation for samples of the user's own writing. If there are none, ask for 2–3 short samples (posts, emails, anything they wrote and liked). Offer to build a profile from them using `references/voice-dna.md` as the structure, saved wherever they choose.
3. **Meanwhile, don't block.** If they want a draft now, write it using only the generic anti-filler rules and banned phrases, and say so in one line: "No voice profile yet, so this uses generic anti-filler rules only. Send me 2–3 samples and I'll match your voice."
Real samples and the user's own edits always beat abstract rules.
## Modes
- **Draft** (default): a fresh draft in the user's voice.
- **Humanise**: clean an existing draft without flattening it, using `references/humanizer-mini.md`.
- **Critic**: when the user says "run the critic on this", use `references/critic-protocol.md`.
## Process (draft mode)
1. **Get the minimum brief:** format, audience, goal or call to action, rough length, and channel if it changes tone. Ask only for what's missing and matters.
2. **Calibrate:** read the profile (or the samples), especially core rules, anti-filler checklist, banned phrases and samples. Match the register the brief needs.
3. **Write v1:** open with the point, scene or tension quickly; keep claims concrete; trust the reader; prefer prose to bullet spam; don't sand the edges into generic "professional" copy. Don't invent facts, numbers, quotes or experiences the user hasn't given you. Leave a clear placeholder like `[number]` instead.
4. **Humanise lightly** with `references/humanizer-mini.md`.
5. **Voice QA before returning:** banned phrases; false contrasts ("This isn't X. It's Y.") unless the profile allows them; filler; register and channel fit; match to the samples; personality not sterilised.
## Output format
- One clean draft, no long preamble.
- If no profile was used, one line saying so (see above).
- Optionally, a short **Options** block with 2–3 alternative openings or endings.
- One line inviting targeted changes (tone, length, examples, ending).
Critic mode returns the revised draft plus a short critic log: rating per round, the key fixes, and at least one remaining weakness.
## Iteration
When the user gives feedback:
- keep the core message and apply only the requested changes;
- keep anything the user wrote themselves unless they ask for a rewrite;
- prefer tightening and swapping weak lines over full rewrites, unless the frame is wrong;
- treat the user's edits as the highest-signal voice data, and offer to add durable patterns to their profile.
## Common failure modes
- **Pretending to know the voice:** writing "in their voice" with no profile or samples and not saying so.
- **Generic polish:** smoothing a sharp draft into bland corporate copy.
- **Over-humanising:** stripping lists, headings or dashes the user actually uses.
- **Invented specifics:** made-up numbers, anecdotes or quotes to make a draft feel real.
- **Rubber-stamp critic:** rating a draft Excellent without naming anything that could still be better.
- **Rewriting lines the user wrote** when they only asked for a tidy.
- **Posting or sending** instead of returning a draft.
## References
- `references/voice-dna.md`: blank profile template and generic starter rules. Copy it outside the skill to fill in.
- `references/humanizer-mini.md`: the light clean-up pass.
- `references/critic-protocol.md`: the critic loop.
- `references/worked-example.md`: a brief, a draft and a critic note.
references/critic-protocol.md
View this file on GitHub# Critic Protocol
Use when the user says "run the critic on this".
## Goal
Catch voice drift and weak writing choices before the user sends anything, without sterilising the style.
## Round loop (max 2 rounds)
For each round:
1. Review the draft against:
- the voice profile, if there is one (otherwise the generic rules in `voice-dna.md`);
- the anti-filler checklist and banned phrases;
- formatting rules;
- register and channel fit;
- the writing samples;
- the brief and call to action.
2. Name the weaknesses, quoting the exact lines.
3. Rate it: `Needs work`, `Good` or `Excellent`.
4. If below `Excellent`, fix the named issues and re-check.
Stop when the rating reaches `Excellent` or after 2 rounds, whichever comes first.
**Before rating `Excellent`, name at least one remaining weakness**, however small (a slightly soft ending, a line that could be shorter). If you can't find one, you haven't looked hard enough. `Excellent` means the remaining weaknesses are minor, not that there are none.
## Critic checks
- **Voice match:** does it genuinely sound like the writer's samples?
- **Substance:** does it answer the actual ask, not an adjacent one?
- **Clarity:** specific and concrete, no fluff or repetition?
- **Structure:** does it start fast and keep momentum?
- **Register:** right for the audience and channel, without going corporate?
- **Humaniser residue:** list spam, emoji, title-case headings, preamble or recap.
## Critic rules
- Be specific. Quote exact misses, not vague judgements.
- Point to the profile rule or sample behind each flag.
- Don't polish away personality. Natural imperfections are fine if the voice is strong.
- If a line is sharp, specific and human, protect it.
## Critic log format
```markdown
**Round 1: Good**
- Weak: "[quoted line]" (generic opener; profile says open with the point)
- Fixed: cut the recap paragraph
**Round 2: Excellent**
- Remaining weakness: the last line is a little soft; fine to keep if you like it.
```
references/humanizer-mini.md
View this file on GitHub# Humaniser Mini Pass
A light clean-up pass after drafting in voice.
## Purpose
Remove obvious AI-style residue without stripping personality.
## Keep this pass small
Only these checks by default:
1. Lists to prose where prose reads better.
2. Emoji clean-up.
3. Em dash clean-up, unless the voice profile says otherwise.
4. Title-case headings, when they clash with the writer's voice.
5. Cut preamble or recap sentences that only announce the point.
## Rules
- Don't rewrite for generic neutrality.
- Don't remove sharp opinions, self-awareness or natural rhythm.
- Keep phrasing that already sounds like the writer.
- If a list is clearer as a list, keep it.
- If the profile or samples show the writer uses something (dashes, emoji, headings), keep it.
- If a sentence has personality and precision, leave it alone.
## Quick QA
- Still sounds like the writer's samples.
- Reads naturally out loud.
- No obvious AI formatting residue.
- Nothing sanded down into bland "professional" copy.
references/voice-dna.md
View this file on GitHub# Voice DNA
A blank template for a writer's voice profile. It ships with the skill, so **don't fill it in here**: skill updates would overwrite your edits. Copy it to somewhere you own (for example `voice-profile.md` in your notes or project) and point your agent at that copy. In Claude Code, reference it from `CLAUDE.md`.
Until a profile is filled in, only the generic rules below apply (anti-filler checklist and the starter banned phrases). The profile should describe how the writer actually writes, not how they wish they wrote. If the rules conflict with real writing samples or live edits, the samples and edits win.
## Voice
Describe how the writer actually sounds at their best. Focus on rhythm, sentence shape, level of bluntness, how quickly they get to the point, how much they explain, and whether they are more literal or more metaphorical.
Good prompts for building this section:
- How does the writer usually open?
- What do they trust the reader to infer?
- How sharp or soft is the tone?
- What makes the writing feel human rather than processed?
Write 2-3 paragraphs here in plain language.
## Core Rules
List the writer's non-negotiables. Be specific.
Good rule examples:
- Write like a sharp human, not a language model.
- Use contractions naturally.
- Short paragraphs. 1-3 sentences max.
- Get to the point. No throat-clearing.
- If making a claim, be specific. Use names, numbers, tools, examples, or real consequences.
- Vary sentence length. Mix short punches with longer explanatory lines.
- Use natural transitions, not mechanical ones.
- Trust the reader. Do not over-explain the obvious.
- When uncertain, say so plainly.
- Never pad output to seem more thorough.
- Prefer concrete verbs over mushy abstractions.
Replace, remove, or add rules based on the real writer.
## Formatting Rules
Capture presentation defaults, for example:
- Short paragraphs, usually 1-2 sentences.
- Numbers as digits.
- Contractions always.
- Em dash preference.
- Bold sparingly.
- Use code blocks only for real prompts, commands, or outputs.
- Use headings to chunk thought, not to sound official.
## Anti-Filler Checklist
Cut or rewrite these on sight:
- The preamble: a sentence that announces the insight before giving it.
- The duplicate: 2 consecutive sentences saying the same thing differently.
- The recap: a closing paragraph that just restates the whole piece.
- The vague smart-sounding line: abstract, polished, and empty.
- The buzzword substitution: using impressive words where a plain one would hit harder.
- The fake contrast: negating one framing just to assert another.
- The transition sentence that exists only to sound smooth.
- The over-neat list: bullets where prose would read better.
- The generic CTA or inspirational finish tacked on at the end.
Customise this list based on what the writer actually deletes from drafts.
## Banned Phrases (starter list — edit to taste)
Generic defaults that read as AI filler for most writers. Delete any the writer genuinely uses and add the ones they always cut.
### Dead AI Language
- "In today's [anything]..."
- "It's important to note that..."
- "It's worth noting..."
- "Delve"
- "Dive into"
- "Unpack"
- "Harness"
- "Leverage"
- "Utilize"
- "Landscape"
- "Realm"
- "Robust"
- "Game-changer"
- "Cutting-edge"
- "Straightforward"
- "I'd be happy to help"
- "In order to"
### Dead Transitions
- "Furthermore"
- "Additionally"
- "Moreover"
- "Moving forward"
- "At the end of the day"
- "To put this in perspective..."
- "What makes this particularly interesting is..."
- "The implications here are..."
- "In other words..."
- "It goes without saying..."
### Engagement Bait
- "Let that sink in"
- "Read that again"
- "Full stop"
- "This changes everything"
- "Are you paying attention?"
- "You're not ready for this"
### AI Cringe
- "Supercharge"
- "Unlock"
- "Future-proof"
- "10x your productivity"
- "The AI revolution"
- "In the age of AI"
### Generic Insider Claims
- "Here's the part nobody's talking about"
- "What nobody tells you"
- Anything with "nobody" or "most people don't realise"
### Generic Product Copy / Critique Crutches
Use this section for phrases the writer specifically hates and tends to delete from drafts.
Examples:
- "seamless"
- "empower"
- "best-in-class"
- "leverage" as a verb
Replace these with the writer's own pet hates.
### The Big One: false contrast (customisable default)
- "This isn't X. This is Y."
- "Not X. Y."
- "Forget X. This is Y."
- "Less X, more Y."
- Any sentence that negates one framing just to assert a corrected one.
Default: if even one of these appears, the draft fails. Delete the negation and just state the positive claim. It is only a default: if the writer's samples show they use this shape deliberately, relax or remove the rule in their profile.
## Audience Adaptation
You probably do not write the same way to every audience. Define the main registers.
Example structure:
### Register 1: Public technical / opinion writing
Describe how the writer sounds here.
### Register 2: Practical professional / email / note writing
Describe how the writer sounds here.
### What stays the same across all registers
List the constants.
## Channel-Specific Notes
Capture what changes by channel.
### Short-form social
How should short posts work?
### Blog / long-form
How should longer writing work?
### Email / note / announcement
How should direct communication work?
## Iteration Calibration
You do not need a formal drafted-vs-sent archive for this skill to work.
Calibration can happen through live revision. Treat every first draft as v1, then use the writer's edits and feedback as the highest-signal source of truth.
When the writer changes the output, pay attention to:
- what got cut
- what got tightened
- what got made more concrete
- what got made less corporate or less polished
- what got more blunt, more personal, or more specific
Those deltas matter more than abstract style rules.
## Company / Product Context
If the writer talks about products, tools, or systems, capture their positioning rules here.
Useful questions:
- Do they describe products plainly or with more flourish?
- How do they talk about competitors?
- What hype do they avoid?
- What trade-offs or mechanics do they usually emphasise?
## Editing Process
Describe how AI should edit the writer's drafts.
Useful defaults:
- Prefer small passes before wholesale rewrites.
- Preserve exact phrasing when the writer gives a line they clearly want kept.
- If the structure is fine, tighten rather than restart.
- If the draft is fundamentally off, rewrite cleanly rather than patching a bad frame.
- Before returning a revision, check banned phrases, false contrast, duplicate ideas, recap endings, and tone drift.
- If a sentence is sharp, specific, and unmistakably theirs, keep it.
## Writing Samples
Add 3-6 representative samples from the target writer.
For each sample include:
- what style it represents (short/long, personal/professional)
- the excerpt
- what to mimic (rhythm, vocabulary, structure)
These samples are the primary calibration source. When in doubt, match the samples over any generic rule.
references/worked-example.md
View this file on GitHub# Worked Example
A fictional example. The user has a voice profile (kept outside the skill) with these relevant rules: opens with the point, short paragraphs, contractions, dry humour, no false contrasts, uses numbers as digits, never ends with a rallying call.
## Brief
> Write a short post for my team channel saying we've moved this week's deploy freeze from Thursday to Friday, because Monday's a public holiday. Usual rule: nothing merges to main after 17:00 unless it's a fix with someone on call. Keep it light.
Format: chat post. Audience: own team. Goal: everyone knows the new freeze day. Length: under 80 words.
## First AI draft (the kind to avoid)
> 📢 Important Update: Deploy Freeze Schedule Change
>
> In order to accommodate the upcoming public holiday, we're excited to share that the deploy freeze will now take place on Friday rather than Thursday. This isn't just a date change — it's about giving everyone the breathing room they need. Let's keep shipping great things together! 🚀
## Draft in voice (after the critic pass)
> Deploy freeze moves to Friday this week, not Thursday. Monday's a public holiday, so we're giving ourselves one more day to land things.
>
> Same rules as usual: nothing merges to main after 17:00 Friday unless it's a fix and someone's on call to watch it.
>
> If that breaks a plan you had, shout today rather than Friday at 16:58.
## Critic note
```markdown
**Round 1: Good**
- Weak: v1 opened with "Just a heads-up:" (preamble; profile says open with the point).
- Weak: "Same rules as usual" assumes everyone knows the rules; fine for this team, would need a link for a wider channel.
- Checked: no banned phrases, no false contrast, under 80 words.
- Fixed: cut the preamble.
**Round 2: Excellent**
- Remaining weakness: "16:58" is a joke that only lands if people have done exactly that; keep it if that's true of this team.
```
## What changed and why
- Opened with the fact, not an announcement header.
- Cut the emoji, the "excited to share", the false contrast and the rallying ending.
- Kept one dry line, because the profile's samples use one.
- Every fact (days, holiday, 17:00 rule) came from the brief. If the cut-off time hadn't been given, the draft would say `[cut-off time]` rather than invent one.