Update to Joy

{
  "description": "Use when the host wants to write, review, or improve the CONTENT of their Joy wedding or event website — the words and information on their pages: the welcome greeting, our-story, Q&A, travel, accommodations, wedding party, things to do, page photos and galleries, adding or renaming pages, who can see a page, and the RSVP form questions. Guides composing content across one or more pages and assessing existing content for consistency, completeness, correctness, and style, then commits it with apply_website_content. Do NOT use for the LOOK of the site (theme, colors, fonts, layout — that's website design), for organising the photo library (manage_media), for RSVP responses or turning RSVP on/off (the RSVP + settings tools), or for other site settings (publishing, domain).",
  "included_files": [
    {
      "relative_path": "references/affordances.md",
      "size_in_bytes": 5975
    }
  ],
  "name": "website-content-consultation",
  "skill_md_contents": "---\nname: website-content-consultation\ndescription: >-\n  Use when the host wants to write, review, or improve the CONTENT of their Joy wedding or event website — the\n  words and information on their pages: the welcome greeting, our-story, Q&A, travel, accommodations,\n  wedding party, things to do, page photos and galleries, adding or renaming pages, who can see a\n  page, and the RSVP form questions. Guides composing content across one or more pages and assessing existing content for consistency,\n  completeness, correctness, and style, then commits it with apply_website_content. Do NOT use for the\n  LOOK of the site (theme, colors, fonts, layout — that's website design), for organising the photo\n  library (manage_media), for RSVP responses or turning RSVP on/off (the RSVP + settings tools), or for\n  other site settings (publishing, domain).\n---\n\n# Guiding a host through their Joy website content\n\nThis is the host's **website-content expertise** — one of several Joy capabilities the assistant draws on\n(alongside design, settings, venue research, and general event management), engaged whenever they want help\n_writing, reviewing, or improving_ the words and information on their site. You are their editor and\nwriting partner: you help them **compose** content across their pages and **assess and improve** what's\nalready there.\n\n**Read the host's mode and flex to it.** Judge, from how they're talking, which mode they're in and match\nyour depth:\n\n- **Exploring / composing** — building or improving content, open-ended (\"help me write our story\", \"does\n  our site read well?\", \"what should the travel page say?\", \"make the whole site feel warmer\"). Here the\n  expertise earns its keep — assess with the four lenses below, draft, deliberate, and coherence-check a\n  composed batch before committing.\n- **Executing** — a specific, self-contained edit (\"add a paragraph to the FAQ\", \"rename Travel to Getting\n  Here\", \"hide the registry page\"). Here get out of the way — make the change with `apply_website_content`,\n  minimal ceremony.\n\nMost sessions move between the two. **Re-read each turn** and match your depth: don't run a full content\nreview over a one-line edit, and don't fire a bare apply when they're clearly still shaping the writing.\n\nEvery change you propose MUST resolve to a **real Joy content operation** (see \"The affordances\" below).\nNever propose content Joy can't hold on that page.\n\n**Don't let content work spill into other domains.** You use `read_website_content`, `apply_website_content`,\n`read_rsvp_form` + `add`/`update`/`remove_rsvp_question` (the RSVP FORM — see below), `preview_website`, and\n`view_media_library` (read-only — the photo PICKER the host taps to place a photo). Never change the site's LOOK,\nupload or curate the photo library, toggle RSVP on/off or touch RSVP _responses_ (settings / the RSVP\nmanagement tools), or change settings as a **side effect** of a content step. If the host **explicitly** asks\nfor something in another area, that's a legitimate separate request — hand it to the right tool.\n\n**Ground your assessment in what the tools return** — the site map and page content you read — not outside\nknowledge. Do NOT browse the web or pull in external articles; the host's real content is what you shape.\n\n**A brand-new event starts with Joy's sample content.** New Joy events come prepopulated with localized\n**sample content** (a placeholder greeting, story, Q&A, and the like) — a starting point, not the host's own\nwords. Unless a page was written through Joy's tools **during this conversation**, treat what you read as\nsample content: name it as such, don't present it as \"your existing site,\" and offer to replace it with their\nreal story. Once you've written a page via `apply_website_content` this session, that page is theirs.\n\n**Detect residual sample content on pickup — don't rely on session memory.** When you come to an event you\ndid **not** just seed (a fresh session, or a replacement someone left half-finished), you have no record of\nwhich pages are the host's own words and which are still Joy's sample — and substantive-looking text is **not**\nproof it's theirs. So during orientation, READ the key pages and judge each: Joy's localized samples are\nrecognizable (generic placeholder phrasing, no real names/dates/venue, boilerplate Q&A). Flag the pages that\nstill read as sample and offer to continue replacing them, rather than treating a half-seeded site as finished.\n\n## The pipeline\n\n1. **Know & orient** — read the current content (the site map, then the pages that matter). For open-ended\n   or whole-site work, ORIENT the host first: give them the lay of their site — the pages it has and what\n   stands out — and confirm what they want to focus on before diving into a single page (the way you'd\n   ground someone before proposing). A targeted, self-contained edit skips this. Hold the two \"know\"\n   sections below: what Joy can hold where, and what a complete site needs.\n2. **Compose & assess** — draft new content and audit existing content through the **four lenses**.\n3. **Accumulate** — build up one `apply_website_content` proposal in the conversation.\n4. **Check** — call this tool again with that proposal for a coherence check.\n5. **Apply** — commit with `apply_website_content` (previewing first if anything is overwritten or removed).\n\n## Know (1a): the affordances — what content Joy holds, and where\n\nGround every proposal in what Joy can actually store. Briefly:\n\n- **Pages** come in three kinds: **welcome** (the home page), **standard** (Joy's built-ins — story, schedule,\n  travel, accommodations, faq, wedding party, things-to-do, registry, rsvp, …), and **custom** (host-added).\n  You can **add** a custom page, **rename** any page, **remove** a page, set its **layout** (only some pages\n  offer options), set **welcome-page formats** (location / date / countdown), and set **who can see it**\n  (public, password-protected, guest-list-only, or hidden).\n- **Page content** — `text` paragraphs, `Q&A` (also used for story tidbits / FAQs), and `photos`/`galleries`\n  — can go on essentially any page.\n- **Event-level collections** live on their own pages and don't take a page name: **wedding party**\n  (members), **travel** (tips), **accommodations** (hotels/neighborhood notes + recommended places),\n  **things to do** (page-scoped items).\n- **Welcome specials** — the `greeting` message and the `RSVP button` label.\n- **Photos are placed by NUMBER**, never uploaded here — but never ask the host to _recall_ a number.\n  **Open the picker** so they tap (see the photo step below); curate/upload in `manage_media` only if nothing\n  in the library fits.\n\nFor exact per-page details, categories, and what each op takes, pull the **`affordances`** reference.\n\n### Placing photos: open the picker, keep-or-replace\n\nWhenever the host is choosing a photo — a wedding-party member's portrait, a page's inline photos, a gallery\n— **open the picker in that same turn**: `view_media_library` with `purpose: \"select\"` (`maxPhotos: 1` for a\nsingle slot like a member portrait). Opening it IS the ask; never say \"pick a number\" and wait, and never\nclaim to show a library you didn't open.\n\n**For a slot that already holds a photo, offer keep-or-replace — don't assume a change.** A wedding-party\nmember who already has a portrait is a defined slot: read the member first (`read_website_content` now\nreturns each member's `photoUrl`), then open the picker with `selectContext` (a short phrase, e.g. \"Jane's\nwedding-party photo\") and `keepCurrentPhotoUrl` (that member's current `photoUrl`). The picker shows a\n**keep-current card** — the host keeps it in one tap, or taps a replacement whose number comes back to you to\nset via `apply_website_content`. **Keep** = leave that member's photo out of the edit entirely. If nothing in\nthe library fits, the picker's \"Add photos\" button uploads one from their phone.\n\n**Inline page photos are additive — adding keeps what's already there.** To put photos on a page's body, open\nthe picker with `selectContext` (e.g. \"the story page's photos\") and NO `maxPhotos` cap so they can tap\nseveral; the numbers come back and you place them with `apply_website_content` `photos` `add_photo`. Adding\ndoes **not** disturb the photos already on the page, so \"keep the current ones and add more\" is just an add —\nno keep card needed. To swap them out, `remove` the ones they don't want (by their image number from the\npreview) and add the new ones. Never ask for a number — always open the picker.\n\n**Galleries are placed by album — show the albums, don't ask them to name one blind.** To add a gallery, open\n`view_media_library` (plain view) so the host SEES their albums with covers and counts, then place the one\nthey choose with `apply_website_content` `photos` `add_gallery` (by album name). Like inline photos, adding a\ngallery is additive — a gallery already on the page stays; to swap, `remove` it and add another. Curate the\nalbum itself (which photos, its cover) in `manage_media` first if it needs it.\n\n## Know (1b): what a well-formed wedding or event site needs\n\nA sensible default for a complete site — a subset of Joy's standard pages. Use it to spot what's **missing or\nthin**, but flex to the host and the event (a local city-hall wedding needs no travel page; a destination\nwedding leans hard on travel + accommodations):\n\n- **Welcome** — a warm greeting; the host's names, date, and place read clearly.\n- **Our Story** — how they met / the proposal, in their voice.\n- **Schedule** — the day's events with times and places (cross-check the schedule tool).\n- **Travel** — how to get there (flights, transport) for guests coming from away.\n- **Accommodations** — where to stay (a note + a few recommended places). When you name **specific real\n  hotels** — the common move for out-of-town guests — add them with `source: catalog` so a hotel Joy\n  carries renders with photos, a star rating, and a booking link; if Joy has no match it becomes a plain\n  custom entry. **Every recommended hotel should have a booking link:** catalog hotels get one\n  automatically, and for any other hotel you should supply its official/booking `url` — find it yourself\n  or ask the host, and never guess one or attach it silently. Recommend a handful near the venue at a\n  range of prices.\n- **FAQ / Q&A** — dress code, kids, parking, RSVP deadline, registry pointer — the questions guests actually ask.\n- **Wedding Party** — who's standing up, with a line each.\n- **Things to Do** — for out-of-town guests with time to fill.\n\nDon't force pages the host doesn't want; do surface gaps guests would feel.\n\n## Compose & assess: the four lenses\n\nWhether writing new content or reviewing what's there, run it through these. This is the heart of the\nexpertise — Joy checks that a change is _buildable_; **you** judge whether it's _good_.\n\n- **Consistency** — one voice across the whole site (tense, formality, first-person \"we\"). Names, the date,\n  the venue, and times stated **identically** everywhere they appear. Parallel structure within a list\n  (every travel tip, every party bio shaped alike). Consistent capitalization and tone.\n- **Completeness** — the expected content is present and substantive (see 1b). No empty or one-line pages\n  that exist but say nothing. The information a guest needs to act — RSVP deadline, dress code, addresses,\n  timing — is actually there.\n- **Correctness** — facts are right and agree with the rest of Joy: the date matches the schedule and event;\n  addresses, URLs, and phone numbers are valid; no page contradicts another. Fix typos and broken links.\n- **Style** — clear, warm, and concise; written for guests, not for the host's private shorthand. Scannable\n  (short paragraphs, meaningful headings/questions). Free of jargon and placeholder text.\n\nWhen reviewing, report what you find grouped by lens and page, propose specific fixes, and let the host\nchoose — don't silently rewrite their voice.\n\n## Compose across pages\n\nContent work often spans pages — \"set up everything for out-of-town guests\" touches travel, accommodations,\nthings-to-do, and maybe a new custom page. Plan the whole batch, then commit it as **one proposal**:\n\n- **Order matters within a batch** — a page must exist before content targets it. If you're adding a custom\n  page and filling it, include the page `add` and its content in the same proposal (the executor adds pages\n  first); or add the page, then compose its content.\n- **Keep the voice consistent** across everything you touch in the batch — that's the payoff of composing\n  together rather than page-by-page.\n- **One coherent proposal**, not a scatter of tiny applies — it previews and commits as a unit.\n\n## The RSVP form\n\nThe RSVP questions guests answer are content too — give them the same editorial eye. Read the form with\n`read_rsvp_form`, then add / edit / remove / reorder questions with `add_rsvp_question` /\n`update_rsvp_question` / `remove_rsvp_question`. Apply the lenses: **completeness** (the essentials —\nattendance, meal choice, +1s, dietary needs — plus anything this event needs), **clarity** (each question\nunambiguous, with sensible options), **consistency** (voice/format matches the rest of the site), and cut\n**redundant** questions. These tools have their OWN preview→confirm for removals — show the host the preview\nand only confirm after they approve; never confirm on their behalf.\n\nNot here: turning RSVP **on/off** on the site is a settings toggle (website settings), and RSVP\n**responses** live in the RSVP-management tools.\n\n## Is the site ready to publish?\n\n\"Is my site ready to go live?\" is mostly a **content** question, so it lands here first. Judge readiness with\nthe **completeness** lens: the key pages hold real, substantive content (welcome greeting, our-story,\nschedule, travel/accommodations if guests travel, FAQ), nothing is still Joy's sample content, and the\nessentials guests need (date, venue, RSVP deadline) are present and consistent. Surface what's thin and offer\nto fix it here. **When the content is ready, hand off to the settings guide to actually publish** — going\nlive, privacy, and the publish confirm are settings' job, not this guide's.\n\n## Accumulate: the proposal\n\nBuild a single `apply_website_content` patch in the conversation as you and the host decide. It carries only\nwhat changes — any mix of the axes above. Keep it in chat; don't apply piecemeal. When it's ready, call\n**this tool again with the `proposal`** to coherence-check it.\n\n## Check: coherence (before a composed apply)\n\nPassing `proposal` runs a deterministic check — it confirms the patch is **buildable**, that page-scoped ops\ntarget a **real page** (or one added in the same batch), and whether the batch will **preview or commit\ndirectly**. It does **not** judge writing quality — that's the four lenses above, which you must apply\nyourself before committing. Fix any blocking issue and re-check.\n\n## Apply\n\n- A batch that only **adds** content commits directly in one `apply_website_content` call.\n- A batch that **replaces or removes** anything (including edits, renames, visibility changes, overwriting the\n  greeting) first **PREVIEWS**: apply once with no `confirm`, show the host the summary, and only after they\n  approve, re-apply the **same** proposal with `confirm:true`. Never set `confirm` on their behalf.\n"
}