htmlsharechecking
/ uses · family & home · the week, on one screen

who is where this week.

shared calendars are a good idea that most households cannot make work: not everyone has the same platform, half the entries are wrong, and nobody opens the app anyway.

what people actually look at is a printed week on the fridge — because it is visible, it takes no interaction, and reading it costs nothing.

a page is the fridge sheet that can be updated without a printer. one url, the week laid out, and the answer to "who is picking up on thursday" in one glance.

what you make
the household week on one screen
where the week lives
in the page — so everyone sees the same thing
what it is not
a calendar that syncs with anything

the fridge sheet, at a url.

01 / what it is

this is the one family recipe where the content lives in the page rather than in a browser, and that is a deliberate trade. it means nobody can add an event from their phone — but it also means everyone opening the url sees exactly the same week, which is the failure that kills shared calendars.

updating it is a message to your assistant and a republish, which takes about a minute and tends to happen on a sunday evening anyway. what you get in exchange is one version of the truth that does not depend on anyone else’s app.

  • the week as a grid, people against days
  • the recurring stuff — clubs, work patterns, who is home late
  • one-off events for this week
  • clashes and gaps made visible
  • a version that prints cleanly, for the fridge
  • a page everyone sees identically
what is on it
the week’s commitments per person, recurring and one-off
where it lives
in the published page — identical for everyone with the url
updating it
ask for the change, republish to the same address
what it is not
a calendar. no invites, no sync, no notifications

see one in action.

02 / example
htmlshare.net/p/…
screen capture · silent loop
video coming soon

a week with four people as columns, clubs and pickups marked, and one glaring clash on wednesday

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 prompt

a 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.

starting prompt · paste into your ai
Build me a family schedule as a single web page showing this week.

Ask me first:
- Who is in the household and how each person should be labelled.
- The recurring commitments: clubs, work patterns, school runs, who is regularly out.
- Anything one-off happening this week.
- Whether we think in days-of-the-week or in dates.
- Whether I want it to print onto one sheet for the fridge.

Put exactly what I give you into the page. Do not invent events, times or people.

WHAT IT DOES

- Shows the week as a grid: people and days, whichever way round reads better for the number of people I have.
- Each entry is short and readable at a glance — what, when, and who is responsible if that matters.
- Mark clashes visibly: two things at once for the same person, or two pickups at the same time with nobody spare. Finding those is the most useful thing this page does.
- Distinguish the recurring from the one-off, so next week's version is quick to produce.
- Show today clearly when the page is opened mid-week.
- If I asked for print: a stylesheet that produces one clean sheet of paper.

DESIGN

- Readable across a kitchen. This is the criterion; everything else is secondary.
- Works on a tablet propped up, on a phone held at arm's length, and printed.
- No colour-coding that stops working in greyscale — use shape and weight as well.

BE HONEST ON THE PAGE

- This page does not sync with any calendar and cannot send reminders. Do not imply otherwise.
- Because the week is written into the page, say when it was last updated so nobody trusts a stale one.

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="family-schedule">

It tells htmlshare which recipe the page came from, so the library can count
that this one was actually made. It carries nothing else.
works as-is inclaudechatgptcodexcursorgrok
adapting it
ask for a last-updated line.a static week with no date on it is dangerous the moment it goes stale. the prompt asks for it — check it is there and prominent.
get the recurring stuff right once.if the clubs and work patterns are correct, producing next week is a two-line message. most of the ongoing cost of this page is in that first description.
republish, do not repost.update the same url every week. the value here is entirely that nobody in the house has to be told a new address.

give it a url.

04 / publishing it

how 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 page gets republished most weeks, so updating in place is the whole workflow — same url, new week, and the link on the fridge tablet never changes. keep the manage token where your assistant can reach it.

the household learns one address.

05 / keeping it around
anonymous
24h

the page stops serving 24 hours after publishing, with a 7-day recovery window. for a page whose value is that everybody knows where it is, that is the wrong shape.

stable updates
this page is republished weekly. the address has to survive that, or the whole household needs re-informing.
keep it around
an expired url on a fridge tablet is the most visible possible failure.
custom url
a household address everyone learns once and types correctly.

questions.

06 / questions
can family members add things themselves?

no — the week is written into the page, so changes go through whoever asks the assistant and republishes. that is the trade for everyone seeing the same thing rather than each browser holding its own version.

does it sync with google or apple calendar?

no. there is no integration and a self-contained page could not have one. this is a readable week, not a calendar system, and it works precisely because it asks nothing of anyone.

how long does updating it take?

a minute or two — paste the changes to your assistant and republish to the same url. the recurring entries stay, so most weeks it is only the one-offs.

is it private?

no. anyone with the url can read it, and it will contain children’s routines, so keep surnames, addresses and school names off the page. that is worth deciding before you send the link.