d4ea931bf8
* feat(agents): add modular engineering rules from 2026 standards Add a rules directory with individual rule files derived from the Cal.com Engineering in 2026 and Beyond blog post. Rules are organized by section (architecture, quality, data, api, performance, testing, patterns, culture) following the Vercel agent-skills structure. Includes: - _sections.md defining rule categories and impact levels - _template.md for creating new rules - 14 individual rule files covering key engineering standards - README documenting the rules structure and usage Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * feat(agents): consolidate DI and Repository+DTO docs into rules - Move di-pattern.md content to rules/patterns-di-pattern.md - Extract Repository + DTO section from knowledge-base.md into: - rules/data-repository-methods.md (method naming conventions) - rules/data-dto-boundaries.md (DTO location and naming) - Update knowledge-base.md to reference the new rule files - Delete old di-pattern.md file Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * chore(agents): remove stub reference sections from knowledge-base.md The rules directory is self-contained with its own README, so these redirect sections are unnecessary clutter. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * refactor(agents): combine DI pattern rules into single file Merged patterns-di-pattern.md into patterns-dependency-injection.md to eliminate overlap and create one comprehensive DI guide. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
80 lines
2.2 KiB
Markdown
80 lines
2.2 KiB
Markdown
# Cal.com Engineering Rules
|
|
|
|
This directory contains modular, machine-readable engineering rules derived from [Cal.com's Engineering Standards for 2026 and Beyond](https://cal.com/blog/engineering-in-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:
|
|
|
|
```markdown
|
|
---
|
|
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.
|