when you last changed the filter.
a house has twenty things that need doing once or twice a year, and nobody remembers when any of them last happened. the boiler service, the smoke alarms, the gutters, the filter, the thing in the loft.
the cost of forgetting is not the task. it is finding out the hard way, at a price.
a page with the jobs, their intervals and the date each was last done turns that into one glance. it also happens to be the document you hand to whoever buys the house.
a record, and the arithmetic on top of it.
01 / what it isthe whole page is one idea: if you know a job is annual and you know when it was last done, you know whether it is due. everything else — the notes, the costs, the contractor’s number — is context you will be glad of at the exact moment you need it.
it is also one of the few pages here with a resale value. a maintenance history is the kind of document that makes a survey go smoothly, and almost nobody has one because keeping it has always been more effort than it was worth.
- the recurring jobs, with how often each is due
- the date each was last done, and by whom
- what is overdue, computed rather than remembered
- notes — the part number, the plumber, what it cost
- a history per job, which is the bit a buyer wants
- export to json and to something readable
- what it records
- jobs, intervals, last-done dates, notes, costs and a history
- where that goes
- localStorage in one browser. not uploaded
- what it computes
- next due and overdue, from the interval and the last date
- reminders
- none — the page cannot notify you. it shows overdue when you open it
see one in action.
02 / examplenineteen recurring jobs with intervals, last-done dates, and four showing overdue
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 home maintenance tracker as a single web page.
Ask me first:
- The recurring jobs I want to track, and how often each one is due.
- Whether I know when any of them were last done.
- Whether I want to record who did it and what it cost.
- Whether there is anything one-off I want logged as history — a new roof, a rewire.
Build from my answers. Do not invent a standard homeowner checklist, do not add jobs I did not mention, and do not invent dates or costs.
WHAT IT DOES
- The top of the page answers one question: what is due or overdue right now. Computed from each job's interval and the date it was last done, not from a schedule I have to maintain.
- Each job shows: name, interval, last done, next due, and how overdue it is if it is.
- Marking a job done sets today's date and moves the due date forward. Let me backdate it, because I will be entering things I did last month.
- A history per job: every time it has been done, with notes and cost if I asked for those.
- A place for the details worth having — part numbers, filter sizes, the contractor I used, the make and model of the boiler.
- One-off works logged as permanent history rather than as recurring jobs.
EXPORT
- JSON export and import.
- Also a readable export of the whole record, because this is the document I would hand to a buyer or an insurer.
DESIGN
- Overdue items first and obvious, everything else calm. This page should look boring when the house is fine.
- Fine to be dense; it is read on a laptop.
- Do not use alarming red for a slightly overdue gutter clean. Distinguish "due" from "overdue by two years".
BE HONEST ON THE PAGE
- Say the record is stored in this browser only, and that for a document like this an occasional export elsewhere is worth doing.
- Do not claim reminders, emails or notifications — a page cannot send them. It can only show you what is due when you open it.
- Do not give safety, gas, electrical or structural advice, or imply the schedule satisfies any legal or insurance requirement.
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="home-maintenance-tracker">
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
- this is a document with a ten-year horizon, so claim the page and export the record somewhere else as well. a single copy in one browser is not a record of a house.
the useful lifespan here is measured in years.
05 / keeping it aroundthe page stops serving 24 hours after publishing, with a 7-day recovery window behind it. that is not a horizon on which boiler services happen.
claim it. this is the kind of page you open twice a year and are extremely glad exists the third time.
- keep it around
- the intervals here are annual. a page that lasts a day is not participating.
- stable updates
- you will add jobs for years. the record should not move when the page changes.
- custom url
- a house address you can find again in two years without hunting through a browser history.
questions.
06 / questionswill it tell me when something is due?
only when you open it. a published page cannot send notifications or email, so the honest pattern is a recurring calendar reminder on your phone that tells you to look at the page.
is this a legal or insurance record?
no. it is your own note of what you did and when, and the page says so. it may well be useful evidence, but nothing here satisfies a regulation or a policy condition by itself.
can i hand it to a buyer?
that is one of the reasons to keep it — ask for the readable export and you have a maintenance history to attach. do not send them the live url unless you are happy for it to be public.
what if my laptop dies?
the record dies with it unless you exported. browser storage is the only copy, which for a ten-year document is the one thing worth building a habit around.