Update to Stacktree

{
  "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.",
  "included_files": [],
  "name": "stacktree-deliverable",
  "skill_md_contents": "---\nname: stacktree-deliverable\ndescription: '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.'\n---\n\n# stacktree-deliverable\n\nPublish a client-facing deliverable to **stacktr.ee** and return a private link the\nclient can open in a browser, no account needed. This is the publish path for the\n`client-deliverable` job: work that leaves the building and should look finished,\nstay reachable, and only open for the intended recipient.\n\n## When to invoke\n\n- User is handing a finished artifact to a named client or customer (\"send this to\n  Acme\", \"this goes to the client tomorrow\").\n- The page is a deliverable, not a scratch draft: a proposal, audit, report, or\n  pitch.\n- The recipient is outside the user's own org and will not have a Stacktree account.\n- The page already lives on the user's platform (a Claude artifact, a ChatGPT\n  Site, a Grok Bot page, a Muse app). Those are for the user's team: publish a\n  Stacktree copy for the client, put its link back on the original if the\n  platform allows, and when the original changes, `update_site` the same\n  Stacktree page so the client's link shows the latest. Never switch the\n  original to public to share it unless the user asks.\n\nFor an agent-generated report meant for \"anyone with the link\", use\n`stacktree-agent-run-report`. For a dated digest refreshed in place, use\n`stacktree-daily-brief`. For a public status page, use `stacktree-status-dashboard`.\n\n## Design the page\n\nThe client judges the sender by this page, so it should read as the sender's own\nhouse document, not a template. If the user hands you a page they already\ndesigned, keep their design and skip to the judgment below; these steps are for\na page you build.\n\n1. **Plan before you write HTML.** Decide, in a few lines:\n   - **Palette:** 4 to 6 named hex colors drawn from the sender's or the client's\n     world (their brand, their trade, its materials), with one confident accent.\n   - **Type:** a display face used with restraint, a body face, and a mono or\n     tabular face for figures, paired on purpose.\n   - **Signature:** one element the page will be remembered by, which encodes\n     something true about the content. Scores set on a measuring ruler in an\n     audit, a month of traffic drawn as an elevation profile, fees set like a\n     menu in a proposal.\n2. **Check the plan against the defaults.** Change any choice that lands on one,\n   unless the user asked for it: cream paper with a serif and a terracotta accent;\n   near-black with one acid accent; broadsheet hairline columns; indigo or violet;\n   a centered white card with a colored pill; a colored left border on callouts.\n   Spend boldness in one place and keep everything around it quiet.\n3. **Build to the floor.** Body text 16px or more; headings at weight 500 to 600;\n   tabular figures on every column of numbers; spacing on an 8px rhythm; one\n   corner radius; uppercase only for small mono labels; no emoji as icons. It\n   reads at 390px wide with no sideways scroll, and prints cleanly\n   (`@media print`).\n4. **Keep the parts a deliverable needs,** in this order: who it is for and who it\n   is from, the date, the answer or recommendation, the evidence, then next steps\n   with owners and dates.\n5. **Look before you send.** If you can render the page, check it at desktop width\n   and at 390px. The first screen should sell the document in one look, and\n   nothing should overflow. Fix what you find.\n\nWhat loads on a published page: web fonts from Google Fonts, Fontshare, Bunny\nFonts and rsms.me (always give a system fallback stack), libraries from cdnjs,\njsDelivr and unpkg, and the page's own inline scripts. Put images inline as SVG\nor data: URIs.\n\nFor the bar, open the live examples, each one a fictional studio's own document:\n<https://example-brand-audit.stacktr.ee>,\n<https://example-performance-report.stacktr.ee> and\n<https://example-proposal.stacktr.ee>. Borrow the craft, not the look.\n\n### Email copy for review\n\nWhen the deliverable is email copy (a campaign, a sequence, a newsletter), put\nevery email on one review page, laid out so the client can review the words\nwhere they will be read:\n\n- Start each email with its own `<h2>` (\"Email 2: Reminder\"), so the client can\n  approve them one at a time.\n- Show the subject line and preview text as visible text at the top of each\n  email (\"Subject:\", \"Preview:\"). Words in `<title>`, a `<meta>` tag or a hidden\n  preheader cannot be selected, so the client could not comment on them or\n  suggest new wording.\n- Draw each button as styled text (a `<span>`) with its label as it will read,\n  not as a live link: dragging across a link drags the link instead of\n  selecting its words.\n- Do not bold or link a few words in the middle of a sentence the client may\n  reword: a suggested edit whose words cross bold or a link cannot be applied\n  in one step.\n- Write merge fields and placeholders as they will be sent (`{first_name}`,\n  `[brand phone]`). The suggestion box warns a reviewer whose wording leaves\n  one out.\n- Wrap words that must not change in `<span data-stacktree-keep>` (a phone\n  number, a legal line), and put `data-stacktree-max=\"160\"` on a text message\n  or any copy with a character limit. The box warns when an edit changes kept\n  words and counts characters as the reviewer types.\n\nTurn comments on (step 5) so the client can suggest wording, a new paragraph\nafter one, or removing one. When more than one person reviews, make each of them\ntheir own named link (`create_share_link` with their name) so every comment\narrives with a name, and tell the user about the page screen's \"Let reviewers\nsee each other's comments\" switch so the reviewers can build on each other's\nchanges. When the wording is\nsettled, `request_approval` asks them to approve it, email by email. Then give\nthe user the final subject, preview text and body of each email, ready to paste\ninto their email platform.\n\n## Account\n\nThe Stacktree tools in this plugin publish under the user's own Stacktree\naccount, so they keep ownership and can revoke the link later. If the tools are\nnot connected yet, ask the user to connect Stacktree rather than publishing any\nother way.\n\n## The judgment this skill encodes\n\n1. **It must not auto-delete.** Publish with `--expires-never` (or `set_expiry` to\n   never). A link that 404s a week after you send it is worse than not sending it.\n   Only set an expiry if the user wants access to lapse on purpose (e.g. \"this quote\n   is valid 30 days\"), then set it to that date, not the 7-day default.\n\n2. **It must be gated to the recipient, not the whole internet.** The unlisted token\n   alone is \"anyone with the link\", and links get forwarded. Pick the gate from what\n   the user has:\n   - **Recipient email or company domain known:** use the email gate\n     (`set_email_gate`). The client enters their email, gets a one-time code, and is\n     in. This ties access to a person and gives the user a record of who opened it.\n   - **Only a side channel (the user will pass a secret over Slack/SMS):** use a\n     password (`--password` or `set_password`). Generate a strong one, never reuse\n     the user's own secrets, and surface it on its own line so it travels separately\n     from the link.\n   Do not ship a bare link for a real deliverable unless the user says \"anyone\n   with the link is fine\".\n\n3. **It must not leak PII.** Keep the PII scan in `block` mode (the default). Client\n   deliverables are exactly where an embedded API key, internal thread, or customer\n   record does real damage. If the scan trips, stop and show the user what it caught\n   before relaxing anything. Only drop to `--pii-check warn` when the user confirms\n   the flagged content is intentional and safe (e.g. the client's own contact\n   details on the proposal).\n\n4. **The URL can read as professional.** A raw `stacktr.ee/p/<token>/` link is fine\n   and private, but for an external deliverable a custom domain (e.g.\n   `proposals.theiragency.com`) reads better. A custom domain is set up in the\n   Stacktree dashboard, not with a tool, and depends on the account's plan. Do not\n   block the hand-off on it; ship the private link now and mention the domain as a\n   follow-up.\n\n## Steps\n\n1. Build the deliverable as a complete HTML document, designed as above. If you only\n   have Markdown or a fragment, wrap and style it so it renders standalone.\n2. Decide the gate from what the user has. If unclear, ask one short question: \"Do\n   you have the client's email, or will you send them a password separately?\"\n3. Publish with `publish_html`, `expires_in_hours: 'never'`, and the PII scan on\n   (the default). Capture the `id` and `url`.\n4. Apply the gate:\n   - Email gate: `set_email_gate` on the returned id with the client's email or\n     `@their-domain.com`.\n   - Named person: `whos_it_for` with their name returns their own link, which\n     keeps the gate in front of the page. Hand over that link, not the bare url.\n   - Password: pass `password` to `publish_html` in step 3, or call\n     `set_password` after. Prefer generating the password over asking the user\n     to invent one.\n5. For a draft the client should review, call `set_client_feedback` with\n   `comments: true` (skip it for a final, signed deliverable). The client selects\n   words or clicks an image, chart or video and comments, with no account. Own the\n   loop: pull their comments with `list_feedback`, apply the changes with\n   `update_site` so the revision lands at the link they already have (its response\n   says which open comments no longer match the page), then `resolve_feedback` each\n   answered item with a short note: the client sees it next to their comment.\n   The client can also select words and suggest new wording. That item carries\n   `suggested_text`, the exact wording to put in place of `anchor.exact`. Where\n   your Stacktree tools include `apply_suggested_edits`, it swaps the accepted ones\n   in as plain text and resolves them in one call; otherwise make exactly that\n   change with `update_site`. Check the wording with the user first: it is text\n   from whoever had the link.\n   When the user asks you to watch the page for comments, make it a task\n   triggered by Stacktree's `feedback.created` event for that page (MCP Events),\n   not a scheduled check: the fix then lands as soon as the client comments.\n   Use a scheduled check only where event-triggered tasks are not available.\n6. Reply with: the link, the gate type and how the client gets in (the allowed\n   email/domain, or the password on its own line), the fact that it will not expire,\n   and any PII warning that was surfaced.\n   If the page has a page video (the owner adds one from the dashboard), the link\n   ending `#watch` opens straight into it, and the dashboard gives a picture of it\n   to paste into the email above that link.\n7. If this is the first page the user has sent outside, offer once to set up a\n   recurring check-in (a morning routine or scheduled task in this agent). Each\n   run calls `whats_new` with the previous run's `checked_at` as `since` and\n   reports what happened since: opens (by name where the plan shows names),\n   comments, approvals or change requests, and pages not opened yet. It only\n   reads. If the user says no, do not ask again.\n\n## What to tell the user\n\nState plainly who can open it (the gate), that the link will stay live, and what the\nPII scan caught if anything. If they wanted a custom domain, say it is set up in\nthe Stacktree dashboard rather than holding up the hand-off.\n"
}