How to contribute

This section is the practical guide for landing a change in Cal.diy. The official prose lives in CONTRIBUTING.md and AGENTS.md at the repo root; what you find here is a developer-flavored summary plus pointers to the parts of the repo that codify each rule.

Pickup → ship

1. Pick an issue or open a draft PR. Recent commits show that kodiak[bot] auto-merges PRs that meet the criteria in .kodiak.toml. Open PRs as drafts by default (AGENTS.md: "Create PRs in draft mode by default").
2. Branch. No fixed naming convention enforced by tooling. The team uses descriptive branch names; commit messages follow Conventional Commits (feat:, fix:, refactor:, etc., per AGENTS.md).
3. Code. Follow the patterns and conventions. Use select not include in Prisma queries. Repositories own queries; services own logic.
4. Test. Add unit tests with Vitest, E2E with Playwright, or Jest for apps/api/v2. See testing.
5. Type-check + lint. Run yarn type-check:ci --force and yarn lint:fix before pushing. Husky + lint-staged run a stripped-down version on commit (lint-staged.config.mjs).
6. Open the PR. Title in conventional commit format. Keep diffs under 500 lines / 10 code files per the size guidelines in AGENTS.md. Larger work should be split into stacked PRs.
7. CI. All required checks live in .github/workflows/all-checks.yml and the per-target workflows (check-types.yml, e2e.yml, e2e-app-store.yml, e2e-embed.yml, etc.).
8. Review. Cal.com uses Kodiak for auto-merge. Manual review concentrates on architectural changes and security-sensitive paths.

Definition of done

A change is "done" when:

• It type-checks (yarn type-check:ci).
• It lints (yarn lint) and is formatted (yarn format).
• New behavior is covered by unit and/or E2E tests.
• UI strings live in packages/i18n/locales/en/common.json (and ideally the other locales).
• It does not introduce as any or expose credential.key (these are explicit prohibitions in AGENTS.md).
• Generated files (*.generated.ts) were regenerated by app-store-cli, not hand-edited.
• The PR description references the issue or spec it implements.

Subsections

• Development workflow — branches, scripts, hot loops
• Testing — Vitest, Playwright, Jest e2e
• Debugging — logs, common failures, troubleshooter
• Patterns and conventions — error handling, imports, repository / service split
• Tooling — Turbo, Biome, Husky, Trigger.dev, Sentry, Checkly