ab21c7f805
* feat: Cal.diy — community-driven MIT-licensed fork of Cal.com This squashed commit contains all Cal.diy changes applied on top of calcom/cal.com main: - Rebrand Cal.com to Cal.diy across the entire codebase - Remove Enterprise Edition (EE) features, license checks, and AGPL restrictions - Switch license from AGPL-3.0 to MIT - Remove docs/ directory (migrated to Nextra at cal.diy) - Remove dead code: org tests, EE tips, platform nav, premium username, SAML/SSO, etc. - Clean up .env.example for self-hosted Cal.diy - Update Docker image references to calcom/cal.diy - Update README, CONTRIBUTING.md, and issue templates for Cal.diy community fork - Add PR welcome bot for Cal.diy contributors - Fix API v2 breaking changes oasdiff ignore entries - Replace Blacksmith CI runners with default GitHub Actions 3893 files changed, 20789 insertions(+), 411020 deletions(-) Co-Authored-By: benny@cal.com <sldisek783@gmail.com> * refactor: remove org-specific /organizations/:orgId endpoints from API v2 atoms controllers (#1701) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * fix: revert Cal.diy Inc to Cal.com, Inc. in license files, copyright notices, and package metadata (#1702) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * rip out org related comments in api v2 --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Spec-First Development
This folder contains design documents for features in development. Claude reads these to understand what to build and track progress.
How It Works
- Before implementing a feature, create a spec folder with design docs
- Claude reads the design before writing any code
- Progress is tracked in implementation.md for session continuity
- Decisions are recorded in decisions.md for future reference
- Docs are generated with screenshots when feature is complete
Starting a New Feature
cp -r specs/_templates specs/{feature-name}
Then tell Claude:
"I want to build {feature}. Here's my idea: [description].
Review the codebase and fill in specs/{feature}/design.md"
File Structure
Each feature has:
| File/Folder | Purpose |
|---|---|
CLAUDE.md |
Instructions for Claude when working on this feature |
design.md |
Source of truth - what to build and how |
implementation.md |
Progress tracking - what's done, in progress, blocked |
decisions.md |
Architecture Decision Records (ADRs) |
prompts.md |
Reusable prompts for common tasks |
future-work.md |
Deferred ideas and enhancements |
docs/ |
Internal documentation with screenshots |
docs/screenshots/ |
Screenshots captured during development |
Session Continuity
When starting a new Claude session:
"Continue working on {feature}"
Claude will read implementation.md to pick up where it left off.
Generating Documentation
When a feature is ready for documentation:
"Generate docs with screenshots for {feature}"
Claude will:
- Open the feature in browser
- Take screenshots of key UI states
- Save to
specs/{feature}/docs/screenshots/ - Update
specs/{feature}/docs/README.md
Promoting to Public Docs
When internal docs are ready for customers:
"Promote {feature} docs to public"
Claude will:
- Copy content to
docs/{feature}.mdx(Mintlify format) - Move screenshots to
docs/images/{feature}/ - Update
docs/mint.jsonnavigation - Adjust language for customer audience
The Most Important Rule
Every PR must be reviewable in under 10 minutes:
- Max 5-7 files changed (excluding tests)
- Max 500 lines changed
- One focused change per PR
If your change is bigger, split it into multiple PRs.