Tamora — User Guide

How to run a live event with Tamora. These pages describe what the product does today, including the rough edges — if something is half-built or works differently than you'd expect, it says so rather than leaving you to find out during a show.

For installation, deployment, and local development, see the project README instead. This guide is for the people running events.

Start here

The five surfaces

Tamora shows the same room through several purpose-built screens. One person drives; everyone else gets a read-only or narrowly-scoped view.

The Controller is a desktop console and is not designed for phones. Use the Moderator screen on a phone or tablet, and the Operator console on a second laptop.

Before your first show

1. Create a room and set its timezone — Controller.
2. Build your rundown, by hand or from a spreadsheet — CSV import.
3. Create the share links you need and test each one on the device that will use it — Share links.
4. Read Things that will catch you out below.

Things that will catch you out

Every one of these is current, real behaviour. They are the most common surprises, collected in one place so you meet them here rather than mid-show.

• The skip buttons reset the clock. ⏮ and ⏭, and clicking any session in the list, stop playback and zero the elapsed time for the session you land on. Skipping forward and back does not restore the time already run.
• Time nudges are ±30 seconds, and do nothing while stopped. There is no ±1 minute button.
• Durations must be mm:ss or plain seconds. 90:00 is ninety minutes. 1:30:00 is silently misread — do not use h:mm:ss anywhere.
• Only one message shows at a time. Showing a message hides the previous one.
• Blackout hides live messages too, not just the timer.
• Breaks do not appear on the public Agenda, but they still consume time — so delegates see gaps between start times.
• Share links never expire and cannot be time-limited from the app. Remove them when the event is over.
• The Viewer team role is not read-only. Do not use it to grant safe access — see Team management.
• Team invites are not emailed. As shipped, an invite cannot be delivered from the app at all — see Team management.
• Deleting a room archives it, and there is no way to restore it yourself.
• Loading a saved show into an existing room replaces its entire rundown. It does not add to it, the way CSV import does — see Saved shows.
• An agent access token is shown once and must never go in a chat message. Copy it the moment you create or rotate one — there is no way to see it again after that. It belongs in a script or automation's own credential store, or in Claude's connector authentication field — see Agent access and Connect Claude via MCP.

Getting help

If something here does not match what you see on screen, the docs are wrong — please open an issue.

A CI check (docs-drift.yml) requires the relevant page to be updated whenever a change lands in the code that surface is built from, which should keep the two close. It is not a guarantee: it watches each surface's own route directory plus a few shared modules the pages quote directly, so a change somewhere less obvious can still leave a page behind. The rules it enforces are in scripts/docs-drift.ts, and the surfaces deliberately left out are listed there.