Department & care

Building the department's scheduling tool

A shared schedule on a single web page: template week, one tab per activity, month view, sync for the whole team, published online. Built with Claude, step by step.

Claude CodeCoworkGitHub2 to 3 sessions, then one version a month

Building the schedule in dialogue: conversation, version preview, counters per person.
Building the schedule in dialogue: conversation, version preview, counters per person.

Screenshot of a real tool · fictitious data, names blurred

Architecture of the scheduling tool

Figure. A single file, one tab per activity, a shared database, and a versioned publishing chain.

The problem

The schedule of a cardiology department involves dozens of staff (senior physicians, clinical fellows, junior doctors, residents) and very different activities: echocardiography by room, clinics, exercise testing, MRI, on-call duty, staff meetings, teaching. It often lives in a spreadsheet that only one person knows how to edit, and every absence sets off a chain of emails.

Step-by-step method

  1. Write the specification before the code: the list of staff (with their category), the activities, the half-days, who may edit what. Claude drafts it from your notes and the existing spreadsheet, and lists the ambiguities to be resolved.
  2. A template week, then real weeks: a “Global” tab describes everyone’s standard week; the real weeks are derived from it and never modify the template.
  3. Recurring attendance by week parity: an attendance can recur on even or odd weeks only, between a start date and an end date. The real weeks compute it; it is never copied by hand.
  4. One tab per activity: Echocardiography (by room and half-day), Clinic, Exercise testing, MRI, On-call, Staff meetings, Faculty, Absences, and a month view showing everyone. When a cell is full, an “also present” row shows those beyond its capacity: without it, names disappeared without warning.
  5. A single HTML file, with no server to maintain: Claude builds it, you open it in the browser to test it.
  6. A shared database so that the whole team sees the same data in real time, protected by a team password. The file must never contain a frozen copy of the data: a new computer would display an outdated state without warning. A red “not connected” banner flags a computer that is not seeing the real data. When two people edit at the same time, the changes are merged by identity (who is assigned), never by position in the list: otherwise one wipes out the other.
  7. Apply rules through versioned migrations: each rule change (new recurring attendance, renamed activity) is a numbered migration, applied only once, and only after the first successful sync with the database. Applied too early, it would write onto empty data or be overwritten.
  8. Publish online: the file lives in a GitHub repository. Every change goes through a branch, then a pull request that the person in charge merges themselves; a static host then publishes the main branch automatically. Two test suites (data logic, gestures in the browser) pass before any merge.
  9. Version it: each release carries a number (v38, v39…) visible in the page title; the old version is archived, never overwritten.
  10. Turn it into a skill: all the lessons learned (bugs, procedure, checks) are condensed into a “planning” orchestrator skill, so they need not be relearned in every conversation.

Deliverable

An online scheduling tool, shared and versioned, and a skill that knows how to diagnose it, fix it and deliver it.

Safeguards

  • The production schedule is never modified directly by the AI: it prepares a branch and a pull request, you merge. Nothing is published without approval, and fixes are bundled into a single version.
  • No patient data in the schedule. Staff contact details stay in the directory, not in the published file.
  • The team password appears neither in shared conversations nor in circulated documents.
  • Deployed does not mean tested: no link is given without having been opened; otherwise it is marked “not verified”.
  • The schedule never feeds anyone’s personal calendar: they are two separate sources.

Starter prompt

Here is our scheduling spreadsheet and the list of staff. Write the specification for a single-web-page scheduling tool: template week, one tab per activity, month view, absences. List what is ambiguous before coding anything.

← Back to the triptych