# Build your own capability map (and decks) — one paste Three clinical-research sites are each building an operations platform on the Claude Code CLI. This file lets **your** Claude Code build your site's capability map by reading **your** repo — no form to fill in. Optionally it also builds your own architecture + capabilities decks. The result drops straight onto the shared live comparison. Everything you need is in this one file. Nothing to download. Nothing proprietary leaves your machine except a tiny capability-level map (a handful of yes/building/no rows + short notes) that **you review before it's shared**. --- ## The fastest path (≈2 minutes) Open your platform repo in a terminal and run **one line**: ``` claude "Read the PROMPT I'm about to paste and do exactly what it says: build our capability map by scanning THIS repo, show it to me, then stop." ``` …then paste the **PROMPT** block below when it asks (or just paste the whole block to start). That's it — review what it produces, and submit it with the one command at the end. > Prefer to point Claude straight at the hosted copy? `claude "Read https:///BUILD.md and follow it"` — Aneesh will send the exact ``. Note: the kit URL must be an UN-GATED copy (a headless CLI can't pass the Access login wall), so pasting the PROMPT block is the default. --- ## PROMPT — paste this into your Claude Code, inside your repo > You are describing our clinical-research operations platform so three sites can compare what we've each built. Work only from evidence in THIS repo (code, configs, scheduled jobs, docs, READMEs). Don't invent capabilities; don't include any secrets, PHI, patient/sponsor/staff names, dollar figures, or study identifiers — **capability level only**. > > The 20 capabilities below are a **shared reference vocabulary** — a common set of words so three different platforms can be lined up side by side. They are **NOT a checklist you have to match**. Every site solves these differently, skips some that don't fit, and builds things that aren't on the list at all. That's expected and interesting — it's the whole point of comparing. **If you do something differently, say so in the note + data sources; if you've built something that isn't in this list, add it under `extras`.** Don't bend your reality to fit a row. > > **The shared vocabulary (20 capabilities, 6 groups):** > > *Getting patients in* > - `leads_autocollect` — Auto-collect leads from website + ads (web-form / ad-platform webhooks landing in a CRM) > - `eligibility_match` — Auto-check which studies a lead qualifies for (criteria/rules engine at intake) > - `recruiter_prioritize` — Tell recruiters who to call first + track response speed (call-back queue; speed-to-lead) > - `online_booking_reminders` — Online booking + automatic visit reminders (self-serve booking; SMS/email reminders) > - `winback` — Win back no-shows / cancellations / unfinished forms (re-engagement; partial-form rescue) > > *Running the day* > - `daily_visit_board` — One screen for the day's visits + what's missing (schedule view with readiness flags) > - `scheduling_guards` — Catch scheduling mistakes before they happen (double-book / wrong-site / wrong-time / same-patient-two-sites checks) > > *Handling the messages* > - `auto_patient_comms` — Automatic patient texts/emails with safety guardrails (DNC / throttle / dedup / quiet-hours) > - `inbound_triage` — AI reads + routes incoming faxes and voicemails (LLM classify + route) > - `ai_voice` — AI voice agent that pre-screens by phone (conversational voice agent) > > *Getting paid* > - `revenue_ar` — Track revenue / invoices / what's owed (per-study revenue, invoices, AR aging) > - `per_study_profit` — Profit per study after costs (revenue minus allocated cost; margin per study) > - `billing_writeback` — Auto-update the billing / finance system (write payment/invoice status back into the EDC or accounting system) > - `auto_collections` — Automatic collections / dunning (overdue-AR chase, ideally behind a reconciliation gate) > > *Safe & compliant* > - `rbac_phi` — Role-based access + patient-data protection (RBAC + PHI perimeter) > - `data_quality_audit` — Daily automatic data-quality checks + audit trail (scheduled cross-system audits + append-only log) > - `rule_checks` — Every important rule has an automatic test (rule-to-check coverage / lint tripwires) > > *Automation & platform* > - `assistant_agents` — Assistant agents that flag what needs attention (recommend-not-act, with a human approval step) > - `design_system` — One shared design system across all screens (component library used everywhere) > - `patient_provider_surfaces` — A patient website + a referring-doctor portal (public eligibility/booking site; provider portal) > > **For each capability, from the evidence in the repo, give:** > - `status` — `live` (built and running in production), `building` (partial, in progress, OR built but switched off behind a flag — say which in the note), or `none` (we don't have it). Judge from evidence, not optimism. > - `note` — ≤ 14 words: how we actually do it, or why it's absent. If your approach differs from the description above, this is where you say so. > - `dataSources` — the **external vendors / generic system categories** that feed this capability: your EDC, ad platforms, telephony, accounting system, e-sign, CRM, data warehouse, etc. Use vendor or category names (e.g. "Meta Ads", "EDC", "VoIP/telephony", "accounting system") — **NOT internal table, service, file, or function names**. Capability level only. For `none`, leave it `[]`. > - `useCases` — short phrases for what it's used for / who it's for (e.g. "recruiters triage callbacks", "finance AR review"). For `none`, leave it `[]`. > > **`extras` — anything you've built that ISN'T in the 20 above.** Add one entry per extra capability, same fields (`label`, `status`, `dataSources`, `useCases`, `note`). If there's nothing extra, use an empty array. Don't pad it — only real things in the repo. > > **Emit one file `.json`** in this shape — one entry per capability id, every id present exactly once, plus the `extras` array. **Use the slug your site is already listed under on the comparison so your column (and logo) fill in: West Clinical Research = `west`, ALSA Research = `alsa`.** (A new/unknown slug just creates a fresh unlabeled column.) > > ```json > { > "slug": "your-site-slug", > "site": "Your Site Name", > "generated": "YYYY-MM-DD", > "taxonomyVersion": "2.0", > "capabilities": { > "leads_autocollect": { > "status": "live", > "note": "Web forms + ad webhooks land directly in our CRM", > "dataSources": ["website forms", "Meta Ads", "Google Ads", "CRM"], > "useCases": ["intake capture", "recruiters work new leads"] > }, > "eligibility_match": { > "status": "building", > "note": "Rules engine at intake; criteria still being loaded per study", > "dataSources": ["EDC", "CRM"], > "useCases": ["auto-suggest studies for a new lead"] > }, > "recruiter_prioritize": { "status": "none", "note": "...", "dataSources": [], "useCases": [] } > // ... one entry for every remaining id, every id present exactly once > }, > "extras": [ > { > "label": "A capability we built that is NOT in the shared list", > "status": "live", > "dataSources": ["..."], > "useCases": ["..."], > "note": "<=14 words on what it is" > } > // ... or [] if you have no extras > ] > } > ``` > > Show me the file before saving, and flag any capability you weren't sure about so I can correct it. **You know our site better than the repo does — fix anything that's wrong.** --- ## Optional — build your own decks too If you'd like your own **architecture map** and **capabilities deck** (the same two views the others made), add this once your map is done: > Now build two self-contained single-file HTML decks for our site, capability-level only (no secrets/PHI/identifiers): > 1. `capabilities.html` — a short visual tour: a plain-English "what we built" opener (6 outcome groups: getting patients in, running the day, handling messages, getting paid, safe & compliant, not drowning in busywork), then one section per capability group from the shared vocabulary, marking each `live` / `building` / `none` from the map you just built, and a closing section for any `extras`. Self-contained, inline CSS, no external scripts. > 2. `architecture.html` — one diagram of how the platform is wired (lead sources → CRM/EDC → your dashboard → automations/agents → patient & provider surfaces), then a section per subsystem. Capability level; redact anything site-specific. Only draw subsystems your repo actually has — drop any box you can't point to in code; don't invent stages to fill the template. > Match a clean, modern look (system-font, card layout, a navy/blue/orange palette is fine). Keep each on one page. These are yours to keep — you don't have to share them. They just make your column easier to talk through. --- ## Submit your map (so it shows up live for all three) The comparison is **dynamic**: it reads every site's map live, so your column fills in **within seconds of submitting** and refreshes whenever you re-submit — no waiting on anyone. Until you submit, your column simply shows "not submitted yet." Pick whichever is easiest: - **One command (live, instant):** if Aneesh sent you a submit URL + key: ``` curl -sS -X POST "/submit" -H "x-kit-key: " -H "content-type: application/json" --data-binary @your-slug.json ``` Your column appears within seconds. Re-run it any time your map changes — it just updates. - **Or just send the file back:** reply to Aneesh's email with `your-slug.json` attached (it's tiny). He drops it in and it appears on the next load. Either way you stay in control — nothing publishes until you send it, and there's nothing in it but a handful of capability rows you've reviewed.