Update to Ember Websites

{
  "description": "Build, edit, restyle, fix, preview, publish, or answer capability questions about Ember content sites through the Ember MCP tools. Use for every Ember site-authoring request. Covers design-first setup, static JSX constraints, file layout, token-only styling, the check loop, preview cadence, product boundaries, and safe publishing. Combine it with the relevant specialist Ember skill when collections, forms, images/files, or an import are involved.",
  "included_files": [
    {
      "relative_path": "references/authoring.md",
      "size_in_bytes": 12479
    },
    {
      "relative_path": "references/product-boundaries.md",
      "size_in_bytes": 3002
    }
  ],
  "name": "build-ember-sites",
  "skill_md_contents": "---\nname: build-ember-sites\ndescription: Build, edit, restyle, fix, preview, publish, or answer capability questions about Ember content sites through the Ember MCP tools. Use for every Ember site-authoring request. Covers design-first setup, static JSX constraints, file layout, token-only styling, the check loop, preview cadence, product boundaries, and safe publishing. Combine it with the relevant specialist Ember skill when collections, forms, images/files, or an import are involved.\n---\n\n# Build and edit Ember sites\n\nOwn the complete workflow when the user asks in ordinary language. Do not make\nthem name Ember, provide tool steps, repeat identifiers, or say “continue.” Keep\ntool mechanics out of user-facing prose unless recovery requires them.\n\nRead `references/authoring.md` before the first file write in a new site or when\nthe file, design, or verification contract is not already active. Read\n`references/product-boundaries.md` before answering whether Ember supports a\nkind of site, feature, plan, account action, or publishing behavior.\n\n## Route specialist work\n\nUse this skill for the overall site workflow and also use:\n\n- `structure-ember-content` before authoring any repeated set with two or more\n  records, even if it is a fixed row with no detail pages;\n- `build-ember-forms` for any form that must submit to the site owner;\n- `add-ember-images-and-files` for uploads, downloads, researched imagery,\n  portfolios, galleries, hero photos, or other static assets; and\n- `import-sites-to-ember` when rebuilding an existing website or online\n  business presence.\n\n## Make decisions and show progress\n\nUse the request and conversation as the brief. Ask only genuinely blocking\nquestions in the host chat; otherwise make sensible content and structure\ndecisions and author directly. Ember provides no questionnaire.\nNever invent real business facts, credentials, prices, testimonials, contact\ndetails, or claims. Use supplied or researched facts and surface material\nunknowns.\n\nKeep the live preview visible. Immediately after the studio applies a design, call\n`render_preview` before any file read or write. That mounts the embedded working\ntree while the build is still in progress; later file mutations reach the same\nview through Ember's live-update channel. Call `render_preview` again after\nmeaningful checked phases, after the final clean check, and whenever the user\nasks to see it. Do not render unchanged state twice or render after every\nindividual file write. When the user asks for a link to the unpublished draft,\nor the host cannot render the embedded view, share the `previewUrl` that\n`render_preview` returns — a short-lived authenticated link to the working tree;\nwhen it expires, call `render_preview` again for a fresh one. Never invent a\npreview address: the only shareable draft link is the one the tool returned.\nThe embedded preview's Refresh button requests a fresh authenticated link.\nIf it asks the user to show the preview again, call `render_preview` in chat.\n\nWhen starting a new site, call `create_site` with an appropriate name derived\nfrom the request. It creates the account resource only. Then call\n`open_design_studio` exactly once with the returned site id and the shortest\nuseful search term for the site type, usually 1–3 words. This opens the studio\non relevant layouts instead of an unrelated default; the studio remains the\nuser's visual choice. Do not call `search_designs` separately while the studio\nis mounted because the studio owns its in-place search updates.\n\nThe user may select an element in Ember's Live preview before asking for a\nchange. The conversation then carries a “[Selected element from the preview]”\nblock naming the site id, page, element, and usually a `Source` file and line.\nTreat “this”, “here”, or an unqualified change as applying to that element: read\nthe named source file, edit that element (or the component it lives in), and\nleave the rest of the page alone. The CSS selector and text only confirm which\nelement was meant; never edit by selector.\n\nFinish every mutation batch with `check_site`, fix every reported error, and\nrepeat until clean. Call `publish_site` only when the user explicitly asks to\npublish. Confirm before deleting a site or any user-authored/irreplaceable file.\nRemoving obvious selected-design demo files during an authorized build needs\nno separate confirmation.\n\nFor an explicit undo, revert, or “go back to that turn” request, call\n`list_checkpoints` for the site, select the exact `turnId` matching the user's\nrequested point, then call `rollback_site`. Never invent or shorten the id.\nMCP working-tree mutations create these checkpoints automatically. A rollback\nis itself recoverable in Ember, but it does not erase the external host chat.\n"
}