I Put Myself in Version Control

Note 002: what happens when the rules for how you work stop living in your head and start living in a repo.

How I work lives in a git repo that an AI loads before it does anything in my name. How it is wired, and the filing rule that keeps it from rotting.

I was deep in curriculum development when I went looking for a rule I knew I had already written down. I found it in the memory of a different machine, in a form that worked only there. The rules were real, earned one correction at a time. What they lacked was a structure, and any way to travel.

They are a repo now. I call it MarkOS. That repo is me.

It is eight skills today that an AI coding assistant loads before it does anything in my name, and the number goes up. Two of them hold substrate: a record of what is verifiably true about my career, down to the phrasing I use for each claim, and a file describing what I optimize for when a decision comes down to judgment rather than rule. Above those sit nine writing voices, because the register for an incident report has almost nothing in common with the register for a keynote. Teaching gets a skill of its own, and another covers how I handle a live room.

The last two do work rather than decide how something reads. One comes up to speed on a repo I have not opened in months and briefs me on what changed. The other composes and sends mail as me, and it lives in here rather than in machine config because the rule that governs it does: nothing goes out without my say-so on that specific draft, in that moment. Keeping a rule and the thing it governs in the same repo is most of the reason this works at all.

It caught me that same afternoon. Rule two of the constitution is no em dashes, anywhere, in any document. The assistant had been scattering them through long replies all session, because the rule was sitting in a repo this machine had not cloned. Once the install finished, mid-conversation, they stopped.

The one idea

The mental model that works for me is concentric rings.

Ring 0 is substrate. Ring 1 is a constitution of four rules. Ring 2 is method, ring 3 is craft, and ring 4 is the immediate context of audience and medium. Every step outward narrows and inherits everything inside it. A voice can add a rule about executive writing. It cannot grant itself an exemption from the requirement that claims be checkable.

What it actually does

The system is invoked rather than ambient. I type a short command and a specific set of files loads.

/voice exec goes on before I write to a business leader. That pulls the base layer plus one voice: what to do with a superlative, and the rule that a strong opinion about the business gets owned with “I believe” or cut.

/teaching wgu goes on before I review course material as a subject-matter expert. Competency-based education carries constraints that do not transfer to a fifteen-week undergraduate course, which has a profile of its own. I teach roughly four thousand students a year across four institutions, and the assumptions travel badly between them.

/speaking goes on before a live room. In July I gave a 45-minute solo session on AI in cinema operations at a convention in Milwaukee. Whether a live demo is worth the risk, and what the first question in Q&A is likely to be. Neither is the same problem as how the slides should read, so it lives in a skill of its own.

/orient goes on when I open a repo I have not touched in months. It reads the rules file, the front door, and the recent history, then tells me where things stand and what is half-finished. Same principle as the voices, pointed at a codebase instead of a paragraph: the knowledge sits in files rather than in my memory of the project.

This note loaded explainer, the register for taking a mechanism apart so you can see how it works.

Why it matters

If you have ever written a style guide, a system prompt, or an acceptable-use policy for AI at your company, you have already made this decision. You just may not have noticed you were making it.

Every rule you write lands somewhere in a scope. Get the scope wrong and the rule quietly fails to cover the case you cared about most.

My version of that decision is a filing rule: a correction goes at the innermost ring that explains it, not the ring where I happened to notice it. “That’s not who I am” is ring 0, values. A wrong date is ring 0, record. “No em dashes” is constitutional, so it binds from ring 1 outward. A ban on a particular piece of jargon is a base-layer style rule at ring 2. Guidance about how I write to one specific executive sits at ring 3, inside that one voice.

Filing too far out is how a system like this decays. Had I filed “no fabrication” inside the executive voice, where I first caught the problem, it would have covered one kind of document, and my incident reports and my fiction research would have walked out unchecked. Filing too far in is the cheaper mistake, since the rule just fails to fire and I notice.

What it buys me

The payoff I did not expect is that corrections stop evaporating. A good line-edit used to live for exactly as long as the conversation it happened in. Now it gets written down at the ring that explains it, committed, and it is waiting the next time, on whatever machine I happen to be sitting at. The system sharpens as a byproduct of me being annoyed at it.

Keeping the registers apart is the part I built it for. Nine voices sounds excessive until you watch a runbook and a keynote abstract get drafted in the same afternoon and catch the cadence of one showing up in the other.

The one I would keep if I had to throw the other five away is the record file. It holds what I can say about my own career and the phrasing for each item, so a draft that reaches for a punchier version of something true gets stopped by a file instead of by me on a reread three days later. What I watch for is rarely invention from nothing. The usual failure is a true statement compressed until it stops being true, which reads better than the original and is exactly why it survives review.

Show the gears

Seven folders and a file at the root, and the root is itself the eighth skill.

SKILL.md        the entry point, and the map of the rest
values/         what I optimize for when judgment beats rule
record/         what is verifiably true, and the explicit do-not-claim list
voice/          nine voices, one base layer, and the gate
teaching/       doctrine, checklists, three context profiles
speaking/       audience analysis, room handling, production
orient/         coming up to speed on an unfamiliar repo
send-email/     mail as me, and the gate it has to clear first

Each folder holds a SKILL.md that opens with a name and a description of when it applies. The assistant reads those descriptions, and when a task matches one it pulls that folder into context.

Installing is where it gets interesting, because the skills directory does not belong to this repo. It belongs to a different one.

There are three, split by the question each answers. dotclaude carries the machine’s own configuration: its settings and hooks, plus the memory that is about this laptop rather than about me. MarkOS is the skills. The third holds what the assistant has learned working on each individual project, which picks up live employer and client detail as it goes.

Sensitivity is what splits them. The first two are dull enough to hand to anyone. The third is not, so it stays where it is instead of travelling with the rest.

~/.claude/skills/ lives inside dotclaude. Every entry in it is a junction into the MarkOS working tree:

me          ->  the MarkOS repo root
values      ->  MarkOS/values
record      ->  MarkOS/record
voice       ->  MarkOS/voice
teaching    ->  MarkOS/teaching
speaking    ->  MarkOS/speaking
orient      ->  MarkOS/orient
send-email  ->  MarkOS/send-email

One repo owns the directory and another owns everything inside it. A git pull in either updates its own half, and neither can swallow the other. The skill called me points at the repo root, so the umbrella and the repo are the same folder.

That line took a revision to get right. Both operations skills started in the config repo, which left send-email in one repo while rule 3, the rule that decides whether it may send anything at all, sat in another. Moving them put each rule back within reach of the thing it governs.

Junctions on Windows, symlinks on macOS and Linux. Junctions need no administrator rights, which is why the Windows install needs no elevation. Nothing is copied, so there is no second version to drift, and an edit is live in the next session.

The project memory connects a different way, with no junction at all. A hook fires when a session ends cleanly, syncs the store, commits it, and pushes. Nothing to remember and nothing to run.

Which is what makes the em-dash catch from that first afternoon worth a second look. I dislike the em dash on its own terms and I consider it a tell, but the rule had no force on that machine until the junctions existed. The moment the symlinks resolved, the habit stopped mid-sentence.

Small thing, and also the whole demonstration. The constraint was never in the model. It was in a file, and the file had not been mounted.

There is one more piece, and it is the piece I would have left out if I had designed this instead of growing it. Following the rules while drafting turns out to be insufficient. Word-level rules are easy to obey sentence by sentence, and a draft can clear all of them and still read as machine-written, because the giveaways are structural: parallel bullets built on one identical template, or a final line that comments on the document rather than ending it. Those only become visible once the whole thing exists.

The gate is therefore a separate file that runs over the finished draft in four passes. Literal string searches first. Then a structural read that ignores content and looks only at shape, counting the three-item lists and the balanced contrasts. Then a pass that stops at every sentence carrying a number and asks what document backs each word of it. Then a last look at the opening and closing paragraphs to check they still sound like the voice I asked for. This note went through all four before you read it.

That is the part worth taking away if you are trying to get consistent output out of one of these systems. What I have found is that consistency is less a personality you coax out of the model than a lookup order you supply, evaluated inside out, and checked again at the end regardless of which voice was active.

The part I have not solved

The system is assembled from corrections, so it is sharpest exactly where I have gone wrong before and thin everywhere I have not.

There is no entry for the things I have never once gotten wrong, because nothing ever generated a correction to file. Read it straight through and you get a clear picture of my failure modes and a vague one of my instincts. The values file is the thinnest of them for that reason, and my own notes in the repo flag it as the one built mostly from inference.

More rules will not fix that. It might be what a system built this way is: a portrait assembled entirely from the times someone said “no, not like that.”

Feels like magic. It’s math.

Mark