Write your conventions for the agent, not the next hire

We have all worked in a codebase with three ways to do the same thing. One the founder wrote in a hurry, one a contractor left behind, one that is just whatever the last person copied off the internet. You learn to read all three. It is annoying but survivable, because a human can hold a contradiction in their head and pick the right pattern by smell.

A coding agent cannot smell anything.

Give an agent a codebase with three ways to fetch data and it will cheerfully add a fourth. Not because it is dumb, but because it has no reason to prefer yours. It pattern-matches against everything it has ever seen, and everything it has ever seen includes every bad tutorial ever published. The drift is not a one-time mess you clean up later. It compounds. Every file the agent writes becomes context for the next file, so one sloppy week teaches the agent to keep being sloppy.

The usual answer to this is a long prompt. You paste your preferences at the start of every session and hope they survive. They do not. The model loses them, the session resets, you forget to paste them, and you are back to three patterns and counting.

The better answer is to write the rules down where the agent will find them on its own.

That is what AGENTS.md is. Not documentation for the next human hire, though it works for that too. It is a contract the agent reads before it works. One documented way to access data. One way to handle secrets. One way to gate an authenticated route. One way to add a migration, a locale string, a Stripe price. The agent does not have to guess your taste, because your taste is written down in a place it actually looks.

Writing it down is half the job. The other half is handing the agent the current facts instead of a stale memory of them. An agent that guesses your database columns will guess wrong, and confidently. So BoiledPlate ships read-only MCP servers that let the agent look at your real Supabase schema, the actual Nuxt UI component docs, and your Stripe test data while it builds. It is the difference between an assistant who read the manual once and one who has the manual open on the desk.

There is one more layer, and it is the one I am most attached to. Vendor skills. The Supabase team, the Stripe team, and the Nuxt UI team all have opinions about how their tools should be used, and those opinions live in skills the agent can consult. I vendor them into the repo, hash-locked, refreshed by a weekly CI pull request so they do not silently rot. On top of those I wrote one of my own for Nuxt 4 patterns, with every rule anchored to a real file in the repo so the agent can go read the example instead of trusting a description of it.

Put together, the agent building in BoiledPlate is not improvising your conventions from memory. It is reading them, checking them against your live schema, and following skills written by the people who made the tools. The output stays consistent in month three because consistency was designed in, not nagged in.

The old instinct says write clean code and document it for whoever comes next. That instinct is right. It is just aimed at the wrong reader now. The next contributor to your codebase is an agent, and it will follow your rules exactly as well as you wrote them down.