today, in the order you do it.
some things are the same every day and still get forgotten: the tablets, the lunchbox, the thing you are supposed to do before the laptop opens.
a to-do app is the wrong tool — it is built for tasks that arrive and leave, so a repeating list becomes a maintenance job in itself.
a page that shows the same list every morning and clears itself at midnight is a twenty-line html file. ask for it, put it at a url, and stop thinking about it.
the same list, every morning.
01 / what it isthis is deliberately not a to-do list. a to-do list is for things that arrive, get done and disappear; this is for the things that never disappear, and treating them the same way is why routines end up in the wrong tool and get abandoned.
so the page has one list, it is in a fixed order, and at midnight everything unticks. adding and removing items is an occasional act of maintenance rather than the daily interaction, which is exactly the right way round.
- your routine as a list, in the order you actually do it
- items that only appear on certain days
- an automatic reset at midnight
- progress you can see without counting
- a note of which days you finished, if you want the record
- export and import as json
- what it records
- what you ticked today, and optionally which days you completed
- where that goes
- localStorage in one browser. nothing is uploaded
- the reset
- automatic at local midnight, keeping yesterday if you asked for a record
- per-day items
- weekday-only, weekend-only, or specific days — described in words, not configured
see one in action.
02 / examplea morning routine of nine items, in sequence, with two that only appear on weekdays
the live example is still being built — the prompt below is the one it was made with.
copy this, then make it yours.
03 / starting prompta starting point, not a template — the point of an agent is that the result is yours. change the sections to match what you want, and remove anything you don’t need.
Build me a daily checklist as a single web page. It is a repeating routine, not a to-do list.
Ask me first:
- The items on the list, and the order I do them in.
- Whether any of them only apply on certain days.
- Whether I want to keep a record of which days I completed the list, or would rather it just reset.
- Whether the list should be one flat sequence or grouped into sections such as morning and evening.
Do not invent routine items. Do not add anything wholesome I did not ask for.
WHAT IT DOES
- Shows today's list in my order, each item one big tap to tick.
- Items scheduled for particular days appear only on those days, and are not shown greyed out on the others — they are simply not part of today.
- Resets automatically at local midnight. Nothing carries over.
- Shows progress as "4 of 9" and as a bar, so it reads at a glance.
- If I asked for a record: a small calendar or row of the last few weeks marking the days I finished, with no streak language attached.
- Let me edit the list — add, remove, reorder, change which days an item applies to — from the page itself, without republishing.
DESIGN
- One screen on a phone if the list allows it. Big targets. Legible at arm's length.
- Ticked items should stay visible rather than vanishing; seeing the done ones is half of why this works.
- No confetti, no sounds, no "great job".
BE HONEST ON THE PAGE
- Say the list and its state are stored in this browser only.
- Do not claim reminders or notifications of any kind.
STORING THE DATA
- Save everything to localStorage in the browser, automatically, as I go. No
accounts, no login, no server call.
- On the page, say plainly that data lives in this browser only and does not
sync to other devices. Do not bury it.
- Give me an "export" button that copies or downloads everything as JSON, and an
"import" that reads the same JSON back. That is the only way my data can move
between devices, so it is not optional.
- Never lose what I have already entered. If the stored data is from an older
version of the page, read what you can rather than throwing it away.
DELIVERY
- Produce one self-contained HTML file. Inline the CSS and JavaScript.
- No build step, no server, no framework, no package install, no external
requests at runtime.
- Mobile-first and responsive; it has to be usable one-handed on a phone and
still look right on a laptop.
- Accessible: semantic HTML, real contrast, visible keyboard focus, labelled
controls, touch targets big enough to hit, and respect reduced-motion.
- Use placeholders where information is missing. Do not invent facts, numbers,
names, dates, prices, or results I have not given you.
- Before you call it finished, use it yourself: enter real-looking data, reload
the page, and confirm nothing is lost or mangled.
PUBLISHING
Publish the finished page to HTMLShare and give me the link.
Use exactly one of the two paths below, preferring the first. Make the call
directly. Do not route it through a code sandbox, container, or computer-use
session — that is where the request gets blocked, and it is never necessary.
1. An HTMLShare integration or connector, if you have one configured.
The page is permanent and owned by my account. Report the url and the
siteId. There is no claimUrl or manageToken on this path — do not go
looking for one, and do not switch paths in order to produce one.
2. Otherwise, publish anonymously over REST. No account, key, or signup is
needed:
POST https://api.htmlshare.net/v1/publish
content-type: application/json
{"html": "<!doctype html> ... "}
The reference is https://htmlshare.net/docs and, for the full schema,
https://api.htmlshare.net/openapi.json
Report these from the response, in your reply and never inside the page:
url the public page
claimUrl a private link that is mine alone. opening it is how I keep
the page past its 24-hour expiry, or set an email reminder
before it goes. it carries the manage token, so it must
never appear in the published HTML or anywhere a visitor
could see it.
manageToken the only thing that can edit or delete this page later. it is
returned once and never again, so tell me what it is.
Tell me which of the two you used. If the path you reach for first is
unavailable in your environment, say so and tell me what you are switching to
before you publish — a permanent page on my account and a 24-hour anonymous
page are different things, and which one I get is my decision, not a detail.
If I ask for a change afterwards, update the existing page instead of
publishing again, so the URL I have already shared keeps working — through the
same integration on path 1, or with the manage token as an X-Manage-Token
header on path 2.
RECIPE MARKER
Include this tag in the <head>, exactly as written:
<meta name="htmlshare-recipe" content="daily-checklist">
It tells htmlshare which recipe the page came from, so the library can count
that this one was actually made. It carries nothing else.give it a url.
04 / publishing ithow you publish depends on how you’re working.
- with an integration
- if your assistant already has htmlshare connected — mcp or another supported integration — just ask it to publish the finished page and hand back the url. the page belongs to your account and is permanent. when you want a change, ask for an update to that same page rather than a new one.
- with no integration
- the prompt tells the assistant to post the html to the rest api instead, which needs no account and no key. it comes back with a live url you can open immediately, a private claim link, and a manage token. the claim link is how the page stops being temporary — keep it.
- by hand
- nothing stops you doing it yourself: have the assistant give you the html file and drop it on the htmlshare home page. same url, same page, one more step.
- what matters here
- the test of this page is whether you open it before the day gets going. that is a home-screen icon and a short url, so claim it rather than leaving it anonymous.
a daily page has to be there daily.
05 / keeping it aroundone day, by definition — the page stops serving 24 hours after you publish, with a 7-day recovery window. which is a slightly absurd match for a daily checklist.
claim it and it is permanent at a url you chose. this is the least ambiguous case in the library for doing that immediately.
- keep it around
- the page has to exist tomorrow morning, which an anonymous one does not.
- custom url
- first thing in the morning is exactly when you will not want to search for a link.
- stable updates
- routines change with the season and the school term; the address should not change with them.
questions.
06 / questionshow is this different from a to-do app?
a to-do app is built around tasks that arrive and get cleared. this is built around a list that never clears — it just unticks at midnight. that difference sounds small and is the entire reason repeating routines go badly in task apps.
does it reset if i do not open it?
yes. the reset is based on the date, not on you visiting, so opening it on thursday after skipping wednesday gives you a clean thursday list rather than wednesday’s leftovers.
can i have a morning and an evening list?
yes — ask for sections. the page can group items and still reset the whole thing at midnight, which is usually what people want rather than two separate pages.
will my ticks show up on my other devices?
no. each browser keeps its own state, so pick one device for this. it is a routine page, and routines tend to happen in one place anyway.