# Stacktree Client Deliverable > 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 ", "this is for a customer", or is handing a polished deliverable to someone outside their team. Produces a page in the Client deliverable shape (a clean editorial "sheet" prepared-for-a-named-recipient), gates it to the recipient, removes the auto-expiry so the link stays live, and refuses to ship if the page leaks PII. - Skill: `stevysmith/stacktree-client-deliverable` (Agent Skill) - Install (CLI): `npx skillmds@latest add stevysmith/stacktree-client-deliverable` - Raw SKILL.md: https://api.skillmd.com/api/skills/stevysmith/stacktree-client-deliverable/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: stevysmith (https://skillmd.com/u/stevysmith) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/stevysmith/stacktree-client-deliverable --- # stacktree-client-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. 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`. ## The page shape Produce a single self-contained HTML document in the Client deliverable shape: a centered white `.sheet` with a `.topbar` (the studio/sender name on the left, a `.pill` reading "Private deliverable" on the right), then a `.pad` body with an `.eyebrow` "Prepared for ", an `

` title, a `.lede`, and a `.meta` row (prepared by, date, version). Use `.section` blocks for Overview, the one recommendation (in a `.callout`), an at-a-glance `
`, and next steps (`
    `). Close with a `.foot`. The published page is what the client sees, so the craft is the point: keep it editorial, content-first, no broken assets. The canonical reference is the `client-deliverable` template in the Stacktree app (`apps/web/src/templates.ts`); match its structure and restraint. ## Required env ``` STACKTREE_API_KEY=stk_live_... # generate at https://app.stacktr.ee/api-keys ``` A client deliverable should publish under the user's own account so they keep ownership and can revoke it later. If no key is set, ask for one rather than falling back to an anonymous upload (anonymous uploads expire in 24h, which is wrong for a deliverable). See the root `stacktree-publish` skill for the pay-to-provision path when there is genuinely no human and no key. ## The judgment this skill encodes 1. **It must not auto-delete.** Publish with `--expires-never` (or `set_expiry` to never). A link that 404s a week after you send it is worse than not sending it. Only set an expiry if the user wants access to lapse on purpose (e.g. "this quote is valid 30 days"), then set it to that date, not the 7-day default. 2. **It must be gated to the recipient, not the whole internet.** The unlisted token alone is "anyone with the link", and links get forwarded. Pick the gate from what the user has: - **Recipient email or company domain known:** use the email gate (`set_email_gate`). The client enters their email, gets a one-time code, and is in. This ties access to a person and gives the user a record of who opened it. - **Only a side channel (the user will pass a secret over Slack/SMS):** use a password (`--password` or `set_password`). Generate a strong one, never reuse the user's own secrets, and surface it on its own line so it travels separately from the link. The template's footer line ("This link is unguessable. Add a password if it should be.") is the prompt: act on it, do not ship a bare link for a real deliverable unless the user says "anyone with the link is fine". 3. **It must not leak PII.** Keep the PII scan in `block` mode (the default). Client deliverables are exactly where an embedded API key, internal thread, or customer record does real damage. If the scan trips, stop and show the user what it caught before relaxing anything. Only drop to `--pii-check warn` when the user confirms the flagged content is intentional and safe (e.g. the client's own contact details on the proposal). 4. **The URL can read as professional.** A raw `stacktr.ee/p//` link is fine and private, but for an external deliverable a custom domain (e.g. `proposals.theiragency.com`) reads better. Custom domains are a paid Pro unlock, not a publish flag, and there is no MCP tool for the mapping, so point the user to or the dashboard to enable it. Do not block the hand-off on it; ship the private link now and offer the domain as a follow-up. ## Steps 1. Build the deliverable as a complete HTML document in the page shape above. If you only have Markdown or a fragment, wrap and style it so it renders standalone. 2. Decide the gate from what the user has. If unclear, ask one short question: "Do you have the client's email, or will you send them a password separately?" 3. Publish with no expiry and the PII scan on, via the publish helper: ```bash echo "$DELIVERABLE_HTML" | bash scripts/publish.sh --expires-never ``` Equivalent MCP path: `publish_html` with expiry set to never. Capture the `id` and `url`. 4. Apply the gate: - Email gate: `set_email_gate` on the returned id with the client's email or `@their-domain.com`. - Password: pass `--password ` in step 3, or call `set_password` after. Prefer generating the password over asking the user to invent one. 5. Optionally `set_agentation` (or `--agentation`) if the client should be able to leave inline feedback (useful for a draft-for-review; skip it for a final, signed deliverable). If you enable it, own the loop: once the client has annotated, pull their notes with `list_feedback`, apply the changes with `update_site` so the revision lands at the link they already have, then `resolve_feedback` each item with a short note so the client can see what changed and why. 6. Reply with: the link, the gate type and how the client gets in (the allowed email/domain, or the password on its own line), the fact that it will not expire, and any PII warning that was surfaced. ## What to tell the user State plainly who can open it (the gate), that the link will stay live, and what the PII scan caught if anything. If they wanted a custom domain, note it is a one-time Pro unlock and offer to walk them through it rather than holding up the hand-off.