A standard the machine consumes

A code standard written for humans has a known problem: nobody reads it at the moment that matters. A standard written for an agent has another, quieter one: it keeps looking correct after it has become wrong. A document that teaches a method whose signature changed breaks nothing. It just teaches wrong, to everyone, indefinitely.

It was by solving those two problems that the house standard became infrastructure instead of a document.

One source, several consumers

The rule lives written once, in a neutral format, without knowing which tool will consume it. Each AI tool has a thin adapter that translates it into the format it understands. Adding a new tool tomorrow is writing an adapter, not rewriting the standards.

That solves a real market problem: AI tools have not converged on an instruction format, and probably will not any time soon. Tying the house standard to one vendor’s format is buying a future migration.

There are also two audiences with opposite needs, and treating them the same spoils both. An agent needs an imperative rule, a compilable example and the consequence of getting it wrong. A human needs narrative, the why of the decision and the historical context. They are different files, with the same subject.

What keeps the standard from rotting

This is the part I like the most, and the idea is simple: there is a project that consumes every API cited by the standards, and compiling is the assertion. If the standard describes a method that no longer exists, it is not a document that goes stale in silence: it is a build that turns red.

Combined with automatic dependency updates and a periodic run, “the standard rotted” stops being an embarrassing discovery in code review and becomes a red PR. The drift does not come from a commit in the standards repository: it comes from a package changing out there, and that is why the check needs to run even when nobody touched anything.

The mechanism does not cover everything, and it is worth saying: prose and justification are not verifiable this way, and policy, “we don’t use such-and-such library”, is not a statement about the world. It covers the most dangerous category, which is the concrete technical statement that ages without warning.

Skills pointing to my tools

A standard that describes what to do is half. The other half is the skill that executes the right path, using the CLIs from Tool as CLI.

Skills and standard rules are distributed in two layers:

• At the user level, what holds for any project: the merge request ritual, how to open a database session, how to read a service log
• At the project level, what only holds there: the architecture of that repository, the known trap of that domain, what not to do

The hooks are the layer that acts without me asking: mechanical checking before the commit, refusal of personal data, and the capture of the friction that feeds The cycle that feeds itself. Each hook exists as a pair, because the team works on two operating systems, and a hook that only runs on half the machines is worse than no hook: it creates the expectation of protection without delivering it.

The machine context is also split this way: there is a part common to everyone and a part per operating system, because what the agent needs to know about where things are changes between them, and writing “it depends on your system” inside a single file is pushing the decision to the agent at the wrong time.

The split between what is always loaded and what is read on demand matters more than it seems. Always-loaded context goes into every request, so it stays short and contains only what holds for any edit. Stuffing everything in there would spend context in every conversation to deliver API rules to someone who is editing a test.

What this replaced

Before, the house standard was a set of written, versioned rules, citable in review. That was already better than an agreed standard, for the reason described in Code review and standards: with a written rule the note is “this goes against rule X”, and without it, it is “I would do it differently”.

What changed is that the rule stopped depending on someone remembering to apply it. It arrives together with the code, at the moment the code is being written.