How to build a writing skill that sounds like you, and set it up so you don’t have to remind it every time.
You’ve never said “unlock your full potential” to a customer.
But somehow it’s in your latest email. Along with “seamless solutions,” several em dashes, and a closing paragraph that says the same thing as the opening.
You asked AI to save you time. Now you’re editing out its personality so you can put yours back in.
I’d turn those corrections into a reusable writing skill.
Here’s how to build one, and how to make sure it actually gets used.
Start with what you keep deleting
A useful skill needs specific instructions. “Sound human” isn’t specific.
My starting rules would be:
- No em dashes, emojis, or decorative icons.
- Skip corporate phrases such as “leverage,” “unlock,” and “game-changing.”
- Open with the actual problem, observation, or useful idea.
- Don’t repeat “It’s not X. It’s Y.” throughout the draft.
- Don’t force every idea into three perfectly balanced points.
- Replace vague promises with concrete explanations.
- Don’t finish by summarizing a short piece we just read.
- Never invent experiences, quotes, numbers, or customer results.
These aren’t universal laws of good writing. An em dash doesn’t prove AI wrote something. The point is to remove habits you don’t want representing you.
Give it examples of your voice
Pick three emails or posts you wrote yourself. Choose ones that sound like you, not ones someone polished beyond recognition.
Remove private information.
Even better, include an AI draft you corrected. The difference between the two shows exactly what you disliked.
Then use this prompt:
Create a reusable writing skill from my rules and samples below.
Include:
- My voice and tone, supported by examples from my writing.
- Words, phrases, punctuation, and repetitive structures to avoid.
- Before-and-after examples showing my preferred wording.
- Instructions to preserve facts and ask for missing information.
- A final editing checklist to apply before returning a draft.
Don’t invent experiences or add mistakes to imitate human writing. Don’t erase my opinions or specific details in the name of polishing.
Return the complete instructions ready to save as a skill.
My rules: [paste]
My writing samples: [paste]
My edits: [paste, if available]
Read what it produces. If the guide describes someone you wouldn’t recognize, correct it before saving.
Make it available next time
This is the step that makes the exercise worthwhile.
If your tool supports reusable skills: create a skill named My Writing Voice, save the instructions and examples, and describe when it should activate: drafting or editing your emails, posts, articles, and proposals.
Where the tool supports standing instructions, add:
For my outward-facing writing, use the My Writing Voice skill before drafting and apply its editing checklist before returning the result. If the skill is unavailable, tell me.
If your tool doesn’t support skills: create a dedicated writing project. Put the rules in its saved instructions and add your examples as reference files. Start your writing tasks inside that project.
A project’s instructions may not apply outside it. And automatic skill selection isn’t a guarantee. The setup needs a test.
Test it in a fresh conversation
Ask for a customer email without repeating your voice rules.
Does it follow them? Does it preserve your meaning? Does it avoid the phrases you banned?
Ask which saved instructions it used, but check the draft yourself. Its claim isn’t proof.
If it misses the skill, explicitly select or invoke it and adjust the activation instructions. Save useful corrections back into the skill instead of leaving them buried in a chat.
Then consider the company version
Your team could have shared writing skills for proposals, follow-ups, and onboarding, supported by approved product facts and examples of good customer communication.
That gives a new employee a starting point for both what the company can say and how it should sound. A person still reviews what goes out.
Start with three emails and one message you keep rewriting. If that same problem runs across your team, bring me those examples. We can use them to design the shared version.