plan-zoom-product — команда для Codex: что делает и как установить
Выбирает подходящий SDK или API Zoom под задачу проекта до написания кода и объясняет компромиссы альтернативных решений.
~/.codex/prompts/plan-zoom-product.mdЧто делает plan-zoom-product
Команда проверяет репозиторий через rg на следы старых интеграций, пакетов SDK или обработчиков вебхуков. Затем она сопоставляет задачу с подходящим вариантом: REST API, Video SDK, Zoom Apps SDK или вебхуки. Это отсекает лишние библиотеки.
Агент выбирает одну базовую поверхность и нужную ей схему авторизации. Без чётких ограничений по модели аккаунтов и задержкам рекомендация останется неполной. Если задача затрагивает сразу несколько продуктов платформы, команда предлагает переключиться на /plan-zoom-integration.
Какие задачи решает
- выбрать между Meeting SDK и Video SDK для интеграции видео
- определить минимальный набор API и событий вебхуков Zoom
- выявить скрытые ограничения по модели авторизации и задержкам
- проверить существующий код проекта на конфликтующие SDK Zoom
Примеры запросов агенту
- Помоги выбрать между Meeting SDK и Video SDK для звонков внутри нашего сервиса
- /plan-zoom-product: проверь репозиторий и подбери API Zoom для синхронизации расписания
- Определи, какой инструмент Zoom лучше взять для чат-бота: REST API или вебхуки
Как установить plan-zoom-product
Вручную: положить файлы
~/.codex/prompts/plan-zoom-product.mdВызов — /prompts:plan-zoom-product. В Codex этот формат помечен устаревшим, замена — скиллы
Вручную: положить файлы
.claude/commands/plan-zoom-product.mdВызов — /plan-zoom-product. Для всех проектов — ~/.claude/commands/
Вручную: положить файлы
.github/prompts/plan-zoom-product.prompt.mdВручную: положить файлы
.gemini/commands/plan-zoom-product.tomlGemini хранит команды в TOML: текст запроса — в поле prompt
Вопросы о plan-zoom-product
Как установить plan-zoom-product в Codex?
Добавьте файл команды по пути ~/.codex/prompts/plan-zoom-product.md. После этого вызов станет доступен в сессиях Codex.
Что делает команда plan-zoom-product?
Она сканирует проект утилитой rg, сопоставляет требования к продукту с возможностями Zoom и рекомендует один основной SDK или API. Заодно команда объясняет, почему альтернативные поверхности хуже решают эту задачу.
Что делать, если продукту нужно несколько поверхностей Zoom одновременно?
Команда зафиксирует статус частичного выбора и предложит запустить /plan-zoom-integration для проектирования составной архитектуры.
Исходный текст
plan-zoom-product.md · MIT
--- description: Choose the right Zoom product surface for a use case and explain the tradeoffs clearly. --- # Plan Zoom Product Use this command when the repo or product idea needs the right Zoom surface selected before implementation begins. ## Preflight 1. Inspect the repository for any existing Zoom integration code, SDK packages, API routes, or webhooks. 2. Capture the user goal in concrete terms: automation, embedded meetings, custom video, in-client app behavior, event delivery, live media, or AI tooling. 3. Identify hard constraints that affect product choice: target platform, required UX, hosting model, latency, account model, and whether the app runs inside or outside Zoom. 4. If the repo already uses one Zoom surface, note it before recommending a different one. ## Plan Before recommending anything: - list the candidate Zoom surfaces that fit the problem - state the primary decision criteria - state whether the output is read-only guidance or includes follow-on implementation - state which path will be recommended unless the repo evidence contradicts it ## Commands 1. Inventory existing Zoom-related code with `rg` over known Zoom SDK names, API clients, and webhook handlers. 2. Classify the problem into the smallest correct Zoom surface: REST API, Webhooks, WebSockets, Meeting SDK, Video SDK, Zoom Apps SDK, RTMS, Phone, Contact Center, Virtual Agent, or a hybrid. 3. Recommend one primary surface and only the minimum supporting pieces required. 4. Explain why adjacent alternatives are worse for this exact case. 5. Keep the answer tied to the current repo and delivery goal rather than giving a generic product catalog. ## Verification 1. Confirm the recommendation matches the user’s actual product goal and the repo’s current shape. 2. Call out any missing evidence or assumptions that could change the decision. 3. Verify the recommendation includes the owning auth model and any mandatory supporting components. ## Summary ```text ## Result - Action: selected the right Zoom product surface - Status: success | partial | failed - Details: recommended surface, supporting pieces, tradeoffs, assumptions ``` ## Next Steps - If the surface is chosen, run the matching build or setup command next. - If the product still spans multiple Zoom surfaces, run `/plan-zoom-integration`. - If the decision depends on missing constraints, gather those before implementing.
© Zoom · MIT · openai/plugins