Streaks

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 habit tracker that replaces Streaks: a handful of things, one tap each, and a count of how long I have kept it up.

STACK
- A PWA that works entirely offline, installable, with widgets where the platform allows — or native if the health integration and the watch matter more than the effort
- Local storage first: IndexedDB or SQLite on device. This must work in a lift with no signal
- An optional tiny sync server: Node 20+ with Fastify and SQLite
- Caddy in front

THE ONE CONSTRAINT WORTH KEEPING
- The product being replaced limits you to about a dozen habits, and that limit is a feature rather than a shortcoming. Twenty habits is a list nobody completes and abandons in a fortnight
- Keep the cap, or at least warn past six. A tracker that lets you add forty is a tracker that will be deleted
- One screen, everything on it, one tap per habit. If it takes more than five seconds a day, it will not happen

THE DATA MODEL
- habits: id, name, icon, colour, kind, target_value, unit, schedule_json, timezone, reminder_json, position, archived_at, created_at — kind is done-or-not, a quantity to reach, a quantity to stay under, or a timed task
- entries: id, habit_id, local_date, value, completed_at, source — one row per habit per local day, and the local date is the key because a habit belongs to the day you were living, not to a UTC instant
- Streaks are computed from entries at query time. Never stored, or they will disagree with their own history after a time zone change
- health_links: habit_id, source_kind, metric, threshold — for automatic completion

THE DAY BOUNDARY, WHICH IS THE SUBTLE PART
- The day ends when the user says it does, not at midnight. Somebody who goes to bed at two in the morning has not skipped a day, and a tracker that says otherwise is a tracker they will resent
- So: a configurable day-start hour, and everything computed against local dates in the user's own zone
- Travelling across zones must not break a streak or create a double day. Store the local date and the zone it was recorded in, and be forgiving where it is ambiguous

SCHEDULES
- Every day, specific weekdays, N times a week, N times a month, or every N days
- A habit that is not due today does not count as missed, and the interface makes that obvious. Half the guilt these applications generate is from days that were never required
- 'N times a week' is checked against the week rather than the day, so the streak survives doing three of them on Friday

STREAKS, HUMANELY
- The current streak, the longest streak, and the completion rate over the last month. The third is the honest number and the first is the motivating one, so show both
- A rest day or a skip that does not break the streak, and a small allowance — one missed day a month forgiven — configurable. A streak that punishes one bad Tuesday is a streak that gets abandoned on Wednesday
- Never a notification designed to make somebody feel bad about a broken streak. That is a dark pattern with a checkmark on it
- Backfilling yesterday is allowed and easy, because people forget to tap, not to do the thing

AUTOMATIC COMPLETION
- Read from the platform's health store where there is one: steps, workouts, distance, sleep, mindful minutes
- A habit linked to a metric with a threshold ticks itself off. That is the single most useful feature in this category, because the habits people most want to track are the ones they are least likely to open an app about
- Read-only, on device, never uploaded anywhere. Health data is the most sensitive thing on a phone
- Manual override always available, both ways

REMINDERS
- Per habit, at a chosen local time, on the days it is due
- Not sent if it is already done, which sounds obvious and is the thing most trackers get wrong
- At most one per habit per day
- A location-based reminder if the platform allows, entirely on device

WIDGETS AND THE WATCH
- A home screen widget showing today's habits, tappable without opening anything. This is where a habit tracker is actually used
- A watch complication with the day's completion
- If you cannot build these on your platform, say so honestly in the README, because they are a large part of what the paid application is for

WHAT IT SHOWS
- Today, and a calendar per habit with the completed days marked
- A year view as a grid, which is the picture people screenshot
- Completion rate by weekday, which tells you which day keeps failing
- Everything computed at query time from entries

SYNC AND ESCAPE
- Optional, end-to-end encrypted, last-write-wins per entry with conflicts kept
- Works entirely without it
- Export every entry as CSV in two taps. Years of habit data is a record of your own effort

OPERATIONS
- If there is a server: .env with DATABASE_PATH, BASE_URL, SESSION_SECRET; migrations on boot; nightly backup of ciphertext
- No analytics in the application. Not one event

WHAT MATTERS MOST
The day boundary and automatic completion from the health store. Get the first right and the tracker feels fair; get the second working and half your habits track themselves. Everything else is a list of buttons.

Give me the app, the sync server if you want one, and a README with build steps, the platform integrations, and the widget situation stated plainly.