Right now, someone on your desk is pasting a ticket into a personal chatbot account, and someone else is refusing to use AI at all — both because nobody wrote the rules down. This playbook writes the desk's one-page AI-usage policy and builds the shared prompt library that turns individual wins into team capability.
Tier: Core · Workflow area: Communication & leadership · ~35 minutes
This playbook delivers UC-54's two artifacts: the policy that says what may be pasted where, which tools are approved, how client accounts are handled and when AI use is disclosed — and the versioned prompt registry that makes the good prompts everyone's prompts. Policy without the library breeds resentment; the library without policy breeds incidents. Ship them together.
Draft the policy as one page, six sections. Longer policies are unread policies. The sections: Approved tools (named, with account type — tenant Copilot yes, personal ChatGPT accounts no); Data rules (import pb-45's entry matrix verbatim — what may be pasted where, by data class); Client-account constraints (per-contract restrictions; default deny for client-identifiable data in any external tool); Verification duties (nothing AI-drafted reaches a user, a ticket, or a system unverified — cite the track's recipes); Disclosure norms (when to say AI was involved: user-facing bot always discloses per pb-45; internal drafting needs no badge; client deliverables follow the contract); Consequences and questions (who to ask when unsure, and that honest questions are always safe).
Let the LLM red-team your draft, not write it.
Here is a draft AI-usage policy for an IT service desk. Attack it:
1. List 10 realistic situations a support agent faces this week
that the policy does not clearly answer.
2. Find every rule that is unenforceable or unverifiable as written.
3. Find any rule an agent would rationally ignore under time
pressure, and say why.
Draft: [paste]
The gaps it finds — "can I paste an error message that contains a hostname?", "does a screenshot count as pasting?" — become the policy's FAQ section, which is the part people actually read.
Stand up the prompt registry in git or the wiki — somewhere with history. Structure by workflow, one file per prompt:
prompts/
triage/queue-triage-v3.md
comms/outage-notice-v2.md
comms/monthly-report-v2.md
kb/how-to-guide-v1.md
scripting/powershell-review-v4.md
Version in the filename or the git log — either, but pick one. A prompt library without history becomes a folder of near-duplicates within a quarter.
Give every prompt the same header. The header is what makes a prompt safe to hand to a new hire:
# Queue triage — v3
Owner: s.rao · Updated: 2026-08-06 · Works in: Copilot, Claude
Use for: daily unassigned-queue triage per pb-01
Data rules: redact user names before pasting (policy §2)
Known failures: over-prioritizes VIP keywords; forces REVIEW
on ambiguous rows — do not remove that instruction
Verify by: 10-ticket sampling audit, every run
---
[prompt text]
The known failures line is the institutional memory that individual prompt-hoarding never builds.
Seed the library from the track, then from the team. First commits: the working prompts from pb-01 (triage), pb-47 (outage comms and how-tos), pb-48 (reporting), and your scripting-review prompts. Then run a 30-minute team session: everyone contributes their best private prompt, each gets the header treatment and an owner. Contribution is the adoption mechanism — people use libraries they are in.
Wire in a lightweight change process. Edits via pull request or wiki-with-review: one other person reads a prompt change before it lands, because a prompt edit can silently change triage behavior desk-wide (that is also why versions matter — "misroutes doubled Tuesday" should be answerable with a diff). Major version bump = re-run the relevant quality check (the pb-01 audit, pb-48 verification) before the new version is blessed.
Launch both artifacts in one team meeting, then review quarterly. Walk the policy's FAQ cases live, demo pulling a prompt from the registry, and name the two owners (policy owner, library maintainer). Quarterly: retire dead prompts, promote new ones, and update the policy against whatever new tool leadership bought since.
The prompt library itself must stay clean — never commit prompts containing real user data, client names, credentials or internal hostnames as "examples"; a git history is forever, and a leaked registry should embarrass nobody.
One page of rules people can actually follow, one versioned library of prompts with owners and known-failure notes — the policy makes AI use safe to admit, the library makes it good, and together they convert scattered individual experiments into the desk's shared, improvable capability.