Skip to main content

Playbooks — the single home for operational how-tos + tools

Why this exists: repeatable operational work (onboard a clinic, white-label an app, debug a data issue, run a sales motion) kept getting re-figured-out by each agent every time. This is the ONE place those live, so nobody re-derives steps and Atlas can hand a playbook straight to a Ready Practice staff member to work a client.

Each playbook is steps + the tools it uses + who does it (🤖 agent-only · 👤 staff-delegatable · 🧑‍💻 needs George/engineering). Four domains:

DomainForIndex
OnboardingGet a new clinic (or white-label app) live end-to-endonboarding.md
Customer SupportRespond to a client with Atlas, within SLA, escalate correctlysupport.md
DebuggingDiagnose a production data/behavior issue safelydebugging.md
SalesRun a lead → demo → close motion (Atlas-assisted)sales.md

The rule (so this never rots)

When you work out a repeatable operational process, write or update its playbook HERE — steps, the exact tool/script paths + callables, and the who-does-it tag. Do NOT leave it in an agent's head or a one-off issue comment. If a tool exists, link it; if it doesn't, note the gap. Atlas reads these to guide staff, so keep them staff-legible (plain language, no undefined jargon).

Where the pieces live (so a playbook can point at them)

  • Reusable tools/scripts: basis-functions/tools/ (import/assign/ingest/backfill/audit/debug/verify), .github/scripts/ (board, ship, lints), hybrid/sh/ (builds, white-label flavor).
  • Deep technical references: docs/claude/*.md (the CLAUDE.md topic index — firebase-backend, labs, scheduling, insurance-rcm, debugging-tools, etc.).
  • Canonical runbooks: docs/claude/white-label-runbook.md, docs/handbook/engineering/*.
  • Test-as-staff pattern: callable-test-auth (custom token via appspot SA → idToken → call callables as staff) — see debugging.md.