Files
calendar/agents/rules
Eunjae LeeGitHubeunjae@cal.com <hey@eunjae.dev>Claude Haiku 4.5Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
12abc316e6 refactor: consolidate agent config into agents directory (#27427)
* refactor: consolidate agent config folders into agents directory

- Move .claude/skills and .claude/rules content to agents/
- Remove duplicate .cursor/ and .goose/ folders
- Create symlinks from .claude/ and .cursor/ to agents/
- Convert review.mdc to quality-review-checklist.md with proper frontmatter

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* feat: add Cal.com APIv2 skills to agents directory

Move the Cal.com API v2 skills from PR #27445 into the consolidated
agents/skills/ directory structure. This includes:
- SKILL.md - Main skill file with API overview
- references/authentication.md - Authentication methods
- references/bookings.md - Bookings API reference
- references/calendars.md - Calendars API reference
- references/event-types.md - Event types API reference
- references/schedules.md - Schedules API reference
- references/slots-availability.md - Slots and availability API reference
- references/webhooks.md - Webhooks API reference

Co-Authored-By: eunjae@cal.com <hey@eunjae.dev>

* fix: update calcom-api skill to use Claude Code frontmatter format

Remove non-standard frontmatter fields (license, metadata) and keep only
the Claude Code supported fields (name, description) as per the
Claude Code skills specification.

Co-Authored-By: eunjae@cal.com <hey@eunjae.dev>

* refactor: restructure calcom-api SKILL.md as index file

Convert SKILL.md from a comprehensive API doc (317 lines) to a concise
index file (108 lines) that references the detailed documentation in
the references/ folder. This follows the Claude Code skills pattern of
keeping SKILL.md focused with supporting files for detailed content.

The SKILL.md now:
- Provides a quick start guide with essential examples
- References all 7 detailed reference docs in a table
- Lists common workflows and best practices
- Points to external resources

Co-Authored-By: eunjae@cal.com <hey@eunjae.dev>

* docs: preserve deleted content in reference files

Move content that was removed from SKILL.md to appropriate reference files:
- Add Error Handling and Pagination sections to authentication.md
- Add Organization endpoints to event-types.md
- Add Core Concepts section back to SKILL.md

This ensures no useful API documentation is lost during the restructuring.

Co-Authored-By: eunjae@cal.com <hey@eunjae.dev>

---------

Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>
Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
2026-02-03 14:14:41 +01:00
..

Cal.com Engineering Rules

This directory contains modular, machine-readable engineering rules derived from Cal.com's Engineering Standards for 2026 and Beyond.

Structure

Rules are organized by section prefix, as defined in _sections.md:

Prefix Section Impact
architecture- Architecture CRITICAL
quality- Code Quality CRITICAL
data- Data Layer HIGH
api- API Design HIGH
performance- Performance HIGH
testing- Testing MEDIUM-HIGH
patterns- Design Patterns MEDIUM
culture- Team Culture MEDIUM

Files

  • _sections.md - Defines all sections, their ordering, and impact levels
  • _template.md - Template for creating new rules
  • {section}-{rule-name}.md - Individual rule files

Rule Format

Each rule file follows a consistent format with YAML frontmatter:

---
title: Rule Title Here
impact: CRITICAL | HIGH | MEDIUM | LOW
impactDescription: Optional description (e.g., "20-50% improvement")
tags: tag1, tag2, tag3
---

## Rule Title Here

**Impact: LEVEL (optional description)**

Brief explanation of the rule and why it matters.

**Incorrect (description):**
\`\`\`typescript
// Bad code example
\`\`\`

**Correct (description):**
\`\`\`typescript
// Good code example
\`\`\`

Reference: [Link](url)

Adding New Rules

  1. Copy _template.md to a new file with the appropriate section prefix
  2. Fill in the frontmatter (title, impact, tags)
  3. Write a clear explanation of the rule
  4. Provide incorrect and correct code examples
  5. Add a reference link if applicable

Usage

These rules are designed to be:

  • Human-readable: Engineers can browse and learn from them
  • Machine-readable: AI agents can parse and apply them
  • Modular: Individual rules can be updated without affecting others
  • Versionable: Changes are tracked in git history

Core Principles

From the blog post, our engineering philosophy is:

We are building infrastructure that must almost never fail. To achieve this, we move fast while shipping amazing quality software with no shortcuts or compromises.

The rules in this directory encode the specific practices that enable this philosophy.