Update to Ember Websites

{
  "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.",
  "included_files": [],
  "name": "structure-ember-content",
  "skill_md_contents": "---\nname: structure-ember-content\ndescription: 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.\n---\n\n# Structure Ember content collections\n\nUse a content collection for every set of two or more independently editable,\nsimilarly shaped records. Fixed showcases qualify; entries do not need detail\npages or expected future growth. Navigation, footer links, decorative UI\nmechanics, and attributes unique to one record may remain in code or config.\n\n## Choose the presentation\n\n- Use list-only entries for FAQs, services, team cards, menu dishes, hours,\n  reviews, values, pricing rows, and similar records without their own URL.\n  Do not add detail routes unless the user needs directly linkable or long-form\n  records.\n- Use list plus detail pages for long-form or directly linkable entries.\n\nUse a separate collection for each repeated set with a different record shape\nor purpose. For example, put services in `content/services/*.md` and pricing\nplans in `content/plans/*.md`; do not combine them merely because they share a\npage. For a pricing table, each plan is one record. Keep inseparable feature\nbullets as a YAML array on that plan; do not make table cells or feature rows\nseparate entries unless they are independently authored records.\n\nBefore building, inspect `/content`, `/lib/content.ts`, and the relevant pages\nand components. Reuse the selected design's rendering pattern, but move\nqualifying authored records out of code even when demo files use arrays. Make\none content-model pass across the whole requested scope before authoring:\nenumerate every repeated set, assign its collection and typed frontmatter\nshape, classify it as list-only or list plus detail, and decide whether it\ngenuinely needs a Markdown body. Do not introduce a second inline content\nsystem later in the build.\n\n## Define the data contract\n\nCreate one `content/<collection>/<slug>.md` file per record. Put structured\nvalues in YAML frontmatter and primary long-form prose after the closing `---`.\nUse consistent field names and types, a stable `title` or `name`, `order` when\nsequence matters, and only the fields the presentation needs: category, price,\nrole, date, rating, attribution, image, alt text, and so on. Quote ambiguous\nYAML strings.\n\nIf a list-only record needs only short plain text, use a named frontmatter\nfield and leave the Markdown body empty; never author body prose that no\nrenderer consumes.\n\nA repeated child with its own title/label and value is a record, not an array\ninside a parent. Give each child an entry and group it with metadata such as\n`category`. Nested arrays are only for inseparable attributes, such as one\nplan's feature bullets. Put featured/pinned status and group order in entry\nmetadata, never in title allowlists in a page.\n\nFor a list-only collection, load every slug and sort the loaded entries by\nmetadata:\n\n```ts\nlistEntries(\"services\")\n  .map((slug) => loadEntry<ServiceFrontmatter>(\"services\", slug))\n  .sort((a, b) => a.order - b.order)\n```\n\nUse the actual collection name and define a separate typed frontmatter contract\nfor each collection. `loadEntry` returns typed frontmatter plus `bodyHtml`.\nThat value is already rendered HTML, not raw Markdown or plain text: pass it to\nthe design's `<Prose html={entry.bodyHtml} />` component. Never place it\ndirectly in JSX text, wrap it in `<p>`, escape it, or parse it again.\n\nFor details, use `pages/<collection>/[slug].tsx`, derive `getStaticPaths()`\nfrom `listEntries`, and handle unknown slugs. Adding an entry must not require\nediting route or component code.\n\n## Verify\n\nBuild one representative entry and its real list/card/detail renderer first,\nthen run `check_site` before bulk-authoring the rest. This vertical slice must\nprove the frontmatter type, `bodyHtml` handling, component props, and route\ncontract together.\n\nAudit every repeated authored block before `check_site`. Search pages,\ncomponents, and content-bearing config for leftover domain-content arrays,\nfeatured-title lists, authored group definitions, or duplicated records.\nConfirm every non-empty Markdown body is rendered and a representative record\ncan be added by creating only one Markdown file. Run `check_site`, fix every\ncontent, route, render, and type error, then render the preview.\n"
}