Sunsama

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 the daily planner that replaces Sunsama: pull in what I could do, choose what actually fits in a day, and put it on the calendar.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode
- Caddy in front

THE IDEA, WHICH IS A PRODUCT DECISION MORE THAN A FEATURE
- The tool exists to stop you overcommitting. Everything about it is designed around a ritual: once a day, you look at everything you could do, choose a subset, estimate each one, and see the total against the hours you actually have
- If the total exceeds the day, the interface says so plainly and makes you remove something. That single friction is the product
- So do not build a task list with a planning screen bolted on. Build the ritual, and let the list serve it

THE DATA MODEL
- tasks: id, title, notes_md, source_kind, source_id, source_url, project_id, estimate_minutes, actual_minutes, planned_date, planned_order, completed_at, archived_at, carried_count, created_at
- days: id, date, user_id, planned_at, reviewed_at, capacity_minutes, note_md — the ritual itself, recorded
- time_blocks: id, task_id, starts_at_utc, ends_at_utc, calendar_event_id, is_focus
- integrations: id, kind, credentials_encrypted, last_sync_at, cursor
- external_items: id, integration_id, external_id, title, url, status, assignee, updated_at, closed_at — mirrored, and the identity is the external id, never the title
- sessions: id, task_id, started_at, ended_at, source — the timer
- Carrying a task to another day increments carried_count and is recorded. A task carried five times is the most useful signal this tool produces

THE PLANNING RITUAL
- One screen, once a day: yesterday's unfinished tasks, anything due, the inbox from every integration, and today's calendar already blocked out
- Drag what you will do into today. Every task must have an estimate before it can be planned — that is not optional, because a plan without estimates is a wish
- The running total against your available hours, recomputed as you add. Available hours means the day minus meetings, not the whole day
- Over capacity, the interface refuses to be quiet about it. Not a warning colour — a line that says you have planned nine hours into six
- Shutdown at the end of the day: what was done, what was not, and each unfinished task carried or dropped deliberately. The carry is a decision, not a default

CALENDAR
- Two-way with the major providers, read-only ICS for anything else
- Meetings block capacity automatically
- A planned task can be placed as a real calendar event so colleagues see the time is taken, which is the only defence against a day of meetings
- Store instants in UTC, expand recurrences properly, and test both daylight-saving transitions
- Only busy intervals stored from the read side; meeting titles are shown but not required

PULLING TASKS IN
- Adapters for the trackers, inboxes and boards you already use: fetch what is assigned to you, with its identifier, title, status and link
- The external item is mirrored so the plan survives the source being unreachable
- Completing here optionally writes back, and that is off by default — one-way is safer and simpler
- A closed item at the source is marked here rather than deleted, because it may already be in a day
- Each adapter is a small module with a fixture and a test; they break when the host changes, and a failing test beats a mystery

DOING THE DAY
- The day as a list in order, with the estimate beside each
- A timer per task, one running at a time, enforced with a partial unique index, recording actual minutes
- Actual against estimate shown after completion, quietly. Over time this is how estimates get better, and it should never feel like a scolding

WHAT IT TELLS YOU
- Estimated against actual, per task and in aggregate: most people plan at about half of reality, and knowing your own ratio is the single most useful output
- Planned against completed, per day and week
- Carried tasks ranked by how often
- Time by project, and the share of the week that went to meetings
- All computed at query time

WHAT NOT TO BUILD
- Team dashboards of who planned what. The moment this is a management tool, people plan for the audience and it stops working
- Notifications through the day. The ritual is at the start and the end; interrupting the middle defeats it

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, ENCRYPTION_KEY, SMTP_URL, provider credentials
- Migrations on boot, each once
- Nightly backup off the machine, restore script
- Health endpoint reporting the age of each integration's last sync

WHAT MATTERS MOST
Capacity against the plan, and the required estimate. Build the planning screen with the running total and the refusal to stay quiet when it is over, then use it every morning for three weeks. Everything else is a task list, and there are plenty of those.

Give me the repository, one integration adapter with its fixture, migrations, .env.example, a seed week, and a README with deploy steps behind Caddy.