build-zoom-phone-integration

Use when building Phone.

Quality

37%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./plugins/zoom/skills/phone/SKILL.md

Quality

Content

57%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is admirably concise and well-structured with a clear classified workflow, but its guidance stays abstract and four of its six reference links are broken, undermining navigation. Workflow steps also lack the validation checkpoints that sensitive OAuth/webhook work warrants.

Suggestions

Fix the four broken references (concepts/, examples/, troubleshooting/) so they point to files that actually exist or create those files.

Add explicit validation checkpoints to the workflow — e.g. verify OAuth scopes and phone license before implementation, confirm webhook subscription before relying on events.

Add at least one concrete, actionable detail per step (a representative endpoint, required scope, or webhook payload shape) to lift actionability from specific-but-incomplete to executable.

Dimension	Reasoning	Score
Conciseness	The ~26-line body is lean and assumes Claude's competence: a short intro, a 5-step classified workflow, and a references list, with no padding or explanation of concepts Claude already knows.	3 / 3
Actionability	The steps name concrete sub-areas (OAuth scopes, webhook subscriptions, postMessage event contracts) but provide no executable specifics — no endpoints, commands, or payloads — so guidance is specific-in-domain yet incomplete per the score-2 anchor.	2 / 3
Workflow Clarity	The 5 steps are clearly sequenced and separated by module, but the work involves OAuth scopes, role permissions, and webhook processing with no explicit validation checkpoints or verify-then-proceed feedback loops, capping clarity at 2 per the destructive/batch-operations guideline.	2 / 3
Progressive Disclosure	Of the six references, four resolve to non-existent paths (concepts/architecture-and-lifecycle.md, examples/phone-api-service-pattern.md, examples/smart-embed-postmessage-bridge.md, troubleshooting/common-issues.md) — broken navigation defeats the one-level-deep reference structure and matches the poor-organization score-1 anchor.	1 / 3
	Total	8 / 12 Passed

Description

17%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is too sparse and uses a fragmentary domain term, omitting both concrete capabilities and the Zoom qualifier that distinguishes it. It passes only on having an explicit use-when trigger.

Suggestions

State concrete capabilities, e.g. "Configure Zoom Phone call control, number management, and webhook event handling."

Use the full domain name "Zoom Phone" plus natural trigger terms like CTI, CRM dialer, call events, and Smart Embed.

Combine what and when: "Build Zoom Phone integrations… Use when the workflow involves Zoom Phone, CTI, CRM calling, call events, or Smart Embed."

Dimension	Reasoning	Score
Specificity	The description "Use when building Phone." names no concrete actions — it states only a domain fragment with no verbs (build, configure, integrate) or listed capabilities, matching the score-1 vague/abstract anchor.	1 / 3
Completeness	It has an explicit "Use when" trigger (the when), but the what is nearly absent — "building Phone" conveys no real capability — so it answers when weakly while leaving what largely missing, fitting the score-2 anchor of having one side present but the other thin.	2 / 3
Trigger Term Quality	"Phone" is a fragmentary, ambiguous keyword rather than a natural user phrase like "Zoom Phone" or "CRM calling"; it omits the common variations the body itself lists (CTI, CRM calling, call events, Smart Embed), so coverage is minimal.	1 / 3
Distinctiveness Conflict Risk	"Phone" without "Zoom" is generic and would collide with telephony, mobile, and other calling skills; the qualifying context (Zoom Phone) that would make it distinctive lives only in the body, not the description.	1 / 3
	Total	5 / 12 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 4 missing	Warning

	Total	15 / 16 Passed

Repository: openai/plugins
Path: plugins/zoom/skills/phone/SKILL.md
Commit: 11c74d6

Reviewed: about 9 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.