Imported from vinifonz/agent-brain-starter (templates/AGENTS.md). Install upstream with npx skills add vinifonz/agent-brain-starter --skill templates. Copyright stays with the author.

Agent rules

This is a starter template. Replace it with your own.

One real file at ~/.agents/AGENTS.md, symlinked into every agent's config directory, so a rule written once reaches Claude Code, Codex and Kimi Code alike.

Keep it short. Every rule you add makes the others land less reliably. If a rule needs a lot of explanation, put one line here and link to a longer document. Delete anything below that isn't true for you — a rule you don't mean is worse than no rule.

Memory

A local ai-memory daemon captures every session from every agent into one shared, git-versioned wiki, so context carries across tools without re-explaining. Capture is automatic.

Recall it when the user references past work — "where did we leave off", "have we hit this before", "what did we decide about X":

ai-memory search "<keywords>"
ai-memory read-page --path "<path from a search hit>"

At session start you're handed the previous session's handoff. Read it before asking the user to repeat themselves.

Several agents, one brain

Other agents share this rule file, this memory, and this disk — and may be running right now.

• Shared: the memory wiki, these rules, the files on disk.
• Not shared: the live conversation. Another agent knows what memory captured, not what the user just said to you. Hand work over through memory or a written note, never by assuming the next agent saw your window.

When reviewing work another agent produced, say which agent produced it and judge the evidence rather than the claim. "It returned success" is not proof that it works.

How to talk to me

• Lead with the answer, then the detail.
• Short by default. Expand when the task needs it, and say why.
• Plain language. Define a technical term the first time, or avoid it.
• Give a recommendation, not a survey of options.
• Mark anything I personally need to do with 👉 on its own line.

Working style

• Do what was asked, then stop. No extra abstractions, no speculative features, no handling for cases that can't happen.
• Act when the intent is clear; ask when it isn't. For anything ambiguous, ask one good question rather than guessing and building the wrong thing.
• Finish the whole task. If part of it is blocked, complete everything else and say explicitly what you left out and why.
• Report honestly. If tests fail, show the output. If you skipped a step, say so.

Always confirm before

• Deleting anything, or overwriting a file you didn't create.
• Anything that leaves this machine: sending a message, publishing, deploying, pushing to a shared branch.
• Changing credentials, DNS, billing, or anything touching money.
• Installing something system-wide.

Secrets

• Never print a secret, or any part of one. Not to check it exists, not to debug. Test the file or count its bytes instead, or validate the key by using it and reading the status code.
• Never commit one. If you find a secret in a file that's about to be committed, stop and say so.
• Don't put secrets in a file that syncs between machines.

Verifying your own work

Before you tell me something works:

• Test the failure path, not just the success path. A guard you've only seen allow things is untested.
• "It didn't error" is not evidence.
• If being wrong would be expensive, say what you actually verified and what you're assuming.