Thryvate plugin

---
name: connect
description: Connect this AI to Thryvate over MCP and verify it can manage your sites.
---

Connect this AI client to Thryvate over MCP so it can publish, update, and share the user's
sites. Goal: **one browser click, no token in chat, no copy-paste.** Drive it as a single clear
step at a time — never hand the user a list of actions to do at once.

## Talking to the user (follow exactly)

- **One step at a time.** Say the single next thing to do, then stop and wait.
- **Make links clickable.** Put any authorization URL on its **own line, raw** — just the
  `https://…` with nothing else on the line (no markdown link syntax, backticks, or trailing
  punctuation). That is what renders as a clickable link.
- **One live link only.** Each new authorization attempt invalidates the previous link. Show only
  the newest URL and tell the user to ignore any earlier ones.
- **Restarts, in plain words.** A newly added MCP server loads only when Claude restarts. When that
  is needed, say it exactly like this: *"Fully quit Claude and reopen it — a reload is not enough —
  then tell me you're back."* Then stop and wait.
- **Never** ask the user to paste a secret or API token into the chat.

## Steps

1. Call `list_sites`. If it returns anything (even an empty list), you are already connected —
   go to step 4.
2. If Thryvate's tools are not available at all, the server is not registered yet — add it at user
   scope (so it works in every project), then have the user fully quit and reopen Claude:

   ```bash
   claude mcp add --transport http thryvate https://app.thryvate.com/api/mcp -s user
   ```

3. Once the server is loaded, start the browser flow. When the client surfaces an authorization
   URL, present it as one step: put the raw `https://…` URL on its own line and tell the user to
   **click Authorize** (they choose how long the connection lasts, including *Never expires*). The
   credential is then negotiated machine-to-machine — no token ever enters the chat.
4. Confirm with `list_sites`. An empty list means it works (no sites yet) — offer
   `/thryvate:publish`. A populated list means you're connected. Tell the user they're ready.

## If the Authorize page errors

The redirect lands on a `http://localhost` address handled by Claude Code itself (not Thryvate),
so a "this site can't be reached" page is usually a loopback IPv4/IPv6 mismatch or a timed-out
listener — not a Thryvate failure. Recover in order:

1. Have the user fully quit and reopen Claude, then click the fresh link **promptly** — these links
   expire within a minute or two.
2. If it still errors, the URL now in their address bar
   (`http://localhost:<port>/callback?code=…&state=…`) is still valid — ask them to paste that one
   URL so the client can finish. It is a single-use code, not a reusable secret.

## Token fallback (last resort — only if the browser flow is truly unavailable)

The user creates an API token in the dashboard under **API tokens** (shown once) and runs this in
*their own* terminal, replacing `<token>` — so the secret stays in their shell, never in this chat:

```bash
claude mcp add --transport http thryvate https://app.thryvate.com/api/mcp --header "Authorization: Bearer <token>" -s user
```

`-s user` stores it in the user's own Claude config; never echo, write, or commit it.

## Notes

- The hosted endpoint is `https://app.thryvate.com/api/mcp`. Any client that supports HTTP (Streamable) MCP with
  OAuth works: point it at that URL and approve the browser prompt.
- After setup the credential lives on the MCP connection; `/thryvate:publish`,
  `/thryvate:update`, and `/thryvate:share` never ask for it again.

---
name: workspace
description: Pick which Thryvate workspace (team or personal account) to work in, then create or choose a site.
---

Use this skill to choose which Thryvate workspace you are working in, then create a new site or
pick an existing one to work on. A workspace is either the token owner's personal account or a
team they belong to.

## Steps

1. Call `list_workspaces`. It returns the workspaces this token can act in — the owner's personal
   account plus any teams they belong to — each with a `workspace_id`, a `handle`, and your
   `role` (owner, admin, or member).
2. If there is more than one, show them to the user and ask which to work in. Remember the chosen
   `workspace_id` and pass it as `workspace_id` on every following tool call (`list_sites`,
   `publish_site`, `update_site`, `set_visibility`, and so on). If there is only one, use it
   without asking.
3. Call `list_sites` with the chosen `workspace_id` and show the user the site titles.
4. Ask what they want to do:
   - **Create a new site** → use `/thryvate:publish` (pass the same `workspace_id`).
   - **Work on an existing one** → confirm which title, then use `/thryvate:update` with its site
     id (and the same `workspace_id`), or `/thryvate:share` to change who can view it.

## Notes

- Always carry the chosen `workspace_id` through the rest of the session so work lands in the
  right account. Omit it and every tool acts in the token owner's personal account.
- You can only act in workspaces `list_workspaces` returns; a `forbidden` error for another id
  means the token owner is not a member of it.
- Re-run this skill any time to switch workspaces.

---
name: publish
description: Publish the current document to Thryvate as a live, shareable site.
---

Use this skill to publish something the user just built (an HTML file, a report, a
notebook, a bundle) to Thryvate as a live site with a stable, shareable link.

## Steps

1. Identify the document to publish. If it is a single self-contained HTML file, read it.
   If it is a folder/bundle, zip it (entry document at the root, e.g. `index.html`).
2. Choose a stable, human `slug` derived from the title (e.g. "Q3 Investor Update" →
   `q3-investor-update`). The slug makes publishing idempotent.
3. Call `publish_site` with a `title`, the `slug`, and the bundle. For a single document use
   `html`; for a small zip use `zipBase64`. For a large or multi-file app (a built Vite/React
   site, an image-heavy page) call `create_bundle_upload` first, PUT the .zip to the returned
   `url` (HTTP PUT, `Content-Type: application/zip`), then pass that `upload_id` instead — this
   bypasses the request-body size limit, so size is not a concern.
4. Report the returned `share_url` to the user. Tell them the link is stable: re-running
   this skill with the same slug updates the same site in place — viewers see it live.

## Notes

- New sites default to private (allowlist) on paid plans. Use `/thryvate:share` to open it
  up or add viewers.
- To change an existing site instead of creating a new one, use `/thryvate:update`.
- A multi-file app gets client-side routing for free — clean routes like `/about` deep-link
  and survive a refresh. Build with `BrowserRouter` and a relative base (`base: './'`), and
  derive the router basename from the injected `<base>` tag (`document.querySelector('base')`).

---
name: update
description: Update an existing Thryvate site in place, keeping its URL.
---

Use this skill to change the content of an existing Thryvate site without changing its
URL, visibility, or allowlist.

## Steps

1. Determine the target site. If the user gave a site id, use it. Otherwise call
   `list_sites` and match by title, confirming the right one with the user if ambiguous.
2. Fetch the current content with `get_site_content` (the site id). It returns the entry
   document: `content` as UTF-8 text for HTML/Markdown, or base64 for binary, with
   `encoding` telling you which.
3. Apply the user's requested change to that content. Edit the real current document — do
   not regenerate it from scratch, so wording, structure, and styling are preserved.
4. Save with `update_site` (the site id) passing the edited bundle: `html` (a single
   document), `zipBase64` (a small bundle), or — for a large or multi-file rebuild — an
   `upload_id` from `create_bundle_upload` (PUT the .zip to its `url` first).
5. Confirm: the share URL is unchanged and anyone viewing it refreshes to the new version
   automatically. Mention you can roll back via `list_versions` + `rollback_site`.

## Notes

- `get_site_content` is the read half of the round-trip — always read before you write so
  you patch the live document rather than overwrite it blindly.
- The token is configured on the MCP connection; never request or paste it.

---
name: share
description: Control who can view a Thryvate site — visibility, allowlist, password, and link expiry.
---

Use this skill to manage who can view a Thryvate site and how the link behaves.

## Steps

1. Identify the site (a site id, or resolve by title with `list_sites`).
2. Apply the change the user asked for:
   - **Public vs private**: `set_visibility` with `public` (anyone with the link) or
     `allowlist` (verified viewers only).
   - **Share with more people**: `add_to_allowlist` adds emails and/or domains *without*
     removing anyone already on the list — this is the default for "share with X". Check who is
     already on it first with `list_allowlist` (or `get_site`). Use `remove_from_allowlist`
     to take specific people off, and only reach for `set_allowlist` when the user explicitly
     wants to replace the whole list (it overwrites everyone; an empty list clears it).
   - **Password**: `set_view_password` to protect it, `clear_view_password` to remove it.
   - **Expiry**: `set_link_expiry` with an ISO 8601 timestamp, or null to clear.
3. For private sites, manage pending requests with `list_access_requests` and then
   `approve_access_request` / `deny_access_request`.

## Notes

- Private sharing, allowlists, and passwords are paid-plan features; if a call returns a
  `plan_limit` error, tell the user which plan unlocks it.
- Visibility, allowlist, and password changes never change the share URL.