A 25-minute setup beats every prompt-engineering trick.
Claude can write in your voice. Most people don't know this and end up with output that sounds like every other AI on the internet.
Twenty-five minutes of setup gets you a tool that drafts emails, posts, and messages that sound like you wrote them. This guide shows the setup, end to end.
The default sounds like nobody.
When Claude doesn't know your voice, it writes the average of every voice it's ever read. That output is fine for generic copy. It's bad for anything that needs to sound like a real person. The boss email. The investor update. The newsletter. The post.
Feeding Claude your voice is the difference between output you have to rewrite from scratch and output you only have to edit.
Three to five samples of your own writing.
You need real samples of your writing. Not the polished, edited, run-through-grammar-tools version. The actual version. Old emails. Slack messages. Newsletter drafts. A LinkedIn post you didn't overthink.
Three is the minimum. Five is better. More than seven is overkill and starts to confuse Claude with conflicting styles.
Pick samples that match the kind of writing you want Claude to do. If you want it writing emails, give it emails. If you want it writing posts, give it posts. Don't mix surfaces.
Build a voice Project.
This works best inside a Project.
Create the Project
Name it something clear. "My voice for emails" or "My voice for posts." One Project per surface.
Add the samples
Drop your three to five writing samples into the Project's knowledge files. Plain text or pasted Google Docs both work. Don't edit the samples for the Project. The whole point is that they're real.
Add the instruction
This is the part most people skip. Without it, Claude reads the samples but doesn't know what to do with them.
Test once
Open a new chat in the Project. Run the test prompt below. If it sounds like you, the setup is right. If it sounds like a chatbot, the samples or the instruction need work.
This project is for drafting writing in my voice. The knowledge files contain examples of how I actually write. When I ask you to draft something, do these things in this order: 1. Read the examples first. 2. Match my sentence length, sentence rhythm, and word choices. 3. Match my tone, including the things I don't do (no buzzwords, no filler openers, no salesy language). 4. Don't make the output more polished than the examples are. 5. If I haven't given you enough context to write in my voice, ask me one short question before drafting. When I send you something to edit, suggest the smallest edits that make it sound more like me.
Paste this into the custom instructions field of a new Project. Adjust the negatives in step 3 to match what you actually avoid.
Write a short email declining a meeting next Tuesday. The reader is a vendor pitching a service I don't need right now. Keep it warm, brief, and don't suggest a future call unless I'd actually take one.
Paste into a new chat in your voice Project.
Add a sample, don't replace them all.
Your voice changes. Your work changes. The samples should change too.
Once a month or so, drop a recent piece of writing into the Project. You don't need to delete the old ones. Five samples is enough range. Newer ones just nudge the average toward where you are now.
Common traps.
- Using polished writing as your samples. Claude will learn the polished version and write that. If your real emails are casual, give it casual emails.
- Mixing surfaces in one Project. Emails and LinkedIn posts have different voices. Use separate Projects.
- Skipping the custom instruction. The samples alone aren't enough. Claude needs to be told what to do with them.
- Asking Claude to write in your voice in a one-off chat outside the Project. The whole point is that the Project remembers. The chat doesn't.
- Accepting the first draft. Tell Claude what's off. "Too formal," "sounds like marketing," "more like the second example." The second draft is almost always better.