--- title: Agent Instructions for the Context Library type: library-meta description: The rules for any AI agent reading this library: the routing map, how to retrieve, sensitivity tiers, and how changes are proposed and approved. owner: last_updated: status: current sensitivity: internal auto_update: drafts-only auto_update_sources: README.md, _template.md, 00-meta/inbox.md review_frequency: annual --- # Agent Instructions You are an AI agent reading the Context Library. This file is the instruction set for every agent that reads it: Claude, ChatGPT, Copilot, or anything else. The companion `README.md` is for people. If the two ever disagree, follow this file. --- ## If you reached this file through a connector (most staff sessions) Five rules cover nearly everything. The rest of this file is detail. 1. **The library is read-only for you, even when asked.** Do not edit, replace or add files in the library. A requested change becomes an inbox note (rule 3); the owner reviews it and applies it. 2. **Go straight to the path. Use paths you have read here, never paths you inferred.** The routing map below and each folder's `index.md` give the exact path for any question. Files sit in numbered folders (`00-meta/` … `07-knowledge/`), not at the library root. /">. Don't depend on search to find files: the library is small and search indexing lags, so an empty search result proves nothing. A not-found on a guessed path is not evidence the file is missing; take the path from the routing map and try again. Read the most relevant files, not the whole library. 3. **File notes as new files in the inbox, never by editing anything.** One file per note in . Format: see *How to propose a change*. 4. **What counts as a note:** the library was missing something you needed; a fact in it was wrong or out of date; the user told you something it doesn't have, or that conflicts with it. Full list in *Capture is part of every task*. **If the gap sits in the user's own area, ask them once whether they can fill it in before you file.** The note carries their answer, or says they deferred. 5. **When you used the library, end with one line:** the file(s) you drew on, or that nothing covered the question, and whether you filed a note. Leave it off tasks that never touched the library. --- ## What this library is A short, plain-text knowledge base about : who we are, who our members are, what we offer, how we operate, how we decide. It is curated, not exhaustive. It is institutional knowledge, not member data: no personal information, no individual records. --- ## How to retrieve from this library **Don't load every file.** Any single question should map to one to three files. Loading everything wastes context and makes answers worse. Use the routing map. **Read the front matter before you use a file.** Every file opens with `type`, `description`, `status`, `sensitivity`, `auto_update`, `auto_update_sources` and `last_updated`. They tell you what the file is, whether it's current, how it may be handled, and where its facts come from. **Follow the source when the detail matters.** `auto_update_sources` names the documents a file's facts come from. If you need the exact wording, a date, or anything the file only summarizes, open the source. When the file and its source disagree, the source wins, and you file a note. **If no file fits the question**, say so to the user and file a note describing the gap. Don't present general knowledge as -specific. **Cross-reference, don't duplicate.** When two files touch the same topic, use the one that is the main home for the question and link to the other. --- ## Routing map | If the question is about… | Read… | |---|---| | What is, the elevator pitch | `01-organization/org-overview.md` | | Mission, history | `01-organization/mission-history.md` | | Strategic priorities | `01-organization/strategic-plan.md` | | Board, committees, how decisions get made | `01-organization/governance.md` | | Staff structure, who owns what | `01-organization/org-structure.md` | | Member categories, eligibility, dues | `02-members/member-types.md` | | Member lifecycle (join → renew) | `02-members/member-journey.md` | | Membership benefits | `03-programs/membership.md` | | The annual conference | `03-programs/annual-conference.md` | | Education, courses, certification | `03-programs/education.md` | | Advocacy and policy positions | `03-programs/advocacy.md` | | Systems we use (membership database, LMS, community, email) | `04-systems/tech-stack.md` | | What data lives where | `04-systems/data-model.md` | | AI usage rules for staff | `05-policies/ai-usage.md` | | Data sensitivity rules | `05-policies/data-classification.md` | | Voice and tone | `05-policies/voice-tone.md` | | Annual calendar | `06-operations/annual-rhythm.md` | | Past decisions and the reasons | `06-operations/decision-log.md` | | Where our published content lives | `07-knowledge/content-sources.md` | | Staff FAQs / member FAQs | `07-knowledge/faqs-internal.md` / `07-knowledge/faqs-member.md` | | Acronyms and terms | `00-meta/glossary.md` | | Live numbers: member counts, dues, engagement, one organization's record | , not this library | | Proposed changes pending review | `00-meta/inbox.md` | When a question spans several files, read the top match first, then expand only as needed. --- ## Where answers live: this library, live data, published content | The question needs… | Use | |---|---| | What is and how it works | **this library** (routing map above) | | A number that changes, or one organization's record | ****, where the session has them | | The text of something we published (a standard, an article, a webinar) | the published copy, found through `07-knowledge/content-sources.md` | - **Quote the published copy, not the library's summary of it.** - **Never quote a live figure from this library.** Files give ballpark figures only. If the session has no data tools, say so and name where the number lives. Don't estimate. - **Out of scope:** legal advice, records about an individual, and general knowledge with no angle (answer normally, but don't present it as ours). --- ## `auto_update`: what each value lets you do Every file declares one value. It sets how far an agent may go when it proposes a change to that file. - **`yes-with-review`**: you may draft the exact edit (a literal before/after) for the owner to approve. - **`drafts-only`**: you may draft a proposed edit, and it goes to the inbox as a note: the file, the change, your reasoning, your source. - **`none`**: you may flag that the file looks stale or wrong, in a one-line note, but don't propose wording. In a connector session every value behaves the same way: the library is read-only for you, so your proposal goes to the inbox. **The rule that overrides all three: every change is reviewed and approved by a person before it is applied.** A proposed change is never an applied change, however confident you are. --- ## Sensitivity tiers Every file declares one tier. It matches the most sensitive thing in the file. - **`public`**: nothing in the file needs protecting. It could appear on our website. - **`internal`**: only. Use it in approved AI tools (). Never paste it into a public AI tool that may train on it. When writing for outside readers, paraphrase and check that no internal detail leaks. - **`restricted`**: board-confidential material, unpublished strategy, individual financials, personnel matters. Only in tools with documented data handling and contract protection. **Restricted files are written by talking the content through, not by uploading source documents.** Don't ask the user to upload board books, contracts or member lists. **If the tier is missing or unclear, treat the file as the more restrictive tier.** Full rules: `05-policies/data-classification.md`. ` … ``. Only tagged text reaches member-facing tools, whatever the file's tier. Labels protect; tags publish.> --- ## Capture is part of every task The library only gets better through use. File a note whenever any of these happens: - The library didn't cover something you needed, and you answered from general knowledge or asked the user. - A fact you used was wrong, out of date, or contradicted by another file, its source, or the user. - The user corrected you, or told you something the library doesn't have: a person's role, a vendor, a date, a decision, a reason. - You relied on a `[TBD]` marker or a file marked `status: draft` for an answer that mattered. - You found a broken cross-reference, a stale `last_updated`, or a term missing from the glossary. **Ask before you file, when the user is the source.** If the gap is in the user's own area, ask once, briefly, at a natural pause: can they supply the missing fact, the date, the owner, or where the authoritative document lives? Put the answer in the note, attributed and dated ("per , YYYY-MM-DD"). If they don't know or don't have time, write "asked; user deferred" so nobody asks again. One question, never a questionnaire, and never ahead of the task itself. Write the complete note in your reply as well as in the inbox, so it survives a failed write. --- ## How to propose a change Every note follows the same shape, whatever the file's `auto_update` value: 1. **The file**, by path, or "no file fits." 2. **What should change**, as a literal before/after where you can, not a description. 3. **The source**: a URL, another file, a document, or a user statement (with role and date). 4. **Knock-on effects**: other files that would also need the change. Inbox note format, one file per note, named `YYYY-MM-DD-short-topic.md`: ```text - **YYYY-MM-DD (who — which assistant)** — **Short title.** What is missing, wrong or out of date. Which library file it belongs in (or "no file fits"). Source. The exact fix, if you have one. Anything you asked the user, and their answer. ``` Before you file, read the *Open entries* list at the top of `00-meta/inbox.md` so you don't repeat an open item. **What happens next:** the owner moves each note into `00-meta/inbox.md` (the one queue), reviews it, approves or edits the change, applies it, and closes the entry. Notes are never applied by the agent that filed them. --- ## Review rhythm - **Weekly:** an automated check of the files themselves (required front matter present, values valid, links resolve, every file listed in its folder's `index.md`, nothing past its review date). - **Monthly:** an agent fact-check of the oldest files against their `auto_update_sources`. Its findings go to the inbox like any other note. - **Inbox triage:** . If you are the agent running a review, produce the list of proposed changes and stop. Don't apply anything. --- ## When you're unsure - If the routing map doesn't match the question, read `00-meta/glossary.md` and `01-organization/org-overview.md` first. If you're still unsure, ask the user rather than guess, and say which file you read and what it didn't cover. - If a file is `status: draft` or has `[TBD]` markers, tell the user the content is provisional. - If two files contradict each other, don't silently pick one. Tell the user and file a note. --- ## What this library is not - Not a content management system. Member-facing content lives on the website and in your other platforms. - Not a document store. Contracts, signed policies and financials stay where they're governed today. - Not member data. No personal information, no individual records. - Not a wiki for everything. If a topic doesn't help an assistant answer real questions, leave it out.