Keep AI marketing content on brand with an open-source voice file

Where the register slips first

The first asset usually sounds right. Someone wrote the brief with the founder in the room. An earlier piece was open in another tab, so the draft had a model to imitate. By the third asset the model is imitating itself. Nothing carries between sessions except what is in the repo. Whatever the brief leaves unsaid gets filled with the model's default register: longer sentences, a friendly opener, the same three adjectives in the same order. Nobody decided any of it.

Two changes do the same damage faster. A second author joins and re-briefs the agent in her own words. The register moves with her, and the first author's ear leaves with her. Or the team changes model providers, and the default sentences change under a file that never moved. Each draft still looks fine on its own, which is why the drift is hard to argue about in a review. It shows a month later, when somebody lays four pieces side by side and cannot find the version anyone approved.

The usual fix is a tone paragraph pasted into every prompt. It works for the session it was pasted into. Next week another person starts another session and pastes a slightly different version. The team now has two voices, and no record of which one a person signed off on. The platforms on the comparison page keep those rules in an account you log into. A file in a repo keeps them where the writing happens.

The voice file and the claims file hold different things

A voice file is short, and most of it is a list of things not to do. Kortix calls that file a skill: "A skill is the markdown that encodes how your company does one job" (Read the docs). One job, one file, in a directory the repo already has. One shape a voice file can take:

skills/brand-voice/SKILL.mdRegister- Second person, present tense. A long sentence earns a short one after it.- Never: leverage, circle back, excited to announce, world-class.- Open on the reader's job. The company name belongs in the second paragraph.Claims- A number carries its source and the date it was read.- A superlative needs a measured comparison in the same paragraph.- No source? Write [NO SOURCE] and stop. Do not draft around it.

Kortix ships no file with those lines. Read the Register block as a test a reviewer can run in ten seconds. Sentence length is checkable. The Never list is greppable. The rule about the opening line kills the pattern every model reaches for first. The Claims block is what separates this file from a tone-of-voice deck. It says what the agent does at the moment a claim has no source behind it. The answer has to be blunt: mark the line and stop. An agent told to be careful will still write the sentence and add a hedge. A hedge on an unsourced number is worse than no sentence at all.

The two lists change on different clocks, which is why they belong in separate files in the same directory. Register changes when the brand changes, a few times a year. Claims change when a price moves, a limit moves or a certification lands, and that can be monthly. Keeping the source and the read date beside each claim lets the next person see which lines are still true without asking anyone.

Why the file lives in git and not in a prompt box

A prompt box holds one person's copy of the rules. A file in the repo holds the team's, so a correction is one edit and every later draft inherits it. That is the whole difference between fixing a voice and fixing one document.

The history is the second half of it. git log skills/brand-voice/SKILL.md answers the question a brand lead asks in month three: when did the register change, and who changed it. The answer arrives with the line, so an argument about whether the copy got colder ends with a diff and a name.

The file also sits beside the grant that lets an agent read it. The starter manifest keeps the agents: map for governance, "GOVERNANCE ONLY (connectors/secrets/kortix_permissions/skills/workspace/enabled), plus file, the path of the agent's .md" (the manifest). What the agent does lives in the markdown that map points at. The starter agent file opens You are a **Kortix general knowledge worker** for **{{projectName}}**. and sets mode: primary and permission: allow (the agent file). A marketing voice is a file of the same kind, one directory over, under skills/, which every harness loads.

Because the rules sit in the repo, they survive a move. Clone the project on another machine and the voice file is there, and a team running its own instance already has it (self-hosting).

The review is a diff

Marketing work reaches the repo the way code does: "Marketing work lands as a draft in a change request, so the review is a diff" (Kortix).

A diff changes what a reviewer can do in five minutes. There is no document with thirty comments and no argument about which draft is current. There are a handful of added lines, one removed line and a title, and the approval attaches to text somebody can see. Nothing merges itself: work reaches main through a change request a person approves, unless an admin granted the merge capability. The grant is project.gitops.merge.

The gates answer a different question. Approval gates you set. Off until you set them. Copy still reaches the repo as a change request either way. A team can leave a gate open and still read every sentence before it ships.

A diff also catches the mistakes a read-through misses. The banned word that came back sits on its own line. So does the claim that lost its source, and a price quoted twice with two numbers. They sit next to each other in the change, so the reader sees them without hunting.

What the file cannot fix

Three things stay with people. Taste is the first. A file can ban a word and still miss that the whole argument is dull, and no rule list has taught judgment yet. Strategy is the second: the file cannot tell you which launch to write about, or that the campaign answers a question no buyer asks. A team that would rather buy its review than run it has the hosted shapes on the home page for that.

The third is the claim nobody verified. A file can demand a source on every number. It cannot go and find one. Someone still opens the pricing page, reads the report or calls the analyst. That person is the reason the Claims block earns its lines.

The file ages too. A register written for a product launch reads wrong a year later. A claim list with no owner fills with lines past its date. Name one owner, read the file once a quarter, and it stays useful. Skip that and the team has a very well-organized record of how it used to sound.