api-no-breaking-changes
**Impact: CRITICAL**
$ npx -y skills add calcom/cal.com --agent claude-codeHow it fires
How this agent gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
Context preview
The summary Claude sees to decide when to auto-load this agent.
**Impact: CRITICAL**
Agent definition
api-no-breaking-changes.mdtitle: Never Introduce Breaking API Changes
impact: CRITICAL
impactDescription: Maintains developer trust and prevents integration nightmares
tags: api, stability, versioning, backwards-compatibility
Never Introduce Breaking API Changes
**Impact: CRITICAL**
Once an API endpoint is public, it must remain stable. Breaking changes destroy developer trust and create integration nightmares for our users.
**Strategies for avoiding breaking changes:**
- Always add new fields as optional
- Use API versioning when you must change existing behavior
- Deprecate old endpoints gracefully with clear migration paths
- Maintain backward compatibility for at least two major versions
**Incorrect (breaking change):**
// v1 - Original response
interface BookingResponse {
id: number;
startTime: string; // ISO string
}
// v1 - Breaking change: renamed field
interface BookingResponse {
id: number;
start: string; // Renamed from startTime - BREAKS CLIENTS
}**Correct (non-breaking evolution):**
// v1 - Original response
interface BookingResponse {
id: number;
startTime: string;
}
// v1 - Non-breaking: add new field, keep old one
interface BookingResponse {
id: number;
startTime: string; // Keep for backwards compatibility
start: string; // New preferred field
}**When you must make breaking changes:**
- Create a new API version using date-specific versioning in API v2
- Run both versions simultaneously during transition
- Provide automated migration tools when possible
- Give users ample time to migrate (minimum 6 months for public APIs)
- Document exactly what changed and why
Reference: [Cal.diy Engineering Blog](https://cal.com/blog/engineering-in-2026-and-beyond)
Read more
title: Never Introduce Breaking API Changes impact: CRITICAL impactDescription: Maintains developer trust and prevents integration nightmares tags: api, stability, versioning, backwards-compatibility
Never Introduce Breaking API Changes
**Impact: CRITICAL**
Once an API endpoint is public, it must remain stable. Breaking changes destroy developer trust and create integration nightmares for our users.
**Strategies for avoiding breaking changes:**
- Always add new fields as optional
- Use API versioning when you must change existing behavior
- Deprecate old endpoints gracefully with clear migration paths
- Maintain backward compatibility for at least two major versions
**Incorrect (breaking change):**
// v1 - Original response
interface BookingResponse {
id: number;
startTime: string; // ISO string
}
// v1 - Breaking change: renamed field
interface BookingResponse {
id: number;
start: string; // Renamed from startTime - BREAKS CLIENTS
}**Correct (non-breaking evolution):**
// v1 - Original response
interface BookingResponse {
id: number;
startTime: string;
}
// v1 - Non-breaking: add new field, keep old one
interface BookingResponse {
id: number;
startTime: string; // Keep for backwards compatibility
start: string; // New preferred field
}**When you must make breaking changes:**
- Create a new API version using date-specific versioning in API v2
- Run both versions simultaneously during transition
- Provide automated migration tools when possible
- Give users ample time to migrate (minimum 6 months for public APIs)
- Document exactly what changed and why
Reference: [Cal.diy Engineering Blog](https://cal.com/blog/engineering-in-2026-and-beyond)
Repo: calcom/cal.com
Other agents on caldiy.
- knowledge-base
This file contains domain knowledge about the Cal.diy product and codebase. For coding guidelines and rules, see [`rules/`](rules/).
Open agent - api-thin-controllers
**Impact: HIGH**
Open agent - architecture-circular-dependencies
**Impact: CRITICAL**
Open agent - architecture-feature-boundaries
**Impact: CRITICAL**
Open agent - architecture-features-modules
The `packages/features` package should contain only framework-agnostic code: - Repositories (data access layer) - Services (business logic) - Core utilities and helpers - Types and interfaces
Open agent - architecture-page-level-auth
**Impact: CRITICAL (Prevents unauthorized access to sensitive data)**
Open agent

