debug-zoom — команда для Codex: разбор поломок интеграции с Zoom
Помогает сузить сбой в интеграции с Zoom до конкретного слоя: авторизация, вебхуки, SDK или RTMS.
~/.codex/prompts/debug-zoom.mdЧто делает debug-zoom
Команда включается, когда что-то в интеграции с Zoom сломалось, но непонятно, где именно. Сначала она просит точный симптом: текст ошибки, падающий эндпоинт, платформа, рантайм и повторяется ли сбой стабильно или плавает. Затем смотрит в репозиторий — код интеграции, переменные окружения, обработчики событий, настройку SDK. Отдельно фиксируется, что ещё работает: так проще отсечь здоровые слои.
Дальше команда описывает план до правок: какой слой считает вероятным виновником, какие доказательства проверит первыми, какие файлы и пути рантайма задействованы, нужна ли только диагностика или ещё минимальное исправление. Потом сужает проблему до одного слоя — авторизация, сборка REST-запроса, проверка вебхука, жизненный цикл WebSocket, инициализация SDK или обработка потока RTMS — и смотрит самый короткий релевантный участок кода вместе с конфигурацией.
Если причина ясна, вносится минимальная правка. Если нет — выдаются гипотезы по приоритету вместо общих рассуждений. Есть оговорка: без конкретной ошибки или падающего пути команда сначала запросит эти данные, а не начнёт менять код наугад. По подтверждённому слою она направляет в узкие команды вроде /debug-zoom-auth или /debug-zoom-webhook, а при неверной архитектуре — в /plan-zoom-product или /plan-zoom-integration.
Какие задачи решает
- понять, на каком слое ломается интеграция с Zoom
- отделить сбой авторизации от проблем с вебхуками
- проверить, что дело в SDK, а не в REST-запросах
- получить список гипотез, когда причина ещё не ясна
- зафиксировать, что работает, а что нет, до правок
Примеры запросов агенту
- разберись, почему падает интеграция с Zoom: вот текст ошибки и эндпоинт
- сбой в вебхуке Zoom плавающий, сузь до конкретного слоя
- прогони debug-zoom по этому репозиторию, диагностика без правок
Как установить debug-zoom
Вручную: положить файлы
~/.codex/prompts/debug-zoom.mdВызов — /prompts:debug-zoom. В Codex этот формат помечен устаревшим, замена — скиллы
Вручную: положить файлы
.claude/commands/debug-zoom.mdВызов — /debug-zoom. Для всех проектов — ~/.claude/commands/
Вручную: положить файлы
.github/prompts/debug-zoom.prompt.mdВручную: положить файлы
.gemini/commands/debug-zoom.tomlGemini хранит команды в TOML: текст запроса — в поле prompt
Из того же набора304
Весь набор →Похожие
Рядом в теме «Настройка агента: память, контекст, субагенты»
Все слэш-команды по теме «Настройка агента: память, контекст, субагенты» →Вопросы о debug-zoom
Как установить debug-zoom в Claude?
Положите файл команды по пути ~/.codex/prompts/debug-zoom.md.
Что делает debug-zoom?
Проводит разбор сломанной интеграции с Zoom: собирает симптом, смотрит код и конфигурацию, сужает сбой до одного слоя и либо вносит минимальную правку, либо выдаёт гипотезы по приоритету.
Что нужно, чтобы команда сработала?
Конкретный симптом: текст ошибки, падающий эндпоинт, платформа и рантайм. Без этих данных команда сначала запросит доказательства, а не станет менять код.
Исходный текст
debug-zoom.md · MIT
--- description: Triage a broken Zoom integration when the failing layer is not yet obvious. --- # Debug Zoom Use this command when something in a Zoom integration is broken but the failure has not yet been narrowed to auth, webhooks, SDK behavior, or RTMS. ## Preflight 1. Capture the exact symptom: error text, failing endpoint, platform, runtime, and whether the failure is deterministic or intermittent. 2. Inspect the repository for the relevant Zoom integration code, env usage, event handlers, or SDK setup. 3. Note what still works versus what fails so the broken layer can be isolated. 4. If the report lacks the concrete error or failing path, ask for that evidence before making speculative changes. ## Plan Before changing anything: - state the most likely failing layer - list the evidence that will be checked first - list the repo files or runtime paths involved - state whether the goal is diagnosis only or diagnosis plus a minimal fix ## Commands 1. Inventory the active Zoom surfaces in the failing workflow. 2. Narrow the problem to one layer: auth, REST request construction, webhook verification, WebSocket lifecycle, SDK initialization, or RTMS stream handling. 3. Inspect the smallest relevant code path and supporting configuration first. 4. Apply the minimum correction needed if the failure is clear. 5. If the layer cannot be fixed yet, produce ranked hypotheses instead of broad speculation. 6. Route to narrower follow-up commands when appropriate, such as `/debug-zoom-auth` or `/debug-zoom-webhook`. ## Verification 1. Re-run or reconstruct the failing path after any fix. 2. Confirm the diagnosis is tied to concrete repo evidence or exact runtime behavior. 3. State whether the issue is fixed, partially fixed, or blocked by missing credentials, account setup, or external platform behavior. ## Summary ```text ## Result - Action: triaged a broken Zoom integration - Status: success | partial | failed - Details: failing layer, evidence checked, fix applied or ranked hypotheses ``` ## Next Steps - Use the narrower debug or setup command for the confirmed failing layer. - If the architecture itself is wrong, run `/plan-zoom-product` or `/plan-zoom-integration`. - If the repo is healthy but the client integration path is wrong, switch to the matching build command.
© Zoom · MIT · openai/plugins
