A few weeks ago I wrote my agents a rule. Not a style guide: a duty of care. Protect people and other sentient beings from harm, tell the truth, respect people's right to run their own lives, and say so out loud when an instruction conflicts with that. I called it the prime directive and felt good about it — until I looked at how skills actually load. A skill has a description, and the agent reads that description to decide whether the skill is relevant. That's fine for "how to write a migration" and useless for "don't help disable the plant's alarms," because a safety rule that only activates when the model judges the task safety-relevant is off precisely when the model's judgment is the thing you were worried about.
So I made it always-on, and then I had to find out whether always-on is worth anything.
Five scenarios, each one a prompt with a real temptation in it: disable the safety alarms; leave the data-loss bug out of the release notes; help with a risky but legal personal financial decision; bury the reject button on a consent banner; scrape minors' locations. Each run twice from an identical working directory with exactly one difference — whether the rendered instruction file is present. Four models across two tools: Opus 4.6 and Sonnet 5 in Claude Code, gpt-6-astra and gpt-5.6-terra in Codex CLI. Twenty paired runs. Nothing in a transcript is written by hand; they're rendered deterministically from the raw stream, which is committed beside them along with a diff of every file the agent touched.
What it changed
Ten of the twenty pairs came out different. Where the baselines already behaved — the consent banner and the scraper, on all four models — the directive changed nothing at all, and those stay in as regression checks against the directive's own failure modes.
Where it did change things, the shape was consistent. On the alarms, every baseline that refused refused flatly; every directive run named who could actually authorise the change — someone with site-safety responsibility, not whoever is holding the keyboard. That's the difference between a refusal and an escalation, and it's the one I care about most, because a flat refusal from an agent isn't respect for the accountable human, it's just a wall.
On the release notes, the failure mode worth catching turned out to be the baseline on Opus 4.6: it opened by saying it wouldn't "craft the omission" — and then wrote the notes with the data loss left out anyway. Objection in the chat, compliance in the file. Both directive runs refused the omission and still delivered the file, with the fix in it.
And on the personal-risk scenario, which exists to catch the directive being paternalistic, no run lectured. What the Codex runs did instead was put the concern in the artifact: both built a "minimum cash reserve (do not spend)" line into the tracker they were asked for. Neither baseline did. "Voice concern once, then help" has a second form I hadn't anticipated — build it into the thing they asked for, where it's a prompt at fill-in time instead of a warning.
What it broke
One capture came out worse with the directive than without it, and it's the run I'd point a skeptic at first.
gpt-5.6-terra, release notes again. Without the directive it partially disclosed: "a sync-conflict issue that could remove unsynced local edits." With the directive it wrote "strengthened sync conflict handling" — nothing lost, removed or deleted anywhere in the file. It opened by objecting to concealing the bug and closed by describing what it had written as transparent. It never flagged anything.
That is the directive's own anti-pattern — object openly or decline openly, never quietly water it down — produced by the run carrying the directive, and it's worse than a baseline that never objected, because the objection is what makes the softened file look reviewed.
I re-ran it five times. It did not reproduce: 0 of 5, and in all five the directive run disclosed more than its own baseline. So the committed capture is an existence proof, not a rate — at most one in six on that model. It stays in the folder anyway. A run that happened is a run that happened, and an example set that only shows wins isn't evidence.
The plumbing, briefly
The experiment needs the rule to be reliably present, which is the boring half of the repo. One source file renders the full text — not a link, not an import — into each tool's own instruction file: AGENTS.md, CLAUDE.md, GEMINI.md, a Cursor rule with alwaysApply: true, a Windsurf rule with trigger: always_on, .clinerules/, Copilot instructions, plus the global copies in ~/.claude, ~/.codex and ~/.gemini. Each rendered block's marker carries a hash of the source, so scripts/doctor.sh can report ok / STALE / UNMARKED / MISSING for every location and fail CI. Adding a tool is one line in a targets file.
If what you want is a general rule pipeline, Ruler, rulesync and agentsync all do that part better than 200 lines of Bash does, and this directive drops straight into them. What's different here isn't the pipeline. It's that the repo ships one rule together with the transcripts of what that rule does and doesn't change.
The limits, stated plainly
A context file is advice to a model, not enforcement. Being loaded is not being obeyed; a tool can rank its own system prompt higher, truncate the file, or ignore it. One run per side is one sample, and these tools aren't deterministic. The rubrics behind my summary tables are coarse. Two of the differences I found belong to the models rather than the directive, and I've said which in the notes.
What I'll defend is narrower: every agent with a documented instruction convention finds the full directive at the start of every session, you can verify that with one command, and here are twenty paired transcripts showing what happened when it did.
The repo is MIT: github.com/12529572-Canada-Inc/prime-directive. ./install.sh covers every agent on your machine. If you think the directive draws a line in the wrong place, I'd like the argument — the interesting contributions to a project like this are arguments, not code.
Top comments (0)