The hardest part of starting a vault is the empty folder. These are the ten notes I would write first for any team using AI coding tools, in the order I would write them. Each is a type of note, with an example from mine. Your examples will differ; the types will not.
-
How we set up a new project. The exact steps, the accounts, the environment variables, the three things that go wrong every time. Mine records that a particular hosting adapter’s latest version requires a framework version we do not use yet, and to pin the older one. That sentence has saved an hour on every project since.
-
The gotcha that bit us last. One mechanism, one symptom, one fix. “Column-level grants are additive; the narrower grant is a no-op until you revoke the table-level one.” Write it the day it happens.
-
How we make the tool interview us before it builds. The prompt, three sentences long, and the rule for when to use it: anything touching a schema, an architecture or money.
-
What we keep in every repository. The instructions file, the architecture note, the decision log, the one-line memory file, and the ritual: read at session start, update before close, update mid-session when something important is settled.
-
How we review AI-written code. The order to read in, the mistakes that show up most, what to grep for. Short enough to actually follow.
-
How we know an app is working. The invariants we check on real data, the rule to log and continue rather than block, and version tags on every error.
-
Our security baseline. What secure means for our applications, in one page. Authentication, who can see what, injection, outbound calls, secrets, scheduled jobs. The scanning schedule and who reviews the findings.
-
Our data rules. What may go to which AI model, what must never leave, and who to ask. The one-page policy, or a link to it.
-
A decision we made and why. The first architecture or vendor decision with its reasoning. Not because the decision matters most, but because the habit of recording reasoning is what stops the next session relitigating it.
-
How to get a real choice out of a non-designer. Or whatever your team’s equivalent is: the process lesson that has nothing to do with code. Mine is about stable option names and honest tradeoffs on a design canvas. Yours might be about running a client workshop.
Write the index line for each as if for a stranger searching by problem: the symptom, the mechanism, the stack. “Setup gotchas” is a title. “Adapter latest peers on a framework we do not run; pin the previous major” is a hook, and it is the hook the tool will match against.
Ten notes take an afternoon. The eleventh will write itself the next time something breaks.