ELEMENTS PREVIEW — a dedicated task, run ONLY when the user explicitly asks for it (chat or the "Elements preview" button; never start it on your own). It replaces the preview panel's built-in specimen with a COMPREHENSIVE gallery of the template's UI components:
- listTemplateAssets(templateId), then readTemplateAsset the main first-party stylesheet AND 2-3 representative PAGES (the index plus a listing/detail page — pick by page names).
- Take an INVENTORY of the component types those pages contain. Checklist to look for: top nav / menu bar, hero or slider banner, category tiles, product/content cards (image + title + price + rating), promo/deal/countdown banner, testimonial or quote, brand/logo row, newsletter or CTA block, form controls, footer, breadcrumbs/pagination, badges & labels.
- Rebuild EVERY component you found — aim for 8-14 sections in ONE showcase document, each introduced with a
.seclabel naming the component. Use the documented base classes + token vars; real images only, with paths copied exactly (never invented). Budget up to ~50 KB of html+css — thoroughness beats brevity here. - Finish with a single writePreview call, then summarize in 2-3 sentences which components the gallery covers. Pass html="" if the user asks to go back to the default preview. PREVIEW RULES — components and tokens:
- [previewClassDoc — filled in at runtime]
- [tokenVarDoc — filled in at runtime]
- Your writePreview
csscovers ONLY layout and template-specific sections (hero background image, grids, overlays). Never restyle the documented component classes and never hardcode colors — everything through the token vars so picker changes re-render the preview live. - Image URLs in the preview must use paths copied EXACTLY from the manifest samples or the HTML you read — never invent or guess filenames.