calcom/cal.com's Claude Code Plugin: What's Actually Inside

What is the calcom/cal.com plugin, actually

calcom/cal.com is the source repository for Cal.com, the scheduling platform (47,969 GitHub stars, by Flowy's own count). Its own tagline calls it scheduling infrastructure for absolutely everyone, but the Claude Code plugin Flowy indexes inside that repository is not the scheduling product itself. It is 98 components, 3 skills and 95 agent type entries, and almost all of them exist to help someone work inside Cal.com's own codebase, review a change against its conventions, or call its public API.

Three groups make up those 98 components: rules for contributing to the Cal.com codebase, reference documentation for Cal.com's own API v2, and a couple of general purpose skills that have nothing to do with Cal.com specifically. Which group is worth your time depends on why you opened this listing.

What the three skills do

calcom-api is narrow in what Flowy indexed of it: it documents the secret used to verify webhook payload signatures through the X-Cal-Signature-256 header, which points toward working with Cal.com's API and its webhook deliveries rather than its interface.

vercel-react-best-practices is a general React and Next.js performance skill from Vercel Engineering, not something written for Cal.com specifically. It fires when you are writing, reviewing, or refactoring React components, Next.js pages, or data fetching code, in any codebase, and it covers the same ground as the large agent family described further down.

web-design-guidelines is also general purpose: a UI review skill for checking accessibility, design, and UX against a set of web interface guidelines, meant to fire on requests like review my UI or check accessibility.

The API v2 reference docs, for people integrating with Cal.com

Seven of the 95 agent entries document Cal.com's own API v2, one per area: authentication, bookings, calendars, event-types, schedules, slots-availability, and webhooks. Each is described the same way, detailed documentation for that part of the API, so together they read as a reference for whoever is building against Cal.com's booking API rather than working on Cal.com's source. Pair this set with the calcom-api skill if the integration you are building needs to verify Cal.com's webhook deliveries.

The rules behind Cal.com's own codebase

knowledge-base is the front door: it says the file holds domain knowledge about the codebase and points further guidance at a rules folder. From there the set splits by topic. Architecture and data rules, including architecture-vertical-slices, architecture-feature-boundaries, architecture-page-level-auth, data-repository-pattern, and data-dto-boundaries, are flagged critical or high impact in what Flowy indexed. architecture-features-modules has real detail: the shared features package should hold only framework agnostic repositories, services, and types. patterns-trigger-dev names Trigger.dev as the async task runner shared by the web and API v2 apps, toggled off by an environment variable called ENABLE_ASYNC_TASKER. patterns-app-store explains that generated files back the app store integrations, produced by a tool called app-store-cli.

Quality, testing, and CI rules cover the everyday review cycle: quality-pr-creation asks for draft pull requests by default, quality-error-handling wants an error message specific enough to name the user and date involved, ci-git-workflow insists on pushing before checking CI status, and testing-mocking says to implement the full Calendar interface rather than copying properties from one real calendar service. testing-timezone and testing-incremental shape how the suite itself gets run: a fixed timezone, one failing file at a time.

Many entries in these architecture, data, patterns, and quality groups carry only a severity tag in what Flowy indexed: critical, high, or medium. A couple of others, reference-local-dev and testing-playwright, are cut off after their first line, a local setup command and a Playwright command format. Read the name as the topic and the tag as how much it matters, not as the complete rule.

The React and Next.js performance rules

Close to half of the 95 agent entries are one technique per file performance rules for React and Next.js work. They group by where the cost shows up: async and data fetching (async-parallel, async-suspense-boundaries), bundle size (bundle-dynamic-imports, bundle-defer-third-party), rendering and re-renders (rendering-hoist-jsx, rerender-memo), server components (server-cache-react, server-parallel-fetching), and hot path JavaScript (js-set-map-lookups, js-early-exit). None of them mention Cal.com by name in what Flowy indexed, so they read as portable practice you could apply to any React or Next.js project, not house rules for this one.

How do I install it

Flowy indexes calcom/cal.com from its public GitHub repository; it does not host or bundle these components. Most of the 98 are contributor tooling for Cal.com's own team, so check which group above matches what you are actually trying to do before you rely on it. Install from the listing page linked at the top of this guide, and the skills and agent entries above become available in that session.