Stacktree

View saved version →

---
name: stacktree-agent-run-report
description: 'Publish what your agent just produced as a private web page, shareable with anyone who has the link. Use right after a run produces a report, audit, analysis, or a dashboard the agent built on demand, the kind that reads better in a browser than dumped in the chat, and the user wants a link to send to colleagues with no account or workspace required. Fits the throwaway, on-demand dashboard pattern (gather the data, render the HTML, share a private link that expires on its own) as well as longer run reports. Produces a page in the Agent run report shape (KPI header, findings, recommended order), keeps it unlisted with a sensible default expiry, and is built to be refreshed in place on re-run.'
---

# stacktree-agent-run-report

Publish a report or dashboard your agent just generated to **stacktr.ee** and return
a private URL, so it is read in a browser and shareable with anyone, instead of
scrolling a wall of text in the chat. This is the publish path for the
`agent-run-report` job.

## When to invoke

- A run just produced a long-form report, audit, analysis, or dashboard that is
  genuinely better as a styled page than as inline text.
- The user wants a link they can forward to colleagues who have no Stacktree account
  and no access to the workspace the agent ran in.
- The user says "publish what you just did", "give me a link to this", or "put this
  somewhere I can look at it".
- The user is following the build-it-then-throw-it-away pattern: rather than maintain a
  standing dashboard, the agent gathers the data and renders a single-use HTML view to
  answer one question right now. This skill is the publish step, and the expiry is what
  makes the page genuinely disposable.

For a deliverable headed to a named external client, use
`stacktree-deliverable` (it adds recipient gating). For a dated digest on a
schedule, use `stacktree-daily-brief`. For a public health page, use
`stacktree-status-dashboard`.

## The page shape

Produce a self-contained HTML document in the Agent run report shape: a `.sheet`
with a `.topbar` ("Run report" plus a `.pill` reading "Completed"), an `.eyebrow`
"Automated by your agent", an `<h1>`, a `.lede`, a `.meta` row (completed-at, model,
duration), and a `.kpis` strip of three figures with the at-risk one marked
`class="kpi alert"`. Follow with `.section` blocks: Summary, Key findings
(`<ul class="clean">`), Recommended order (`<ol class="steps">`), and a Notes
section that states the page came straight from the run and can be refreshed in
place at the same URL. Charts must be self-contained (inline SVG, as the template
does, or a pinned CDN script, never a local file path that 404s). The canonical
reference is the `agent-run-report` template in `apps/web/src/templates.ts`.

## Account

The Stacktree tools in this plugin publish under the user's own Stacktree
account, so the report is listable (`list_sites`), editable and refreshable
later. If the tools are not connected yet, ask the user to connect Stacktree.

## The judgment this skill encodes

1. **It pulled in data, so the PII scan stays strict.** Reports built from tool
   output, scraped pages, logs, or query results are the most likely to carry an
   embedded key, a customer email, or a token. Keep `--pii-check block` (the
   default). If it trips, do not relax it reflexively, show the user the finding. A
   report is read later by a human who assumes it is safe; make that true first.

2. **Shareable with anyone is the point, but unlisted, not public.** The job is "no
   account, no workspace needed to view", which the default unlisted token already
   delivers (the link works for anyone you send it to). Do not add a `--public-slug`
   here, that is for the status-dashboard job. A run report is for the people the
   user forwards it to, not for search engines. Only gate it (`set_password` /
   `set_email_gate`) if the user says the findings are sensitive.

3. **Default to a sensible expir

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: stacktree-daily-brief
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.'
---

# stacktree-daily-brief

Publish a dated digest to **stacktr.ee** and, crucially, refresh it in place at the
same URL on every run. This is the publish path for the `daily-brief` job: a brief
the user bookmarks once and re-reads each morning, not a fresh link per day.

## When to invoke

- The user wants a recurring digest: an overnight market/news brief, a standup
  summary, a watchlist roundup, a daily metrics digest.
- It will be produced repeatedly (often on a schedule or an agent loop) and read at
  one stable address.
- The user says "refresh it every morning", "same link, new content daily", or "set
  up a daily brief".

For a one-off run report, use `stacktree-agent-run-report`. For a deliverable to a
client, use `stacktree-deliverable`. For a public live-status page, use
`stacktree-status-dashboard`.

## The page shape

Produce a self-contained HTML document in the Daily brief shape: a `.sheet` with a
`.topbar` ("Morning Brief" plus a `.status ok` pill showing the update time, e.g.
"Updated 06:00"), a dated `.eyebrow` ("Tuesday, 25 June 2026"), an `<h1>`, and a
`.lede` promising a short read. Then `.section` blocks for the day's content, for
example Markets (`.mover` rows with inline-SVG `.spark` sparklines and `.fig`
up/down deltas), Top stories (`<ul class="clean">` with linked sources), and a
watchlist. Close with a `.foot` that states it is published from a scheduled agent
and refreshed at the same link. The date and the update-time must change on every
run, the URL must not. Canonical reference: the `daily-brief` template in
`apps/web/src/templates.ts`.

## Account

Refresh-in-place needs a site the user owns. The Stacktree tools in this plugin
publish under the user's own Stacktree account, so every page they make can be
updated later. If the tools are not connected yet, ask the user to connect
Stacktree.

## The judgment this skill encodes

1. **One site, updated in place. This is the whole point.** On the first run,
   publish once and record the returned `id` (and slug, if any). On every later run,
   do not publish a new site, update the existing one:
   call `update_site` with the saved id. The user's bookmark, and any link they
   shared, must keep resolving. Minting a new URL each day is the failure mode this
   skill exists to prevent.

2. **Persist the site id so the loop is stateless-safe.** A scheduled run starts
   fresh with no memory of yesterday. Store the brief's `id`/slug somewhere the next
   run can read it (a project note, an env var, a tiny state file). If the id is
   genuinely lost, recover it with `list_sites` and match by title/slug rather than
   creating a duplicate. Never let "I forgot the id" become "publish a new link".

3. **Never expire.** A brief that is refreshed daily should not also be racing an
   expiry clock. Publish and update with `--expires-never`. The content goes stale by
   design and is replaced each morning; the site itself stays put.

4. **Keep it unlisted by default; gate if it is personal.** A personal brief
   (watchlist, internal metrics) should stay on the unlisted token and, if it holds
   anything private, get a `set_password` or `set_email_gate`. Do not give a daily
   brief a public slug unless the user explicitly wants a public digest; that is the
   status-dashboard pattern, not this one.

5. **PII scan stays on (`block`).** Briefs assembled from feeds, inboxes, or internal
   metrics can pick up addresses or tokens. Keep the default and surface anything it
   catches be

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: stacktree-deliverable
description: 'Hand a finished report or proposal to a client at a private link. Use when the user says "send this to the client", "share this with <company>", "this is for a customer", or is handing a polished deliverable to someone outside their team. Designs the page as a house document from the sender rather than a template, gates it to the recipient, removes the auto-expiry so the link stays live, and refuses to ship if the page leaks PII.'
---

# stacktree-deliverable

Publish a client-facing deliverable to **stacktr.ee** and return a private link the
client can open in a browser, no account needed. This is the publish path for the
`client-deliverable` job: work that leaves the building and should look finished,
stay reachable, and only open for the intended recipient.

## When to invoke

- User is handing a finished artifact to a named client or customer ("send this to
  Acme", "this goes to the client tomorrow").
- The page is a deliverable, not a scratch draft: a proposal, audit, report, or
  pitch.
- The recipient is outside the user's own org and will not have a Stacktree account.
- The page already lives on the user's platform (a Claude artifact, a ChatGPT
  Site, a Grok Bot page, a Muse app). Those are for the user's team: publish a
  Stacktree copy for the client, put its link back on the original if the
  platform allows, and when the original changes, `update_site` the same
  Stacktree page so the client's link shows the latest. Never switch the
  original to public to share it unless the user asks.

For an agent-generated report meant for "anyone with the link", use
`stacktree-agent-run-report`. For a dated digest refreshed in place, use
`stacktree-daily-brief`. For a public status page, use `stacktree-status-dashboard`.

## Design the page

The client judges the sender by this page, so it should read as the sender's own
house document, not a template. If the user hands you a page they already
designed, keep their design and skip to the judgment below; these steps are for
a page you build.

1. **Plan before you write HTML.** Decide, in a few lines:
   - **Palette:** 4 to 6 named hex colors drawn from the sender's or the client's
     world (their brand, their trade, its materials), with one confident accent.
   - **Type:** a display face used with restraint, a body face, and a mono or
     tabular face for figures, paired on purpose.
   - **Signature:** one element the page will be remembered by, which encodes
     something true about the content. Scores set on a measuring ruler in an
     audit, a month of traffic drawn as an elevation profile, fees set like a
     menu in a proposal.
2. **Check the plan against the defaults.** Change any choice that lands on one,
   unless the user asked for it: cream paper with a serif and a terracotta accent;
   near-black with one acid accent; broadsheet hairline columns; indigo or violet;
   a centered white card with a colored pill; a colored left border on callouts.
   Spend boldness in one place and keep everything around it quiet.
3. **Build to the floor.** Body text 16px or more; headings at weight 500 to 600;
   tabular figures on every column of numbers; spacing on an 8px rhythm; one
   corner radius; uppercase only for small mono labels; no emoji as icons. It
   reads at 390px wide with no sideways scroll, and prints cleanly
   (`@media print`).
4. **Keep the parts a deliverable needs,** in this order: who it is for and who it
   is from, the date, the answer or recommendation, the evidence, then next steps
   with owners and dates.
5. **Look before you send.** If you can render the page, check it at desktop width
   and at 390px. The first screen should sell the document in one look, and
   nothing should overflow. Fix what you find.

What loads on a published page: web fonts from Google Fonts, Fontshare, Bunny
Fonts and rsms.me (always give a system fallback stack), libraries from cdnjs,
jsDelivr and unpkg, and the page's own inl

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: stacktree-publish
description: 'Publish HTML to a private link that opens in any browser, no account needed for the viewer. Use when the user says "publish this", "publish html", "host this html", "share this page privately", "share an html file", "send this to the client", or asks for a link to something you built. Pages can be passcode-gated on every plan, restricted to a company email domain, or given a public slug; links are private by default and replace in place, so a shared URL always shows the current version.'
---

# stacktree-publish

Publish an HTML artifact to **stacktr.ee** and return the URL into the conversation.

## When to invoke

- User asks to publish, share, host, or drop an HTML / Markdown artifact you just generated.
- User wants a link to a hosted version of a page they just saw (e.g. a dashboard, mock, table).
- You just produced an HTML artifact and the user will benefit from a browser view.

**A copy for someone outside.** Your platform's own pages (Claude artifacts, ChatGPT Sites, Grok Bot pages, Muse apps) are for the user and their team. When a page is for someone outside (a client, a customer, anyone without the team's account), publish a Stacktree copy, rebuilt as one page by following `get_design_guide` with `for: "client_copy"` so every chart, tab and checklist survives: add a passcode, email gate or expiry if the user asks, and for a named person, hand over their own link from `whos_it_for`. If the platform allows, put the Stacktree link back on the original page. When the original changes, call `update_site` on the same Stacktree page so the recipient's link always shows the latest. Never switch the platform's own page to public to share it unless the user asks.

Do **not** use this for code that isn't a complete static page (e.g. fragments, JSX components without a host page). Wrap the fragment in a minimal HTML shell first.

## How to publish

This skill works alongside the **Stacktree MCP server** that comes with this plugin. Call its tools directly.

The tools you will use most:

| Tool                 | Purpose                                                  |
| -------------------- | -------------------------------------------------------- |
| `publish_html`       | Upload HTML. Returns `{ url, id, expires_at, ... }`.     |
| `update_site`        | Replace HTML in place — URL stays stable across revisions. |
| `set_password`       | Add or clear a passcode gate. Works on every plan.       |
| `set_email_gate`     | Restrict viewers to a specific email domain. Paid plans only. |
| `set_expiry`         | Set hours-from-now expiry, or `null` for never.          |
| `set_client_feedback` | Let the people you send it to comment (words, images, video) and react, with no account. |
| `list_feedback`      | Read their comments, each with what it is on and whether it is still on the page. |
| `resolve_feedback`   | Close a comment with a short note the client sees.       |
| `list_sites`         | List the sites in this account.                          |
| `list_client_spaces` | List the client spaces pages are filed under.            |
| `set_client`         | File an existing page under a client, or detach it.      |
| `create_client_space` | Create a client space up front (publishing auto-creates one anyway). |
| `update_client_space` | Rename, archive/unarchive, or gate a whole client space. |
| `delete_client_space` | Delete a space; its pages detach and keep working.      |
| `delete_site`        | Take a page down. The link dies now; content kept 30 days. |
| `restore_site`       | Put a deleted or expired page back at the same URL.      |

## Steps

1. Make sure the artifact is a complete HTML document (`<!doctype html>...</html>`). If you only have a body fragment or markdown, wrap it in a minimal HTML shell first.
2. Call **`publish_html`** with the HTML content as the `content` argument. Optional arguments worth knowing:
   - `password` — passcode gate, works on every plan

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: stacktree-status-dashboard
description: 'Publish a live status or health page that anyone can check at a clean public URL, refreshed in place as conditions change. Use for a public status page, uptime/health dashboard, or "is it up" page meant to be linked from a footer or shared widely with no login. This is the one job where a public slug is the right call. Produces a page in the Status dashboard shape, gives it a public {slug}.stacktr.ee URL, and updates the same site on every refresh.'
---

# stacktree-status-dashboard

Publish a live status or health page to **stacktr.ee** at a public, memorable URL and
refresh it in place as conditions change. This is the publish path for the
`status-dashboard` job, and the one case in this library where a public slug is
correct.

## When to invoke

- The user wants a public status page, uptime/health dashboard, or "is the service
  up" page that anyone can check with no login.
- It will be linked widely (a docs footer, a support page, a status link) and
  refreshed as health changes.
- The user says "give it a public status URL", "put up a status page", or "a health
  page anyone can check".

For a private run report shareable by link, use `stacktree-agent-run-report`. For a
private dated digest, use `stacktree-daily-brief`. For a client deliverable, use
`stacktree-deliverable`.

## The page shape

Produce a self-contained HTML document in the Status dashboard shape: a `.sheet`
with a `.topbar` ("System status" plus a `.status ok` pill reading the overall state,
e.g. "All systems operational"), an `<h1>` of the headline state, a `.lede`, a
`.meta` row (updated-at, region), and a `.kpis` strip (uptime %, avg response, open
incidents). Then `.section` blocks: an `.uptime` bar strip (90 day cells, with
`.warn`/`.down` for off days), a Services list (`.svc` rows, each with a `.spark`
and a per-service `.status ok|warn`), and a Recent incidents note. Close with a
`.foot` that states the link is public and shareable and refreshes in place. The
overall pill and the updated-at must reflect real current state on each run.
Canonical reference: the `status-dashboard` template in `apps/web/src/templates.ts`.

## Account

A public slug and refresh-in-place both need a site the user owns. The Stacktree
tools in this plugin publish under the user's own Stacktree account. If the tools
are not connected yet, ask the user to connect Stacktree. A public slug may not be
on the account's plan; if the slug is rejected, fall back to the unlisted URL and
tell the user a public address is not available on their current plan.

## The judgment this skill encodes

1. **A public slug is right here, and only here.** A status page exists to be found
   and linked, so give it a clean address with `--public-slug <slug>` (e.g.
   `status` for `status.stacktr.ee`, or the product's own name). This is the
   deliberate exception to the library's private-by-default posture. Confirm the slug
   with the user, since it is public and memorable.

2. **Public means a hard PII and secrets bar.** Because anyone can read it, a status
   page must contain only what is safe for the world: service names, states, uptime,
   response times, incident notes. Never put internal hostnames, customer data,
   tokens, or stack traces on it. Keep `--pii-check block`, and if it trips, treat it
   as a real leak on a public page, not a nuisance, and fix the content. Do not relax
   the scan on a public page.

3. **No password, no email gate.** Gating defeats the job ("anyone can check"). If the
   user actually wants a private health view for the team only, that is the
   daily-brief or agent-run-report pattern with a gate, not this skill. Keep this one
   open.

4. **Refresh in place, never a new URL.** The page's whole value is one stable
   address that always shows current state. On the first run, publish with the slug
   and record the `id`. On every later run, update the same site:
   call `update_site` with the saved id. For a li

Preview of the first 4,000 characters. Read full instructions →