* 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>
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
- Copy
_template.mdto a new file with the appropriate section prefix - Fill in the frontmatter (title, impact, tags)
- Write a clear explanation of the rule
- Provide incorrect and correct code examples
- 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.