plan-zoom-product — Codex command: what it does, how to install
Selects the appropriate Zoom SDK or API surface for your project goals and explains tradeoffs before coding starts.
~/.codex/prompts/plan-zoom-product.mdWhat plan-zoom-product does
The command scans the repository using rg to find existing Zoom SDK packages or webhook handlers. It then maps project requirements to specific surfaces like Video SDK or REST API. This prevents adding unnecessary libraries.
The agent recommends one primary surface alongside its mandatory authentication model. Without defined constraints on latency and user accounts, the recommendation stays incomplete. If the implementation must span several surfaces at once, the workflow points to running /plan-zoom-integration.
What it helps with
- decide between Meeting SDK and Video SDK for custom app interfaces
- identify the minimal Zoom REST API endpoints and webhooks needed
- audit the repo for conflicting Zoom packages using rg
- surface hidden constraints around hosting and account models
Example prompts for the agent
- Help me pick between Zoom Meeting SDK and Video SDK for embedding calls
- /plan-zoom-product: inspect our codebase and recommend the right Zoom API surface
- Evaluate whether to use Zoom REST API or webhooks for meeting synchronization
How to install plan-zoom-product
Manually: put the files in place
~/.codex/prompts/plan-zoom-product.mdCall it with /prompts:plan-zoom-product. Codex marks this format deprecated in favour of skills
Manually: put the files in place
.claude/commands/plan-zoom-product.mdCall it with /plan-zoom-product. For all projects use ~/.claude/commands/
Manually: put the files in place
.github/prompts/plan-zoom-product.prompt.mdManually: put the files in place
.gemini/commands/plan-zoom-product.tomlGemini stores commands as TOML: the prompt text goes into the prompt field
Questions about plan-zoom-product
How do I install plan-zoom-product in Codex?
Save the command prompt file to ~/.codex/prompts/plan-zoom-product.md. It will then be available in Codex sessions.
What does plan-zoom-product do?
It audits the codebase with rg, evaluates user goals against Zoom surfaces, and picks one primary SDK or API. The command also clarifies why adjacent alternatives are less suitable.
What if the architecture requires multiple Zoom tools?
The command marks the selection as partial and instructs you to run /plan-zoom-integration for multi-surface setups.
Source text
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