Zoom Rtms
Run a five-minute RTMS preflight so backend ingestion, webhooks, lifecycle gating, and stream IDs match Zoom’s backend-first model before you debug media pipelines.
Overview
Zoom-rtms is an agent skill most often used in Build (also Ship, Operate) that runs a 5-minute RTMS preflight on backend architecture, lifecycle events, IDs, and webhooks before deep media debugging.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill zoom-rtmsWhat is this skill?
- RTMS 5-minute preflight runbook structured as numbered checks before deep debugging
- Enforces backend-first ingestion with optional frontend consuming WebSocket or SSE outputs
- Lifecycle gating: processing starts only after meeting/webinar/session rtms_started and stops on stop events
- Product ID matrix: meeting_uuid for meetings/webinars, session_id for Video SDK, plus rtms_stream_id context
- Webhook pattern: immediate 200 response, async work, signature verification, heartbeat and single active connection per
- RTMS 5-minute preflight runbook with 5 numbered confirmation sections in the documented flow
Adoption & trust: 831 installs on skills.sh; 19.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your RTMS pipeline drops streams or double-connects because architecture, lifecycle gating, or webhook handling was wrong before you ever inspected media bytes.
Who is it for?
Indie backends adding RTMS to meetings, webinars, or Video SDK sessions with a short checklist before implementation or incident response.
Skip if: Projects planning frontend-only RTMS without a server ingest path or teams skipping webhook signature and heartbeat requirements.
When should I use this skill?
Before deep RTMS debugging or new pipeline work—confirm backend-first design, lifecycle start/stop events, product IDs, webhooks, and heartbeat connections.
What do I get? / Deliverables
You validate backend-first RTMS assumptions, correct IDs, and async webhook handling so ingestion starts only after rtms_started and stays stable under retries.
- Preflight pass/fail notes per runbook section
- Corrected architecture sketch if frontend-only RTMS was assumed
- Webhook and connection handling checklist for implementation
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Build integrations is the canonical shelf because RTMS setup is implemented as backend webhooks, async workers, and connection handling—not optional frontend magic. Integrations fits Zoom RTMS handshake, product-specific IDs, and webhook contracts that must be correct before any UI consumes streams.
Where it fits
Confirm RTMS lifecycle handlers and ID fields before writing the first media worker.
Design token and webhook routes that return 200 immediately and verify signatures async.
Preflight stream gating and heartbeat handling before exposing RTMS to beta users.
Re-run the checklist when duplicate stream attempts appear after webhook retries.
How it compares
Operational runbook for Zoom RTMS wiring, not a general video AI model skill or Meeting SDK UI guide.
Common Questions / FAQ
Who is zoom-rtms for?
Backend-focused solo builders and small teams using agents to implement or debug Zoom RTMS ingestion alongside optional stream consumers.
When should I use zoom-rtms?
Use it in Build when scaffolding RTMS workers, in Ship before launch to verify webhooks and gating, and in Operate when streams fail or duplicate after Zoom retries.
Is zoom-rtms safe to install?
It references webhook secrets and live media paths; review Prism Security Audits and your Zoom app credentials policy before enabling in production.
SKILL.md
READMESKILL.md - Zoom Rtms
# RTMS 5-Minute Preflight Runbook Use this before deep debugging. It catches the highest-frequency RTMS issues fast. ## Skill Doc Standard Note - Agent-skill standard entrypoint is `SKILL.md`. - This runbook is an operational convention (recommended), not a required skill file. - `SKILL.md` is also a navigation convention for larger skill docs. ## 1) Confirm Architecture Assumption - RTMS is backend-first media ingestion. - Frontend is optional and should consume backend outputs (WebSocket/SSE/etc). If implementation assumes frontend-only RTMS behavior, redesign first. ## 2) Confirm Event-Triggered Kickoff - Processing starts only after RTMS lifecycle start events: - `meeting.rtms_started` - `webinar.rtms_started` - `session.rtms_started` - Stop events should deactivate pipeline. If media handling starts before lifecycle start, session gating is wrong. ## 3) Confirm Product-Specific IDs - Meetings/Webinars: use `meeting_uuid` - Video SDK: use `session_id` - Use `rtms_stream_id` from payload for stream context Using wrong ID field commonly breaks handshake/signature. ## 4) Confirm Webhook Handling Pattern - Respond `200` immediately. - Do heavy work asynchronously. - Verify webhook signature if secret token is configured. Slow webhook responses can trigger retries and duplicate stream attempts. ## 5) Confirm Connection and Heartbeat - Track one active connection per stream/session reference. - Handle heartbeat ping/pong per protocol. - Implement reconnection strategy explicitly. No heartbeat handling means unexpected disconnects. ## 6) Confirm Media Subscription/Gating - Ensure requested media types match your processing path. - Reject/ignore media packets for inactive sessions. - Expose pipeline status endpoint for observability. This avoids silent packet handling when lifecycle is not active. ## 7) Quick Probe Checklist - `GET /api/health` returns service alive. - `GET /api/pipeline/status` shows expected active session count. - Mock/media probes show: - media before start -> rejected - start event -> pipeline active - media after start -> accepted ### Copy/Paste Validation Commands ```bash curl -sS "$RTMS_BASE_URL/api/health" curl -sS "$RTMS_BASE_URL/api/pipeline/status" ``` Expected: healthy service JSON and correct active pipeline visibility. ## 8) Fast Decision Tree - **No media at all** -> lifecycle event not received or wrong webhook route. - **Duplicate streams** -> delayed webhook response or no active-session guard. - **Handshake/auth errors** -> wrong credential pair or wrong session ID field. - **Frontend appears idle** -> backend bridge not connected, not an RTMS source issue. --- name: zoom-rtms description: Reference skill for Zoom RTMS. Use after routing to a live-media workflow when processing real-time audio, video, chat, transcripts, screen share, or contact-center voice streams. user-invocable: false triggers: - "real-time media" - "rtms" - "live audio stream" - "live video stream" - "meeting transcription" - "raw audio" - "raw video" - "websocket media" - "live transcript" - "streaming audio" - "streaming video" - "meeting bot media" - "contact center voice media" - "participant video on" - "participant video off" - "single individual video stream" --- # Zoom Realtime Media Streams (RTMS) Background reference for live Zoom media pipelines. Prefer `build-zoom-bot` first, then use this skill for stream types, capabilities, and RTMS-specific implementation constraints. # Zoom Realtime Media Streams (RTMS) Expert guidance for accessing live audio, video, transcript, chat, and screen share data from Zoom meetings, webinars, Video SDK sessions, and Zoom Contact Center Voice in real-time. RTMS uses a WebSocket-based protocol with open standards and does not require a meeting bot to capture the media plane. ## Read This First (Critical) RTMS is primarily a **backend media ingestion service**. - Your backend receives and processes live