sachinndhimann

Clinic AI Receptionist — Data skill for Claude Code

Data community

WhatsApp AI receptionist for clinics — FastAPI + Postgres/pgvector + Claude.

How to install Clinic AI Receptionist

This entry records only its repository, not the path inside it, so there is no exact command to give. Open sachinndhimann/clinic-ai-receptionist and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Clinic AI Receptionist does

WhatsApp AI receptionist for clinics — FastAPI + Postgres/pgvector + Claude. Answers FAQs via RAG, books appointments through a multi-turn agentic flow, and escalates emergencies/complaints to human staff. Multi-tenant SaaS architecture, starting with the dental/hospital vertical.

Alternatives in Data

Private GPT — Complete API layer for private AI applications on local models: RAG, skills, tools, MCP, text-to-sql, and more 57.5k ★
OpenViking — Self-evolving Context Database for AI Agents 33.3k ★
Book Translation Skill — You are a book translation assistant 489 ★

README

Clinic AI Receptionist

WhatsApp-based AI receptionist for clinics: FAQ answering (RAG), appointment booking (agentic tool-calling), and safe escalation to human staff.

Architecture

WhatsApp --> webhooks/whatsapp.py
               |
               |-- conversation lookup (state/conversation.py)
               |-- escalated? --> stop, staff handles it
               |-- emergency keyword filter (core/emergency_filter.py) --> escalate immediately
               |-- mid-booking-flow? --> state/flow_state.py narrow handler
               |-- else: intent_router.py --> FAQ | BOOKING | COMPLAINT | UNCLEAR
               |
               |-- FAQ --> rag/retrieve.py (pgvector) --> core/agent.py (grounded answer)
               |-- BOOKING --> core/agent.py (tool-calling loop) --> tools/booking.py
               |-- COMPLAINT/UNCLEAR --> tools/escalation.py

Key design decisions

pgvector, not a standalone vector DB — one Postgres instance serves both structured data (appointments, conversations) and RAG embeddings. Simpler ops for a multi-tenant SaaS at this scale.
Tools, never freehand writes — the LLM can only change state (book, cancel, escalate) through typed functions in tools/, each of which re-validates against the DB before committing.
Structured flow state, not chat-history replay — multi-turn booking uses booking_flow_state (slot-filling) instead of re-feeding growing transcripts to the LLM. Flat token cost, no drift on remembered details.
Two-layer emergency detection — a deterministic keyword filter runs before any LLM call; the system prompt carries a backstop instruction for phrasing the filter misses. Life-safety checks should not depend solely on probabilistic model behavior.
Escalation is a hard stop — once conversation.status == "escalated", the webhook handler skips the agent entirely until a staff member explicitly resolves it. No parallel bot/human replies.
**Multi-tenant via