build-zoom-apps-sdk-app — Claude command: apps inside Zoom
A slash command for Claude and Claude that scaffolds a Zoom Apps SDK app running inside the Zoom client.
~/.codex/prompts/build-zoom-apps-sdk-app.mdWhat build-zoom-apps-sdk-app does
Reach for this command when the repo should host an app inside the Zoom client instead of embedding Zoom into an external product. It first inspects the codebase: existing Zoom Apps SDK usage, the frontend framework, backend APIs, and how auth is handled. It also confirms the requirement is an in-client app and not a Meeting SDK or Video SDK workflow.
You then name the target running context — meeting, webinar, main client, phone, collaborate mode, immersive mode, or camera mode. The command lists the files it will touch, states the auth model and backend responsibilities, and describes how the app gets verified locally or in Zoom client testing. SDK initialization goes into the right frontend surface, and features are gated by running context rather than assumed to work everywhere.
Verification is stepwise: re-read the initialization and capability checks, run the local build or tests, then confirm the app load path and the first useful user action. Any remaining blocker is reported — allowlist gaps, missing Zoom client context, or a configuration mismatch. Marketplace settings, allowed domains, and redirect URIs have to line up with the implementation, or the app will not load in the client.
What it helps with
- build an app that runs inside the Zoom client
- pick the right running context instead of a Meeting SDK flow
- wire in-client OAuth with a matching callback path
- gate features by running context rather than global support
- keep domain allowlists aligned with app configuration
Example prompts for the agent
- build a Zoom Apps SDK app that runs inside the Zoom client
- check the SDK initialization and capability checks in this repo
- add the minimum backend for the first useful flow
How to install build-zoom-apps-sdk-app
Manually: put the files in place
~/.codex/prompts/build-zoom-apps-sdk-app.mdCall it with /prompts:build-zoom-apps-sdk-app. Codex marks this format deprecated in favour of skills
Manually: put the files in place
.claude/commands/build-zoom-apps-sdk-app.mdCall it with /build-zoom-apps-sdk-app. For all projects use ~/.claude/commands/
Manually: put the files in place
.github/prompts/build-zoom-apps-sdk-app.prompt.mdManually: put the files in place
.gemini/commands/build-zoom-apps-sdk-app.tomlGemini stores commands as TOML: the prompt text goes into the prompt field
Questions about build-zoom-apps-sdk-app
How do I install build-zoom-apps-sdk-app in Claude?
Place the prompt file at ~/.codex/prompts/build-zoom-apps-sdk-app.md, and the command becomes available in Claude.
What does build-zoom-apps-sdk-app do?
It implements a Zoom Apps SDK app that runs inside the Zoom client: SDK initialization, capability checks per running context, minimal backend wiring, and auth where the chosen workflow needs it.
How is it different from the Meeting SDK or Video SDK?
It targets an app inside the Zoom client. If the requirement is to run outside Zoom, the command points you to the appropriate meeting, video, or REST flow instead.
Source text
build-zoom-apps-sdk-app.md · MIT
--- description: Implement a Zoom Apps SDK app that runs inside the Zoom client with the right running context, auth path, and backend integration. --- # Build Zoom Apps SDK App Use this command when the repo should build an app that runs inside the Zoom client rather than embedding Zoom in an external app. ## Preflight 1. Inspect the codebase for existing Zoom Apps SDK usage, frontend framework, backend APIs, and auth handling. 2. Confirm the requirement is truly an in-client Zoom app and not a Meeting SDK or Video SDK workflow. 3. Identify the required running context: meeting, webinar, main client, phone, collaborate mode, immersive mode, camera mode, or another supported context. 4. Check for required Marketplace app settings, allowed domains, redirect URIs, and in-client OAuth requirements without printing secrets. ## Plan Before making changes: - state the target running context and user flow - list the files that will be changed - state the auth model, backend responsibilities, and any capability gating - state how the app will be verified locally or in Zoom client testing ## Commands 1. Add or correct Zoom Apps SDK initialization in the correct frontend surface. 2. Configure capability checks and gate features by running context instead of assuming global support. 3. Add the minimum backend or API wiring needed for the app’s first useful flow. 4. Wire in-client OAuth or supporting backend auth only where the chosen workflow requires it. 5. Keep domain allowlists, callback paths, and app configuration aligned with the implementation. 6. Avoid mixing external embed assumptions into an in-client Zoom app architecture. ## Verification 1. Re-read the client initialization, capability checks, and backend integration code after changes. 2. Run local build or tests where available. 3. Verify the app load path, running-context assumptions, and first useful user action. 4. State any remaining blocker such as allowlist gaps, missing Zoom client context, or app configuration mismatch. ## Summary ```text ## Result - Action: implemented or updated a Zoom Apps SDK app - Status: success | partial | failed - Details: running context, files changed, auth path, verification run ``` ## Next Steps - Test the app inside the intended Zoom client context. - Add advanced client capabilities only after the base app loads reliably. - If the requirement is to run outside Zoom client, switch to the appropriate meeting, video, or REST flow.
© Zoom · MIT · openai/plugins