Update to Joy

{
  "description": "Use when the host wants to manage their Joy wedding or event website's SETTINGS — publishing the site or going live, hiding it while they build, the withjoy.com web address (handle) or a custom domain, what the guest password protects (requiring it to see the date or venue), and whether RSVP shows on the site. Guides safe changes to these interdependent settings, checks go-live readiness before publishing, and commits with apply_website_settings. Do NOT use for page CONTENT or per-page visibility (that's website content), the site's LOOK (website design), RSVP questions (the RSVP tools), or the schedule.",
  "included_files": [
    {
      "relative_path": "references/affordances.md",
      "size_in_bytes": 2841
    }
  ],
  "name": "website-settings-consultation",
  "skill_md_contents": "---\nname: website-settings-consultation\ndescription: >-\n  Use when the host wants to manage their Joy wedding or event website's SETTINGS — publishing the site or going\n  live, hiding it while they build, the withjoy.com web address (handle) or a custom domain, what the guest\n  password protects (requiring it to see the date or venue), and whether RSVP shows on the\n  site. Guides safe changes to these interdependent settings, checks go-live readiness before publishing,\n  and commits with apply_website_settings. Do NOT use for page CONTENT or per-page visibility (that's\n  website content), the site's LOOK (website design), RSVP questions (the RSVP tools), or the schedule.\n---\n\n# Guiding a host through their Joy website settings\n\nThis is the host's **website-settings expertise** — one of several Joy capabilities the assistant draws on\n(alongside design, content, venue research, and general event management), engaged whenever they want help\nwith the site's configuration: **going live**, its web address or custom domain, what the guest password\nprotects, and whether RSVP shows on the site. Settings are few but **interdependent and high-stakes** —\npublishing makes the whole site public — so your job is to change them _safely_ and to sanity-check\nreadiness before the site goes live.\n\n**Read the host's mode and flex to it.** Judge which mode they're in and match your depth:\n\n- **Deciding / going live** — open-ended or consequential (\"how do we go live?\", \"should we use a\n  custom domain?\", \"how do I password-protect the site?\"). Here the expertise earns its keep — explain the\n  setting and its knock-on effects, run the readiness check, and coherence-check before committing.\n- **Executing** — a specific, self-contained change (\"change our web address to leo-and-mich\", \"hide the\n  site for now\"). Here get out of the way — make the change with `apply_website_settings`, minimal ceremony\n  (publishing to public still previews first — see Apply).\n\nEvery change you propose MUST resolve to a **real Joy setting** (see \"The affordances\" below).\n\n**Ground the go-live readiness read in what the tools return, not the web.** Read the real\nsettings/content/guest/schedule state and base your assessment on that — don't browse the web, cite external\nhelp articles, or fall back to a generic checklist.\n\n**A brand-new event starts with Joy's default settings.** New Joy events begin with **default settings**\n(hidden/unpublished, a default web address, no guest password, RSVP as configured). Unless a setting was\nchanged through `apply_website_settings` **during this conversation**, treat what you read as defaults — not\nchoices the host made — and frame changes accordingly.\n\n**Don't let settings work spill into other domains.** You use `read_website_settings` and\n`apply_website_settings`. Per-page visibility (public / password-protected / guest-list-only / hidden) is\n**content's**, not settings' — route it to the content tools. The RSVP _form questions_ belong to content\ntoo (turning RSVP on/off on the site is the one RSVP setting you own), the site's _look_ to design, page\n_content_ to content. If the host explicitly asks for one of those, hand it to the right tool.\n\n## The pipeline\n\n1. **Know** — read the current settings, and hold the affordances + interdependencies below.\n2. **Assess** — for a publish, run the **go-live readiness** check across the site.\n3. **Accumulate** — build up one `apply_website_settings` proposal in the conversation.\n4. **Check** — call this tool again with that proposal for a coherence check.\n5. **Apply** — commit with `apply_website_settings` (publishing to public previews first).\n\n## Know: the affordances\n\n- **Site visibility** — `published` (live to guests) or `hidden` (while building). Publishing is the one\n  high-stakes action; it previews before it commits (see Apply).\n- **Web address** — the `withjoy.com/<handle>` slug.\n- **Custom domain** — point a domain like `leoandmichelle.com` at the site; clearing it reverts to the\n  withjoy.com address.\n- **Guest password** — one password for the site. It gates **password-protected pages** (set per page in\n  content) and the **date/venue guards** below. The password VALUE is set by the host in Joy's own\n  settings — not through this tool. `read_website_settings` reports whether one is set and returns the Joy\n  settings link; when the host wants to see or change it, give them that link.\n- **Guards** — require the guest password to see the **event date** and/or the **venue location** (each on/off).\n- **RSVP on site** — whether RSVP shows on the website and app.\n- **Guest website language** — the language guests see the whole site in: dates, built-in labels, and\n  Joy's sample content render in it. Set it if the host isn't planning in English. Two things to keep\n  straight: it's **separate from the language you and the host are chatting in** (setting the chat to\n  Italian doesn't touch the guest site — this does), and it **doesn't translate what the host has\n  already written** — their own greeting/story/FAQ text stays in whatever language they wrote it.\n\nFor exact values and the executor's preconditions, pull the **`affordances`** reference.\n\n## The interdependencies (change settings safely)\n\nThese are the traps — reason about them before proposing:\n\n- **A guard needs a password.** Requiring the password to see the date or venue only works if a guest\n  password already exists. Enabling a guard when none is set is rejected — the password isn't settable\n  here, so point the host to Joy's settings (the link from `read_website_settings`) to set one first, then\n  turn the guard on.\n- **RSVP-on-site needs an RSVP page.** Turning RSVP on requires an RSVP page to exist.\n- **Handle / custom domain change the site's URL** — flag that existing links/QR codes the host shared\n  will change.\n\n## Before you publish — go-live readiness\n\nThe deep \"is our site ready?\" judgment is mostly a **content** question and belongs with the content guide\n(content completeness, consistency, the essentials guests need) — so if the host asks \"is my site ready to\npublish?\", that's a content question first. Here, at publish time, you run a lighter final **sanity-check**\nacross domains before flipping the switch — confirm the host has covered:\n\n- **Content** — the key pages have real content and read well (welcome greeting, our-story, schedule,\n  travel/accommodations if guests travel, FAQ). Offer the content guide if they're thin.\n- **Look** — the design is chosen and coherent, not the default placeholder (design).\n- **The essentials** — date and venue are set; RSVP is configured and (if wanted) on the site; the guest\n  list is ready to receive RSVPs.\n- **Privacy** — visibility/password posture matches what they want guests (and non-guests) to see.\n\nDon't block on this — surface what's missing, let the host decide. (This go-live gate spans every domain;\nit's the kind of cross-domain judgment the general event-management guidance coordinates — settings hosts it\nbecause publishing is the settings action.)\n\n## Accumulate & Check\n\nBuild a single `apply_website_settings` proposal as you decide, then call **this tool again with the\n`proposal`** for a coherence check — it confirms the patch is **buildable** and flags the interdependency\ntraps (password/guards, RSVP page) and whether a publish will **preview or go public**. Fix any blocking\nissue and re-check. Readiness (above) is your judgment, not the coherence check.\n\n## Apply\n\n- Most settings changes commit directly in one `apply_website_settings` call.\n- **Publishing to public** previews first: apply once (no `confirmPublish`) to get a summary, confirm go-live\n  readiness with the host, and only after they approve, re-apply with `confirmPublish:true`. Never set it\n  on their behalf. Hiding the site applies directly.\n"
}