build-zoom-rivet-app — команда для Codex: Zoom-интеграция на Rivet
Слэш-команда для Codex и ChatGPT, которая разворачивает серверную интеграцию Zoom на Rivet SDK: OAuth, API-клиенты, вебхуки и модульная сборка.
~/.codex/prompts/build-zoom-rivet-app.mdЧто делает build-zoom-rivet-app
Команда включается, когда в репозитории нужна серверная интеграция Zoom через Rivet SDK, а не самописная обвязка для API и вебхуков. Сначала она проходит префлайт: смотрит, есть ли уже следы Rivet, точки входа сервера, обработка OAuth, приёмники вебхуков и конфигурация деплоя. Отдельно проверяет, что Rivet — действительно нужная абстракция, а не лишний слой поверх прямых вызовов REST.
Дальше команда планирует работу: называет сценарий Rivet, перечисляет файлы под правку, описывает путь авторизации, путь вебхука и стратегию сборки модулей. Только после этого идёт реализация — сначала минимальный авторизованный путь API и один приёмник вебхуков, потом уже более широкая многомодульная логика. Обработку переменных окружения и допущения по деплою команда держит явными, особенно для Lambda-подобных и serverless-приёмников, и старается переиспользовать существующие в репозитории шаблоны конфига, логирования и работы с секретами.
В конце — верификация: перечитать код модулей, авторизации и вебхуков, прогнать локальную сборку или тесты, проверить связку модулей и первый рабочий поток. Если чего-то не хватает — например, учётных данных приложения Zoom — команда прямо скажет об этом в блоке с оставшимися блокерами. Там же она назовёт расхождение с фреймворком или несоответствие модели деплоя. Если Rivet добавляет больше сложности, чем пользы, команда сама предлагает откатиться на прямой REST плюс вебхуки.
Какие задачи решает
- развернуть серверную интеграцию Zoom на Rivet SDK вместо ручной обвязки
- проверить, есть ли в репозитории уже готовые точки входа, OAuth и приёмники вебхуков
- собрать модульную структуру: конфиг приложения, OAuth, API-клиенты, обработчики вебхуков
- поднять минимальный авторизованный путь API и один вебхук до расширения логики
- зафиксировать допущения по деплою для serverless-приёмников и не засветить секреты
Примеры запросов агенту
- собери серверную интеграцию Zoom на Rivet SDK в этом репозитории
- проверь, что Rivet тут уместен, и опиши план модулей, авторизации и вебхуков
- добавь минимальный авторизованный путь API и приёмник вебхука Zoom
Как установить build-zoom-rivet-app
Вручную: положить файлы
~/.codex/prompts/build-zoom-rivet-app.mdВызов — /prompts:build-zoom-rivet-app. В Codex этот формат помечен устаревшим, замена — скиллы
Вручную: положить файлы
.claude/commands/build-zoom-rivet-app.mdВызов — /build-zoom-rivet-app. Для всех проектов — ~/.claude/commands/
Вручную: положить файлы
.github/prompts/build-zoom-rivet-app.prompt.mdВручную: положить файлы
.gemini/commands/build-zoom-rivet-app.tomlGemini хранит команды в TOML: текст запроса — в поле prompt
Из того же набора304
Весь набор →Похожие
Рядом в теме «Бэкенд и API»
Все слэш-команды по теме «Бэкенд и API» →Вопросы о build-zoom-rivet-app
Как установить build-zoom-rivet-app в Claude?
Положите файл команды по пути ~/.codex/prompts/build-zoom-rivet-app.md — после этого она доступна в Claude.
Что делает build-zoom-rivet-app?
Разворачивает серверную интеграцию Zoom вокруг Rivet SDK: модули конфигурации, OAuth, API-клиенты, обработчики вебхуков и бизнес-логику. Сначала префлайт и план, потом минимальный рабочий путь и проверка.
Что нужно для работы команды?
Учётные данные приложения Zoom и понятная модель деплоя — команда проверяет их наличие, не выводя секреты. Если Rivet окажется лишним слоем, она предложит вернуться к прямому REST и вебхукам.
Исходный текст
build-zoom-rivet-app.md · MIT
--- description: Implement a server-side Zoom integration with Rivet modules for auth, APIs, webhooks, and deployment-safe composition. --- # Build Zoom Rivet App Use this command when the repo should build a server-side Zoom integration around the Rivet SDK instead of hand-rolled API and webhook plumbing. ## Preflight 1. Inspect the codebase for existing Rivet usage, server entry points, OAuth handling, webhook receivers, and deployment configuration. 2. Confirm Rivet is the intended abstraction and not just a generic backend integration that should stay with direct API and webhook code. 3. Identify the required modules: app configuration, OAuth, API clients, webhook handlers, and business workflow handlers. 4. Check whether the required environment variables and deployment model are already represented without printing secrets. ## Plan Before making changes: - state the Rivet workflow being implemented - list the files that will be changed - state the auth path, webhook path, and module composition strategy - state how the first working Rivet path will be verified ## Commands 1. Add or correct the Rivet-based module structure at the correct server layer. 2. Implement the smallest authenticated API path and webhook receiver before composing broader multi-module behavior. 3. Keep environment handling and deployment assumptions explicit, especially for Lambda-style or serverless receivers. 4. Reuse existing repo patterns for config, logging, and secret management where possible. 5. Avoid wrapping Rivet in unnecessary abstractions that make the auth and webhook paths harder to reason about. ## Verification 1. Re-read the Rivet module setup, auth handling, and webhook integration code after changes. 2. Run local build or tests where available. 3. Verify the module wiring, auth path, and first useful API or webhook flow. 4. State any remaining blocker such as framework drift, deployment mismatch, or missing app credentials. ## Summary ```text ## Result - Action: implemented or updated a Zoom Rivet integration - Status: success | partial | failed - Details: files changed, module setup, auth path, verification run ``` ## Next Steps - Exercise one real authenticated API path and one webhook flow. - Expand to multi-module workflows only after the base path works. - If Rivet is adding more complexity than value, fall back to direct REST plus webhook implementation.
© Zoom · MIT · openai/plugins