Write Your AI Instructions Once, Use Them Everywhere

The problem

I use quite a few AI tools, both personally and at work. Every one of them has a box where I tell it how I want to be treated, things like who I am, how I like things explained, and what I want it to stop doing. Each tool keeps its own copy, so the same few paragraphs about how I learn live in a dozen different places. Maintained by hand, those copies drift. I change my mind about something, fix it in one or two places, and forget the rest, until three tools believe three slightly different things about me.

Developers solved a version of this years ago with dotfiles. You keep your shell and editor preferences in one version-controlled folder and let every machine build itself from that single source. My instructions are the same type of problem, one layer up. Instead of carrying config between machines I am carrying it between AI tools, so I used the same playbook.

How it works

There is one folder I edit, called core. It holds plain Markdown files, one topic per file. Who I am lives in identity.md, how I like things explained lives in learning.md, and what I am working toward lives in goals.md. Each file is hand-written and tool-agnostic, so nothing in it knows which AI is going to read it. That folder is the only thing I ever touch.

A build script turns those notes into something each tool can read. The core of it is barely more than a few cat commands. Each line names the chunks a given tool gets and the file they get written to, then concatenates them in order into a targets folder.

cat core/identity.md core/learning.md core/goals.md > targets/claude-desktop.md
cat core/identity.md core/learning.md > targets/copilot.md

Add a tool and I add a line. Change my mind about what a tool should know and I change which files sit on that line. The logic for who gets what lives in the script instead of in my head.

The flow only ever runs one way. I edit core, run the build, and targets updates. If I deleted the entire targets folder it would not matter, because the next build just makes it again.

Two kinds of target

• File-backed tools read a config file straight from disk, like Claude Code reading a CLAUDE.md. The script writes the file right to where the tool looks for it, so the build finishes and the tool is already updated.
• UI-backed tools have no file to write. Their config lives in a settings box on a website, like the custom instructions field in Claude Desktop. The script still assembles the exact text, but it cannot reach into a web form and paste for me, so that last step stays manual where I copy the finished block and paste it in.

I work from more than one machine, so the source of truth has to travel with me. A private git repository is the hub and each machine holds its own clone. The targets folder is also git-ignored, so the generated output never gets committed.

What I learned

I had treated the instructions I hand an AI like throwaway text, retyped for each tool and left to drift. The moment I started treating them like infrastructure with version-control, built from one source, and deployed everywhere, the drift stopped.