Update to Stacktree

{
  "description": "Publish a dated morning brief or digest to one stable link and refresh it in place each day, rather than minting a new URL every time. Use for a recurring digest (a market/news brief, a standup summary, a metrics digest) the user wants to bookmark once and re-read each morning. Suits a scheduled or agent-loop refresh. Produces a page in the Daily brief shape and always updates the same site via update_site, so the bookmark never breaks.",
  "included_files": [],
  "name": "stacktree-daily-brief",
  "skill_md_contents": "---\nname: stacktree-daily-brief\ndescription: 'Publish a dated morning brief or digest to one stable link and refresh it in place each day, rather than minting a new URL every time. Use for a recurring digest (a market/news brief, a standup summary, a metrics digest) the user wants to bookmark once and re-read each morning. Suits a scheduled or agent-loop refresh. Produces a page in the Daily brief shape and always updates the same site via update_site, so the bookmark never breaks.'\n---\n\n# stacktree-daily-brief\n\nPublish a dated digest to **stacktr.ee** and, crucially, refresh it in place at the\nsame URL on every run. This is the publish path for the `daily-brief` job: a brief\nthe user bookmarks once and re-reads each morning, not a fresh link per day.\n\n## When to invoke\n\n- The user wants a recurring digest: an overnight market/news brief, a standup\n  summary, a watchlist roundup, a daily metrics digest.\n- It will be produced repeatedly (often on a schedule or an agent loop) and read at\n  one stable address.\n- The user says \"refresh it every morning\", \"same link, new content daily\", or \"set\n  up a daily brief\".\n\nFor a one-off run report, use `stacktree-agent-run-report`. For a deliverable to a\nclient, use `stacktree-deliverable`. For a public live-status page, use\n`stacktree-status-dashboard`.\n\n## The page shape\n\nProduce a self-contained HTML document in the Daily brief shape: a `.sheet` with a\n`.topbar` (\"Morning Brief\" plus a `.status ok` pill showing the update time, e.g.\n\"Updated 06:00\"), a dated `.eyebrow` (\"Tuesday, 25 June 2026\"), an `<h1>`, and a\n`.lede` promising a short read. Then `.section` blocks for the day's content, for\nexample Markets (`.mover` rows with inline-SVG `.spark` sparklines and `.fig`\nup/down deltas), Top stories (`<ul class=\"clean\">` with linked sources), and a\nwatchlist. Close with a `.foot` that states it is published from a scheduled agent\nand refreshed at the same link. The date and the update-time must change on every\nrun, the URL must not. Canonical reference: the `daily-brief` template in\n`apps/web/src/templates.ts`.\n\n## Account\n\nRefresh-in-place needs a site the user owns. The Stacktree tools in this plugin\npublish under the user's own Stacktree account, so every page they make can be\nupdated later. If the tools are not connected yet, ask the user to connect\nStacktree.\n\n## The judgment this skill encodes\n\n1. **One site, updated in place. This is the whole point.** On the first run,\n   publish once and record the returned `id` (and slug, if any). On every later run,\n   do not publish a new site, update the existing one:\n   call `update_site` with the saved id. The user's bookmark, and any link they\n   shared, must keep resolving. Minting a new URL each day is the failure mode this\n   skill exists to prevent.\n\n2. **Persist the site id so the loop is stateless-safe.** A scheduled run starts\n   fresh with no memory of yesterday. Store the brief's `id`/slug somewhere the next\n   run can read it (a project note, an env var, a tiny state file). If the id is\n   genuinely lost, recover it with `list_sites` and match by title/slug rather than\n   creating a duplicate. Never let \"I forgot the id\" become \"publish a new link\".\n\n3. **Never expire.** A brief that is refreshed daily should not also be racing an\n   expiry clock. Publish and update with `--expires-never`. The content goes stale by\n   design and is replaced each morning; the site itself stays put.\n\n4. **Keep it unlisted by default; gate if it is personal.** A personal brief\n   (watchlist, internal metrics) should stay on the unlisted token and, if it holds\n   anything private, get a `set_password` or `set_email_gate`. Do not give a daily\n   brief a public slug unless the user explicitly wants a public digest; that is the\n   status-dashboard pattern, not this one.\n\n5. **PII scan stays on (`block`).** Briefs assembled from feeds, inboxes, or internal\n   metrics can pick up addresses or tokens. Keep the default and surface anything it\n   catches before the brief goes out.\n\n## Steps\n\n1. First run: build the brief as a complete HTML document in the page shape above,\n   with today's date and update-time. Publish once:\n   `publish_html` with `expires_in_hours: 'never'`.\n   Record the returned `id` and `url`. Gate it if the content is private.\n2. Hand the user the URL to bookmark, and note that it will refresh at this same\n   address.\n3. Every later run (manual or scheduled): regenerate the brief with the new date and\n   content, then update in place:\n   `update_site` with the saved id. Confirm the id resolved; if not, `list_sites` and match rather\n   than re-create.\n4. To run unattended, wire this into the user's scheduler or agent loop so step 3\n   fires each morning. The update is idempotent: same site, new content.\n\n## What to tell the user\n\nGive them the single link to bookmark, confirm it refreshes at the same address\n(never a new URL), and state whether it is unlisted or gated. If you set up a\nscheduled refresh, say when it runs and where the site id is persisted so the loop\nkeeps targeting the same page.\n"
}