Fantastical

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a calendar that replaces Fantastical — and know why this is ALMOST.

The calendar is ordinary work. What you are paying for is **a parser that is right every time**: type a sentence, get the right event, on the right calendar, with the right alert, without checking. Right most of the time is worse than useless, because you have to verify every entry and the typing advantage disappears. That reliability, plus the platform integrations, is the verdict.

STACK
- A native application, or a PWA if widgets and system integration matter less than the effort
- SQLite on device, with an optional sync server
- CalDAV as the protocol, so it talks to calendars people already have. Do not invent a sync protocol

THE PARSER, WHICH IS THE PRODUCT
- 'lunch with Anna next tuesday 1pm at Da Mario /work !30' becomes a title, attendees, a start and duration, a location, a calendar and an alert
- Parse in layers, each independently tested: dates and times, duration and ranges, recurrence, the calendar, alerts, location, attendees, and finally the title from what remains
- Dates in the forms people actually type: today, tomorrow, tue, next tuesday, in 3 days, the 15th, 15/03, end of month, every other monday, weekdays at 9
- Ambiguity resolved conservatively and **shown as chips before saving**, correctable with one tap. Never applied silently. That display is what makes right-most-of-the-time acceptable, because the reader verifies at a glance rather than opening the event afterwards
- Runs on the device, offline, in under fifty milliseconds. This is bound to a reflex
- A test suite of several hundred real sentences, including the ambiguous ones, is the actual deliverable. Add every sentence that parses wrongly, forever

TIME
- Every event stored as an instant with its named zone. Never an offset
- All-day events are dates, not midnight instants — the classic bug in this category
- Recurrence rules with exceptions and moved instances, expanded correctly. A wrongly expanded weekly meeting is wrong for a year
- Both daylight-saving transitions in the test suite

CALENDARS
- CalDAV for read and write, plus subscribed ICS feeds read-only
- Discovery, ETags, conditional writes, and a full reconcile on a schedule because incremental sync drifts
- Servers are all subtly different. Test against at least three real ones
- Calendar sets: a named group of calendars, switched in one tap, so work and personal are separate contexts rather than a wall of colours. That feature costs almost nothing and is one of the most-liked

THE VIEWS
- Day, week, month, and a list of what is next — the last one being what most people look at most
- Events and reminders on the same surface, because a to-do with a time is an event to a human
- Weather on the day view if you have a source, which sounds like decoration and is genuinely useful for planning

SHARING AVAILABILITY
- Select some free slots and produce a block of text or a link somebody can pick from
- The link needs a small server: slots, a picker, and a booking that writes the event
- Time zones shown for both sides, always

WIDGETS AND THE PLATFORM
- A home screen widget with today, and a complication on a watch. This is where a calendar is actually read
- If your platform will not allow these, say so in the README, because it is a large part of what the paid application delivers

OPERATIONS
- Local first, working entirely offline
- If there is a sync server: .env with DATABASE_PATH, BASE_URL, SESSION_SECRET; migrations on boot; nightly backup
- No analytics. A calendar knows where you are going and who with

WHAT MATTERS MOST
The parser and its test corpus. Build the layered parser with the chips display and feed it every sentence you actually type for a fortnight; the corpus that comes out of that is the thing worth having.