Ember Websites

View saved version →

---
name: add-ember-images-and-files
description: Add, upload, place, or troubleshoot existing images and downloadable files in an Ember site. Use for any image or static-asset work, especially portfolios, galleries, hero photos, source assets, researched stock photography, PDFs, or favicons. Preserves existing and real work, applies automatic optimization correctly, and covers public paths, truthful use, alt text, scrims, and verification.
---

# Add images and files to Ember

## Success criteria

Image work is complete when every intended visual slot renders a relevant,
high-quality image from a valid non-empty source, uses appropriate alt text,
fits its crop and layout across viewports, and remains truthful about what it
depicts. Keep any working existing image until an equal or better replacement
is ready. A finished site has no unfilled image placeholders. If truthful
imagery is unavailable, remove the unused placeholder or ask for the real
asset instead of presenting an empty frame as completed work.

## Choose a suitable source

Use a direct public HTTPS image URL, including a suitable Unsplash or other
stock URL; an existing path already in the site; or an Ember-managed
asset created with `upload_file`. Choose the option that best fits the request.
Use `upload_file` when a managed copy, optimization, stable local path, or
downloadable non-image asset is useful—not as a requirement for every image.

If calling `upload_file`, pass a complete short, descriptive destination
filename rather than only a directory, especially for signed or opaque source
URLs. Use `referenceInPagesAs` when the result supplies it; otherwise derive the
served path from the reported stored path. A small `data:` URI is suitable only
for compact assets such as an SVG icon.

Save visitor-facing assets under a typed `/public` directory, such as
`/public/images/`, `/public/files/`, or the `/public` root for a favicon. The
served path drops `/public`: reference `/public/files/menu.pdf` as
`/files/menu.pdf`.

Images sent through `upload_file` are resized and re-encoded automatically. The
optimizer may change the filename or extension, so reference the path reported
by the tool rather than the requested path. The MCP server cannot read the
user's local disk; a managed upload requires a publicly retrievable HTTPS URL
or a small data URI.

## Choose truthful existing imagery

Use the user's real portfolio, products, menu, team, location, and other
factual work whenever it is available. For generic atmosphere or editorial
support, use relevant existing stock or editorial photography,
but do not label or imply that it depicts the actual business, products,
people, work, or location. If a factual image is unavailable, remove the unused
placeholder or ask for the real asset rather than inventing one.

## Place assets well

- Give every `<img>` meaningful alt text; use an empty alt only for genuinely
  decorative imagery.
- Place asset sizing, cropping, overlays, and other visual rules in
  `components/theme.ts` using the selected design's tokens and classes.
- Put a scrim between text and any photographic hero/background, and verify
  contrast in light and dark themes.
- Add a favicon link and OG metadata in `PageShell` when the request calls for
  them.
- Use short descriptive filenames instead of camera defaults.

After placing assets, run `check_site` for normal site correctness, then inspect
the already-mounted live preview. Confirm that every intended image renders,
fits its crop and responsive layout, maintains contrast, and has appropriate
alt text. Call `render_preview` again for the final checked state or a fresh
shareable link.

View saved version →

---
name: build-ember-forms
description: Add or improve a working Ember contact, quote, booking, RSVP, survey, application, or other submit-to-the-owner form, or read and manage the form submissions it receives. Use whenever a form must actually submit, or the user asks about submissions, spam, or notification emails. Covers the data-ember-form contract, limits, accessible theme-consistent controls, thank-you routes, spam protection, notification settings, the Forms inbox tools, and plan gating without inventing a custom backend.
---

# Build working Ember forms

Ember turns static form markup into a submission endpoint. Entries appear in
the site's Forms inbox and email the site's configured notification addresses.
Do not add server code, a third-party form service, or a fake success state.

Every valid submission is classified automatically as **spam** or **not spam**.
Spam starts in the Forms view's **Spam** filter, does not count toward the visible
inbox, and does not send notifications. The owner can restore a false positive
with **not spam**; a classifier failure fails open into the visible inbox with
normal notification and appears as **not classified**.
Generic, templated reply-seeking outreach can count as spam even without links
or an explicit sales pitch. Short concrete inquiries and signup/RSVP fields
remain legitimate. Use an accurate page title and meta description, and give
the form an informative `aria-label`: their public copy supplies relevance
context after publishing. Never put private instructions or notification
addresses in that copy.

## Keep distinct workflows distinct

There is no per-site form-count cap and no persistent form-slot registry. The
published manifest is derived from the forms currently rendered by the site.
Give every distinct submit-to-owner workflow its own stable id: for example,
`contact`, `violin-waitlist`, and `spring-recital-rsvp`. Never reuse `contact`
for a waitlist, RSVP, application, quote request, or another unrelated flow to
conserve forms. Separate ids preserve each workflow's structured fields,
thank-you route, and Forms-inbox filtering.

Reuse one id across routes or components only when it is intentionally the same
logical form with the same fields and behavior. `check_site` reports
conflicting definitions. For repeated records such as events, derive the id
from a stable slug (for example, `rsvp-${event.slug}`) and ensure the rendered
value still follows the id rules below. Removing every rendered occurrence of
an id removes that form from the next published manifest; it does not consume a
stale slot, and earlier submissions remain in the site's Forms history.

## Implement the fixed contract

For each distinct form:

- Choose a stable lowercase id using letters, digits, `-`, or `_`, up to 64
  characters.
- Render `data-ember-form="<id>"`, `method="post"`, and
  `action="/__ember/form/<id>"` on the `<form>`.
- Add `data-ember-thanks="/path"` and build that useful, on-brand route.
- Give every stored control a `name`, unique except for one radio group. Add
  fitting `type`, `required`, `maxlength`, `autocomplete`, and `inputmode`
  attributes.
- Add one visually hidden named honeypot with `data-ember-hp`, `tabindex={-1}`,
  `autocomplete="off"`, and `aria-hidden="true"`. Hide it with a class styled
  in `components/theme.ts`, not an inline style.
- Keep each form to 20 stored fields and each submission within 32 KB.
- Do not use file inputs. Avoid repeated-name checkbox groups or multi-selects;
  Ember stores only the first value. A radio group safely submits one value.
- Preserve native POST, browser validation, the no-JavaScript path, and the
  thank-you redirect. Do not intercept submission with React `onSubmit` or a
  custom `fetch()`. Use the static lowercase `onsubmit` busy handler below.

Use this exact progressive-enhancement behavior so a valid submit disables the
button, sets `aria-busy`, changes its label, and guards against double submits
without replacing th

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: build-ember-sites
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.
---

# Build and edit Ember sites

Own the complete workflow when the user asks in ordinary language. Do not make
them name Ember, provide tool steps, repeat identifiers, or say “continue.” Keep
tool mechanics out of user-facing prose unless recovery requires them.

Read `references/authoring.md` before the first file write in a new site or when
the file, design, or verification contract is not already active. Read
`references/product-boundaries.md` before answering whether Ember supports a
kind of site, feature, plan, account action, or publishing behavior.

## Route specialist work

Use this skill for the overall site workflow and also use:

- `structure-ember-content` before authoring any repeated set with two or more
  records, even if it is a fixed row with no detail pages;
- `build-ember-forms` for any form that must submit to the site owner;
- `add-ember-images-and-files` for uploads, downloads, researched imagery,
  portfolios, galleries, hero photos, or other static assets; and
- `import-sites-to-ember` when rebuilding an existing website or online
  business presence.

## Make decisions and show progress

Use the request and conversation as the brief. Ask only genuinely blocking
questions in the host chat; otherwise make sensible content and structure
decisions and author directly. Ember provides no questionnaire.
Never invent real business facts, credentials, prices, testimonials, contact
details, or claims. Use supplied or researched facts and surface material
unknowns.

Keep the live preview visible. Immediately after the studio applies a design, call
`render_preview` before any file read or write. That mounts the embedded working
tree while the build is still in progress; later file mutations reach the same
view through Ember's live-update channel. Call `render_preview` again after
meaningful checked phases, after the final clean check, and whenever the user
asks to see it. Do not render unchanged state twice or render after every
individual file write. When the user asks for a link to the unpublished draft,
or the host cannot render the embedded view, share the `previewUrl` that
`render_preview` returns — a short-lived authenticated link to the working tree;
when it expires, call `render_preview` again for a fresh one. Never invent a
preview address: the only shareable draft link is the one the tool returned.
The embedded preview's Refresh button requests a fresh authenticated link.
If it asks the user to show the preview again, call `render_preview` in chat.

When starting a new site, call `create_site` with an appropriate name derived
from the request. It creates the account resource only. Then call
`open_design_studio` exactly once with the returned site id and the shortest
useful search term for the site type, usually 1–3 words. This opens the studio
on relevant layouts instead of an unrelated default; the studio remains the
user's visual choice. Do not call `search_designs` separately while the studio
is mounted because the studio owns its in-place search updates.

The user may select an element in Ember's Live preview before asking for a
change. The conversation then carries a “[Selected element from the preview]”
block naming the site id, page, element, and usually a `Source` file and line.
Treat “this”, “here”, or an unqualified change as applying to that element: read
the named source file, edit that element (or the component it lives in), and
leave the rest of the page alone. The CSS selector and text only confirm which

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: import-sites-to-ember
description: Rebuild or migrate an existing website, Google Business profile, social profile, or other online business presence into Ember. Use when the user asks to import, recreate, migrate, modernize, or improve an existing site. Preserves verified identity, content, navigation, branding, forms, social links, locations, and source images while adapting them to Ember's design system and static-site boundaries.
---

# Import an existing presence into Ember

Rebuild the source in Ember; do not pixel-clone its layout. Preserve the
source's purpose, verified identity, information architecture, substantive
content, branding, and real assets inside the selected Ember design. Never
invent missing facts or testimonials.

Use the `build-ember-sites` workflow for account preflight, site creation, the
interactive design studio, batching, checks, previews, and publishing. Also use
`structure-ember-content`, `build-ember-forms`, and
`add-ember-images-and-files` wherever their triggers apply.

## Inventory before authoring

Build a migration manifest before creating or editing an Ember site. This is a
hard gate: do not select/apply a design or author pages, components, content,
configuration, or public assets until the manifest is complete. Start with
`sitemap.xml` when available, then follow every same-origin link reachable from
navigation and page bodies. Record each source URL and destination route,
title and metadata, navigation position, substantive copy, contact facts, form
behavior, download, and image. Preserve source paths when Ember can represent
them; record every intentional exclusion.

The manifest must include all of the following:

- Desktop, tablet, and mobile captures, with viewport dimensions and source
  URL. If a full-page capture is unreadable, use viewport and section captures
  rather than inferring what it contains.
- A source-order section geometry inventory: approximate heights, container
  widths, columns, alignment, image/text placement, major spacing, and how
  those relationships change across the three viewports.
- An asset inventory covering logo, favicon, every meaningful `<img>`,
  `picture`/`srcset` candidate, CSS background, carousel slide, gallery item,
  factual team/product/location image, and download. Record role, source page,
  exact candidate URLs, selected highest-suitable original, alt/caption,
  intended Ember reference, and status. Enumerate every carousel/gallery state,
  not only the item visible during capture.
- An interaction inventory covering desktop/mobile navigation, sticky or
  overlay headers, anchors, carousels, tabs/accordions, buttons and links,
  forms and validation, maps, embeds, downloads, and unsupported behavior.
- Reconciliation totals for pages, sections, assets, forms, social links,
  maps, downloads, and interactions, with a named exception for every gap.

When the site exists, persist this working checklist as
`/.ember/import-manifest.md` before authoring so subsequent passes can reconcile
against the same evidence. Do not claim discovery is complete while a count is
unknown or an observed source element has no manifest row.

Use the host's available browsing or user-provided material to inventory all
in-scope pages, navigation order and hierarchy, headings, copy, offerings,
prices, identifiers, contact details, locations, hours, forms, social links,
logo, fonts, colors, and meaningful images. Preserve a multi-page source as
real pages rather than flattening navigation into anchors; keep a genuinely
single-page source single-page.

If the source cannot be inventoried, do not create or edit an Ember site. State
exactly what is missing and ask for a reachable URL, site export,
screenshots/assets, or explicit approval for a partial migration. If sources
conflict, surface the conflict and ask rather than choosing or inventing a
fact. Do not fill unknown business facts with plausible prose.

## Rebuild faithfully

- Keep the verified busines

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: structure-ember-content
description: Structure repeated authored content in an Ember site as independently editable Markdown collection entries. Use before building any set with two or more similar records, including products, dishes, services, events, projects, team members, reviews, FAQs, pricing, schedules, values, stats, posts, or fixed rows without detail pages. Prevents domain-content arrays and keeps additions data-only.
---

# Structure Ember content collections

Use a content collection for every set of two or more independently editable,
similarly shaped records. Fixed showcases qualify; entries do not need detail
pages or expected future growth. Navigation, footer links, decorative UI
mechanics, and attributes unique to one record may remain in code or config.

## Choose the presentation

- Use list-only entries for FAQs, services, team cards, menu dishes, hours,
  reviews, values, pricing rows, and similar records without their own URL.
  Do not add detail routes unless the user needs directly linkable or long-form
  records.
- Use list plus detail pages for long-form or directly linkable entries.

Use a separate collection for each repeated set with a different record shape
or purpose. For example, put services in `content/services/*.md` and pricing
plans in `content/plans/*.md`; do not combine them merely because they share a
page. For a pricing table, each plan is one record. Keep inseparable feature
bullets as a YAML array on that plan; do not make table cells or feature rows
separate entries unless they are independently authored records.

Before building, inspect `/content`, `/lib/content.ts`, and the relevant pages
and components. Reuse the selected design's rendering pattern, but move
qualifying authored records out of code even when demo files use arrays. Make
one content-model pass across the whole requested scope before authoring:
enumerate every repeated set, assign its collection and typed frontmatter
shape, classify it as list-only or list plus detail, and decide whether it
genuinely needs a Markdown body. Do not introduce a second inline content
system later in the build.

## Define the data contract

Create one `content/<collection>/<slug>.md` file per record. Put structured
values in YAML frontmatter and primary long-form prose after the closing `---`.
Use consistent field names and types, a stable `title` or `name`, `order` when
sequence matters, and only the fields the presentation needs: category, price,
role, date, rating, attribution, image, alt text, and so on. Quote ambiguous
YAML strings.

If a list-only record needs only short plain text, use a named frontmatter
field and leave the Markdown body empty; never author body prose that no
renderer consumes.

A repeated child with its own title/label and value is a record, not an array
inside a parent. Give each child an entry and group it with metadata such as
`category`. Nested arrays are only for inseparable attributes, such as one
plan's feature bullets. Put featured/pinned status and group order in entry
metadata, never in title allowlists in a page.

For a list-only collection, load every slug and sort the loaded entries by
metadata:

```ts
listEntries("services")
  .map((slug) => loadEntry<ServiceFrontmatter>("services", slug))
  .sort((a, b) => a.order - b.order)
```

Use the actual collection name and define a separate typed frontmatter contract
for each collection. `loadEntry` returns typed frontmatter plus `bodyHtml`.
That value is already rendered HTML, not raw Markdown or plain text: pass it to
the design's `<Prose html={entry.bodyHtml} />` component. Never place it
directly in JSX text, wrap it in `<p>`, escape it, or parse it again.

For details, use `pages/<collection>/[slug].tsx`, derive `getStaticPaths()`
from `listEntries`, and handle unknown slugs. Adding an entry must not require
editing route or component code.

## Verify

Build one representative entry and its real list/card/detail renderer first,
then run `check

Preview of the first 4,000 characters. Read full instructions →