Standing Instructions for a Team

When a team starts using AI, everyone builds their own habits. One person pastes the company description into every conversation. Another has a long custom instruction they wrote six months ago and forgot about. A third uses it with no setup at all. The results come back in three different voices with three different sets of facts, and nobody can tell which version of the company the assistant was working from.

Standing instructions fix this. They’re a shared document the assistant reads before every task in a project or workspace: who the organization is, how it talks, what terms it uses, and what the assistant should never do. Most tools have a place for them, usually called project instructions or custom instructions. Some teams keep them as a file in a shared folder, often named something like CLAUDE.md or INSTRUCTIONS.md, that gets loaded automatically.

I keep standing instructions for my own work, and I’ve built a template for organizations that want one. The template is a scaffold: a set of headings and prompts a team fills in during its first few weeks. What follows is what goes in it.

Who we are

Start with a short description of the organization as you’d explain it to a new hire. What you do, who you serve, how big you are, and what makes your work different from the company down the road. Keep it to a few paragraphs. The assistant doesn’t need your history. It needs enough context to make sensible guesses.

Add the people and roles the assistant is likely to hear about. Not a full org chart, just enough that “send it to Maria in purchasing” makes sense.

Terms and names

Every organization has its own vocabulary. Product names, internal project names, abbreviations, the customer word you use instead of “client.” Write them down with a one-line definition. This is where a lot of embarrassing mistakes come from: an assistant that spells your product name three different ways, or uses a competitor’s term because it’s more common online.

Terms
- "Service agreement," never "maintenance contract." Customers sign service agreements.
- "Field team" means our technicians. "Office team" means everyone else.
- Product names are always capitalized exactly as listed in /reference/products.md.

Tone and formats

Describe how the organization sounds in writing. A few sentences of description and one or two short examples work better than a list of adjectives. “Friendly and professional” means nothing. “We write like a knowledgeable person talking across the counter, short sentences, no exclamation points, no sales language” means something.

Then list the formats your team uses most, with a pointer to where the full version lives. Customer emails, quotes, internal updates, meeting notes. If a format has strict rules, like a proposal structure your customers expect, say so here and link the template.

What never goes in

This section matters more than any other. Be plain about it.

• Information that must never be pasted into the assistant: customer financial details, health information, employee records, passwords, anything under a confidentiality agreement.
• Things the assistant must never do: invent prices, make promises about delivery dates, give legal or medical advice, or send anything without a person reading it.
• What to do when it doesn’t know: say so, and ask. Don’t fill the gap.

If the organization has an AI use policy, point to it here and summarize the rules that apply day to day.

Where reference files live

Standing instructions should be short. The detail belongs in reference files the instructions point to: the product catalog, the price list, the style guide, past proposals that went well. Say where each one lives and which one wins if two disagree.

Reference files
- Products and specs: /reference/products.md (owner: Dave, reviewed monthly)
- Current pricing: /reference/pricing.md (owner: finance). If anything else conflicts, this file wins.
- Proposal template: /templates/proposal.md

Keeping instructions short and pointing to files has a practical reason. When the price list changes, you update one file. You don’t have to remember every place someone pasted the old prices into a prompt.

Ownership and versioning

Instructions without an owner go stale within months. Name one person responsible for the document, even in a small organization. Their job isn’t to write everything. It’s to collect corrections, decide what changes, and keep it current.

Version it. A version number and a short change log at the bottom are enough. When someone says the assistant started doing something odd last week, the change log is the first place to look. My own instruction files carry a version number and a change log for exactly this reason.

Review on a schedule. Quarterly is reasonable for most teams. Read it start to finish and ask what’s no longer true.

Start small

You don’t need all of this on the first day. A useful first version is one page: who you are, ten key terms, the tone in a paragraph, and what never goes in. Use it for two weeks, collect every correction your team finds themselves typing, and add those. That’s how the template I use is meant to be filled in: a little at a time, from real work.

The goal is that anyone on the team can open the assistant and get work that sounds like the organization and uses its real facts, without having to explain the company first. A person still reads everything before it goes out. The instructions just make what they’re reading a lot closer to right.