Update to Mailtea

{
  "description": "Build and restyle a publication's public website with Mailtea from an AI agent — pages, sections, theme, and the design brief that keeps later edits on-brand. Use when the user wants to create or change their Mailtea site (home, about, archive, a landing page), restyle it, or publish it. Pairs with mailtea-email-design, which covers the email side.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 348
    },
    {
      "relative_path": "assets/mailtea-mark.svg",
      "size_in_bytes": 980
    }
  ],
  "name": "mailtea-site-design",
  "skill_md_contents": "---\nname: mailtea-site-design\ndescription: Build and restyle a publication's public website with Mailtea from an AI agent — pages, sections, theme, and the design brief that keeps later edits on-brand. Use when the user wants to create or change their Mailtea site (home, about, archive, a landing page), restyle it, or publish it. Pairs with mailtea-email-design, which covers the email side.\n---\n\n# Mailtea site design\n\nEvery Mailtea publication has one public website: a home page, an archive of\nposts, and whatever else you add. It is edited the same way an email is — a\ndeclarative ops batch against a draft, then a deliberate publish.\n\n**Ops go to the DRAFT.** Real visitors keep seeing the live site until someone\ncalls `site.publish`. That is the safety net, so use it: build, look, fix, and\nonly publish when the user asks. `site.page_upsert` is the exception: it writes\nlive (see Pages).\n\n## The loop\n\n```\nsite.get                 → what exists: pages, theme, live vs draft\nsite.section_templates_list        → the section templates you can insert (use these, don't invent)\nsite.design_brief_set    → the durable intent, once (below)\nsite.apply_ops           → compose / insert / edit / arrange / theme / navbar / rename\nsite.publish             → make it real  ← only when the user asks\n```\n\n`site.discard_draft` throws away **every** pending draft edit across the whole\nsite, including the operator's own unpublished work. Destructive and not\nundoable — confirm before calling it.\n\n## Ops\n\n`site.apply_ops` takes `{pageId, ops, baseVersion}` and reports\nwhat applied and what was skipped, same contract as the email reducer.\n\nEvery site tool also accepts `publicationId`, but it is optional: it defaults to\nthe publication the connection is for. Pass it only when the connection reaches\nmore than one.\n\n| op | what it does |\n|---|---|\n| `compose_page` | Replaces a page's whole section list. |\n| `insert_section` | Adds a template section at `index`, with `copy` for its text slots. |\n| `swap_section` | Replaces one section with a different template, carrying the copy across. |\n| `edit_copy` | Rewrites text: `{edits:[{nodeId, …}]}`. |\n| `edit_style` | One node's `style` / `layout`. |\n| `arrange` | `moves` then `deletes`. |\n| `set_navbar_template` | `templateId` from `site.navbar_templates_list`, optional `brand`. Replaces the navbar. |\n| `rename_nodes` | `renames: [{nodeId, layerName}]`. Layer-tree labels only — nothing a visitor sees. |\n| `set_theme` | Site-wide design tokens. |\n\nSections are addressed by **`nodeId`**, not by index path — ids are stable across\nedits, so unlike the email reducer you can safely hold one across turns. Get them\nfrom `site.page_get`.\n\nPrefer `insert_section` with a **template** over composing raw structure: templates\nare the vocabulary the theme knows how to style, so a template section inherits the\nsite's design and a hand-built one drifts from it.\n\n## Pages\n\n`site.page_upsert` needs `{kind, slug, title}` and optionally\n`status`, `contentJson`, and the SEO fields (`seoTitle`, `seoDescription`,\n`seoOgImageUrl`). Write the SEO fields — a page shared without them gets an ugly\nunfurl, and nobody goes back to add them later.\n\n`site.page_upsert` writes the page's **live** document, not the draft. A\npublished page changes for visitors at once, with no preview. If the page has a\npending draft (`hasDraft` on `site.page_get`), that draft is kept: `site.page_get`\nkeeps returning it, and the next `site.publish` replaces your upsert with it.\nFor edits that should wait for review, use `site.apply_ops`.\n\n## The design brief\n\n`site.design_brief_set` stores the site's durable design intent — audience, tone,\npalette, the feel. Set it **before** a big design pass and every later edit,\nyours or another agent's, has the same reference. Skipping it is why a site drifts\ninto a different look three edits in.\n\n## Images\n\nSame library and the same rules as email:\n\n```bash\nmailtea assets upload --publication-id pub_123 --file ./cover.jpg --width 1600 --height 900\nmailtea assets list --publication-id pub_123\n```\n\nPNG / JPEG / GIF / WebP / SVG, 5 MB max. SVG is fine on a site page: it is\nserved under a sandboxing Content-Security-Policy, so it cannot run script. The\nbytes are checked against the declared content type, so a mislabelled file is\nrejected rather than stored.\n\nUnlike email, a website is a normal web page: real fonts, flexbox and CSS\nvariables are all fine here. Do **not** carry the email-safe contract over — it\nwould make the site needlessly primitive.\n\n## Don't\n\n- Don't publish unless the user asked. Draft is the default for a reason.\n- Don't call `site.discard_draft` to \"clean up\" — it destroys the operator's\n  pending work too.\n- Don't invent section structure when a template exists.\n- Don't hot-link images from another host; upload them.\n- Don't leave a new page without `seoTitle` / `seoDescription`.\n"
}