debug-zoom — Claude command: triage a broken Zoom integration
Narrows a Zoom integration failure down to one layer: auth, webhooks, SDK behavior or RTMS.
~/.codex/prompts/debug-zoom.mdWhat debug-zoom does
Reach for this command when a Zoom integration is broken and the failing layer is still a guess. It starts by pinning the symptom: exact error text, failing endpoint, platform, runtime, and whether the failure is deterministic or intermittent. Then it reads the repo for the integration code, env usage, event handlers and SDK setup. It also records what still works, which is what lets you rule layers out.
Before touching anything, the command lays out a plan: the most likely failing layer, the evidence it will check first, the files and runtime paths involved, and whether the goal is diagnosis alone or diagnosis plus a minimal fix. From there it narrows to a single layer — auth, REST request construction, webhook verification, WebSocket lifecycle, SDK initialization or RTMS stream handling — and inspects the smallest relevant code path with its configuration.
A clear failure gets the minimum correction. An unclear one gets ranked hypotheses instead of broad speculation. One caveat worth knowing up front: if the report has no concrete error or failing path, the command asks for that evidence first rather than editing code on a hunch. Once a layer is confirmed, it routes to narrower commands such as /debug-zoom-auth or /debug-zoom-webhook, and to /plan-zoom-product or /plan-zoom-integration when the architecture itself is the problem.
What it helps with
- find which layer of a Zoom integration is failing
- separate an auth failure from a webhook problem
- check whether the SDK is at fault or the REST request
- get ranked hypotheses when the cause is still unclear
- record what works and what does not before editing
Example prompts for the agent
- triage this broken Zoom integration — here is the error text and endpoint
- the Zoom webhook fails intermittently, narrow it to one layer
- run debug-zoom on this repo, diagnosis only
How to install debug-zoom
Manually: put the files in place
~/.codex/prompts/debug-zoom.mdCall it with /prompts:debug-zoom. Codex marks this format deprecated in favour of skills
Manually: put the files in place
.claude/commands/debug-zoom.mdCall it with /debug-zoom. For all projects use ~/.claude/commands/
Manually: put the files in place
.github/prompts/debug-zoom.prompt.mdManually: put the files in place
.gemini/commands/debug-zoom.tomlGemini stores commands as TOML: the prompt text goes into the prompt field
Questions about debug-zoom
How do I install debug-zoom in Claude?
Place the command file at ~/.codex/prompts/debug-zoom.md.
What does debug-zoom do?
It triages a broken Zoom integration: captures the symptom, reads the relevant code and config, narrows the failure to one layer, then either applies a minimal fix or returns ranked hypotheses.
What does the command need to work?
A concrete symptom — error text, failing endpoint, platform and runtime. Without that evidence it asks for it first instead of changing code.
Source text
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
