How to build an MD file that teaches your AI to sound like you
AI Literacy · Working With AI
A brand voice file is not a mission statement. It is a set of instructions written for a new team member on their first day, one who has never heard you speak but needs to write like you by lunchtime. Tap each section to open it.
Part one: how to actually build it
Write the first version as a braindump. Don’t wait to have every rule figured out before you start. A rough file you actually use beats a perfect file that stays unfinished on your desktop.
Open a blank document and just write, in plain sentences, how you want things to sound. Turn it into rules afterwards. Trying to write polished instructions from a blank page is what stalls most people before they start.
A plain text or markdown file (.md) is enough. No special software, no template to buy. Markdown just means plain text with light structure: a # for a heading, a – for a bullet point.
Use clear headings for each section, rules, examples, banned words, brand kit, so both you and the AI can scan it quickly. Structure matters more than formatting polish here.
A voice file only works if it’s actually in front of the AI when it writes. Re-pasting it into every new chat gets missed and gets skipped. Look for a project knowledge area, a custom instructions field, or a saved style setting, most AI tools now have one, and load it there once.
If you’re not sure your tool has this, ask it directly: “where can I save instructions that apply to every conversation?” That single step is what turns the file from a document into something the AI actually uses.
Don’t test a voice file with a generic prompt. Run an actual piece of content through it, a LinkedIn post you were about to write anyway, a real email. Compare the result to how you’d naturally say it.
Mark exactly where it drifts: too formal, too long, uses a word you’d never use. Vague dissatisfaction (“this doesn’t sound like me”) isn’t useful feedback. Specific drift is.
When you fix a draft, don’t just fix that one draft. Ask what rule would have prevented the mistake, and add it to the file. This is the step most people skip, and it’s the one that actually improves the file over time.
A file built this way, from real corrections on real work, will always outperform one written in a single sitting from memory.
Set a reminder to reread the whole file every few weeks, not just when something goes wrong. You’ll usually find a rule that’s gone stale, an example that no longer represents you, or a gap you hadn’t noticed because you’d been correcting drafts one at a time instead of looking at the whole picture.
Part two: what goes inside it
“Be authentic” tells your AI nothing it can act on. “No em-dashes” does. The difference is that one is a feeling and the other is a check. Every rule in the file should be something you could hold a finished draft against and get a clear yes or no.
This is the single biggest shift between a voice file that works and one that gets ignored. Vague, adjective-led guidance gets interpreted differently every time. Specific, checkable rules get followed the same way every time.
A description of your writing is a guess dressed up as guidance. Your actual writing is proof. Pull a handful of pieces that genuinely sound like you: a LinkedIn post that landed well, an article, a comment you were proud of.
Selection matters more than volume here. A handful of the right examples outperforms a long, generic brief every time. Choose pieces that vary in purpose too, not five versions of the same type of post, so the file has range to draw on.
Knowing the edges matters as much as knowing the centre. Include a line you rewrote, a draft you rejected outright, a tone you never want again.
Most people only ever show an AI their best work. That leaves it guessing at the boundary. Showing what you’d never say closes that gap directly, instead of hoping the AI infers it from absence.
Voice lives in structure as much as word choice. Sentence length, how you open a paragraph, how you close one, whether you favour short declarative statements or longer builds.
These are the rules that are easiest to skip and most responsible for a draft feeling “almost right, but not quite you.” Naming them explicitly is what closes that gap.
British or American English, stated explicitly, never assumed. Small inconsistencies like this are what make a piece of writing feel machine-assisted, even when everything else is right.
Named and specific, not a vague instruction to “avoid jargon.” List the actual words: corporate filler, landscape, leverage, whatever your own ear catches most often.
A specific banned list is one of the highest-value, lowest-effort additions to any voice file. It’s concrete, it’s easy to update, and it catches the phrases that make writing sound generic faster than almost anything else.
“No clickbait” is vague. “No ‘Nobody Is Talking About X’ titles” is something an AI can actually check for. Naming the exact pattern, by example, works far better than naming the category.
This is worth revisiting over time too, since clickbait patterns shift. What reads as a giveaway today wasn’t necessarily obvious a year ago.
Your voice doesn’t change, but your audience does. A LinkedIn post, a formal report, and a quick client email all need the same underlying voice adapted to a different register.
Giving context on the audience and purpose for each type of content lets that adaptation happen without losing what makes it recognisably you.
If your AI ever touches visual work, the file needs colours, fonts, and logo rules alongside the voice rules. Keep this section separate from the writing rules, so the file still works cleanly for text-only tasks.
A brand kit section turns a writing tool into a genuine extension of how the business looks and sounds, not just how it reads.
The file is never really done. Every time you correct a draft, that correction belongs back in the file, not just in that one edit.
Over time the rules get sharper because they come from real corrections on real work, not a one-off brief written before you’d tested any of it. A voice file built once and never touched again slowly drifts out of date with how you actually write.
The bigger principle across all ten: write it like you’re onboarding a new team member, not drafting a mission statement. Specificity beats description, and selection beats volume, every time.
Building this properly, for one project or across a whole team, is exactly what Aiforya’s AI literacy workshops are built for.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
