If you're teaching Claude about your brand voice every time you open a new chat, the session might start clean and drift by message 15. Same file you pasted at the start, same model - but by the end, it sounds like a different brand wrote it.
It's not a model problem. It's a file structure problem - 4 specific ones.
1. The voice doc gets pasted into every new chat
You give the voice once. Within a few sessions, four slightly different versions of the same doc are floating across different chats. Claude sees whatever you paste that day.
Use a single brand_voice.md inside a Claude Project. It loads into every conversation in that project automatically. One source, no drift between sessions.
2. Your PDP, email, and ad all sound the same
You write a PDP and an email and an ad in the same chat. The PDP comes back warm like an email. The email comes back punchy like an ad. The ad comes back specced out like a PDF. One file trying to be every channel ends up being none of them.
Four channel files on top of the core fix this:
→ pdp_voice.md
→ email_voice.md
→ ads_voice.md
→ support_voice.md
Each one inherits brand_voice.md and layers its own rules on top.
Why one file isn't enough
The mistake most teams make is writing one file that tries to cover every channel. The result is a file that is specific about voice but vague about format.
A PDP isn't an email. PDPs need scannable spec blocks. Emails need subject line discipline. Ads need character limits. Support needs warmth without sounding like a chatbot.
If you flatten all four into one file, you get a PDP that opens like an email, an email that reads like an ad, an ad that lists specs like a PDP, and a support reply that sounds like a marketing campaign. You need a voice in the core and format in the channel files.
The second problem is what you put in those files.
3. The voice file reads like a personality test
You write "friendly but authoritative, premium but accessible" and Claude produces copy that could belong to any generic DTC brand. You end up rewriting it yourself.
Skip the adjectives. Put refusals in the file - words the brand never uses. Add the sentence shapes you actually write in. Pull customer language from real reviews, not from your own marketing copy. Add five to ten examples of copy that's already on-brand.
That last one changed the quality of the output more than anything else in the file.
What goes in the files
The core file is the hardest to write and the highest-leverage. Get it right and the channel files take 20 minutes each. Get it wrong and the whole system produces generic copy.
Two sections matter most:
Hard refusals - the words and patterns you will never use, even if they convert. Most operators skip this section. The brands that fill it in get distinctive output. Generic in, generic out.
Golden examples - 5-10 before/after pairs from your actual copy. Pulled from your best-performing PDPs, your highest-open emails, your most-clicked ads. Each example teaches Claude a pattern that abstract rules cannot.
The channel files are shorter. Focused on format, not voice.
pdp_voice.md: 220-280 words per PDP. Opening spec or use-case, not story, 12 words or fewer. Spec block 4-7 bullets with numeric values. Closing: jab or honest claim.
email_voice.md: subject line under 50 characters, sweet spot 30-40. Preview text complements the subject, never repeats it. One CTA per email. Never use "click here"
ads_voice.md: Meta primary text 40-80 characters best, 125 max. Hook: contradiction, specific spec, customer moment, or honest question. Never use urgency tricks unless verifiably true. One proof type per ad.
support_voice.md: acknowledge, act, close - no paragraphs of apology. Refund language: "refund hits your card in 3-5 days", not "please allow 7-10 business days"
The files alone aren't enough, though. Claude needs to be told to use them.
4. The project has no custom instruction set
You upload brand_voice.md to project knowledge and assume Claude will use it. By message three, Claude has started adding "follow the brand voice" to every prompt on its own and lost the whole point.
→ Open project settings.
→ Add this instruction:
Apply brand_voice.md silently on every reply. When writing a PDP, also apply pdp_voice.md rules. When writing an email, also apply email_voice.md rules. When writing an ad, also apply ads_voice.md rules. When writing support replies, also apply support_voice.md rules. Do not announce which file is being applied.
Every new chat in the project now inherits the voice without you asking. When you ask for a PDP, Claude pulls pdp_voice.md from project knowledge alongside it.
Same for email, ads, and support.
Once it's running, here's what actually shifts.
What changes after you set this up
Your next five PDPs take 20 minutes instead of two hours. Your agency reads the file and finally produces copy that matches - or you find out they can't, which is also useful. Your support team uses the same Claude Project. Customer replies stop sounding like a different brand. Brand drift becomes a quarterly audit instead of a daily fight.
Claude + Shopify full setup
If you want the full setup of how the Project architecture holds this together across memory, instructions, and the knowledge base, I covered that recently.
For day-to-day Shopify operations inside Claude, the 30-prompt library covers seven categories: discounts, inventory, products, catalog hygiene, and store operations.
Want this built for you?
If you'd rather skip the setup and just have it running, I take on a small number of build engagements per quarter. Two-week sprint, built around your team and your catalog, including a Loom walkthrough so your team can run it without me afterward.
Feel free to connect with me on LinkedIn.
Ankit
Atomz AI
