# Query Routing Playbook (zoom-general) Use `zoom-general` as the routing/orchestration layer. Do not implement product-specific logic in `zoom-general` if a specialized skill exists. ## Goal Convert a complex developer query into: - `selected_skills` - `execution_order` - `assumptions` - `next_actions` ## Routing rules | Query signal | Route to skill | Why | |---|---|---| | OAuth, scopes, S2S, token strategy | `zoom-oauth` | Authentication and authorization design | | Meetings/users/recordings/reports API operations | `zoom-rest-api` | Server-side Zoom resource management | | Embed full Zoom meetings/webinars | `zoom-meeting-sdk` | Meeting runtime integration | | Build custom video session experience | `zoom-video-sdk` | Custom media UX runtime | | Receive event callbacks via HTTP | `zoom-webhooks` | Event lifecycle notifications | | Need lower-latency event stream | `zoom-websockets` | Persistent real-time event transport | | Live audio/video/transcript stream ingestion | `zoom-rtms` | Real-time media and transcript pipeline | | App runs inside Zoom client | `zoom-apps-sdk` | In-client app model and APIs | ## Sequencing 1. Start with `zoom-general` (triage and architecture). 2. Add `zoom-oauth` if any protected resource access is required. 3. Select one primary runtime/API skill (`zoom-meeting-sdk`, `zoom-video-sdk`, or `zoom-rest-api`). 4. Add event/media skills (`zoom-webhooks`, `zoom-websockets`, `zoom-rtms`) based on requirements. 5. Keep the chain minimal; do not add extra skills without explicit need. ## Handoff contract ```json { "selected_skills": [ "zoom-general", "zoom-oauth", "zoom-meeting-sdk", "zoom-webhooks" ], "execution_order": [ "zoom-general", "zoom-oauth", "zoom-meeting-sdk", "zoom-webhooks" ], "assumptions": [ "embedded meeting experience required", "server-side event endpoint available" ], "next_actions": [ "confirm OAuth scopes", "implement auth/token flow", "implement runtime integration", "implement event consumer and verification" ] } ``` ## Ambiguity handling If confidence is low, ask one focused question before final routing: - “Do you need embedded Zoom meetings, or a fully custom video session UI?” - “Is webhook latency acceptable, or do you require persistent low-latency events?” ## Example route Query: “Build a Linux bot that joins meetings, auto-creates meetings, streams transcript, and tracks lifecycle events.” Recommended chain: - `zoom-general` - `zoom-oauth` - `zoom-rest-api` - `zoom-meeting-sdk` - `zoom-rtms` - `zoom-webhooks` Why: - `zoom-rest-api` for meeting provisioning - `zoom-meeting-sdk` for runtime join/control - `zoom-rtms` for live transcript/media stream - `zoom-webhooks` for lifecycle notifications