Build a direct-to-consumer product page and a few supporting pages for
[brand name], my single-product brand, on the
[server name] site on my Opus Growth hosting server. Product:
[product name, what it does, for whom]. Price:
[price]. Colours or variants: [for each one a name, colour code and a photo link shot from the SAME angle on the SAME canvas]. Specifications: [dimensions, material, weight and performance figures with their test conditions]. Models to compare:
[your own other models and their figures]. Buy link:
[store URL and variant parameter]. Shipping, returns and warranty:
[periods and terms]. Contact:
[email],
[phone],
[WhatsApp number],
[address]. Domain:
[domain].
Pages: product home (/), warranty and returns (/garanti-ve-iade/), contact (/iletisim/), privacy (/gizlilik/) and 404.html. Home sections in order: hero (3D showcase on the left; label, h1, two-sentence intro, price, colour picker, buy button and a shipping, returns and warranty summary on the right), three short sections on how the product works, a specifications table (#ozellikler), a size or model comparison table (#karsilastir), FAQ (#sss). The menu links to these sections in-page plus the warranty and contact pages. This site has no cart or checkout; the buy button goes to the store page with the selected variant, and the page says so plainly.
Style: a clean, modern direct-to-consumer product page. A warm off-white background, one brand colour that matches the product, a black rounded buy button and clean tables. Typography: a tight grotesk display from Fontshare (for example Familjen Grotesk 500 and 700) with a readable body face (for example Ranade 400 and 500). The product photo is the star; save the boldness for the 3D showcase. GSAP, Lenis and Swiper are not loaded; the only JavaScript is an inline script under 1 KB that tilts the showcase.
3D showcase, colour picker and buy bar rules (follow them exactly):
1. Build the 3D showcase with CSS: `perspective: 1100px` on the container, `transform: rotateX(var(--rx, 3deg)) rotateY(var(--ry, -7deg))` and `transform-style: preserve-3d` on the inner card, and a 0.3 second transform transition. Without JavaScript and on touch screens the card rests in this slightly tilted pose. Two small badges (for example capacity and a performance figure) float in front of the card with `translateZ(60px)` and are aria-hidden; the same information is also in the text. Put a soft highlight that follows the pointer over the image (a radial-gradient driven by --gx and --gy).
2. The tilt script is inline at the end of the page and runs only when `matchMedia("(pointer: fine) and (prefers-reduced-motion: no-preference)")` matches. On pointermove it maps the pointer position inside the card to -0.5 to 0.5, sets --ry to at most 8 and --rx to at most 6 degrees, and throttles the writes with requestAnimationFrame; on pointerleave it removes the variables and returns to the default pose. Only transform changes, the layout never shifts. Add a data-reveal="tilt" attribute to the showcase container so design-check recognises the motion.
3. Build the colour picker without JavaScript: inside a `<fieldset>` and `<legend>`, a real `<input type="radio" name="colour">` per variant wrapped in a 44x44 pixel `<label>`; the radio is visually hidden (sr-only), the colour dot gets a double ring through `input:checked + .dot` and a focus ring through `input:focus-visible + .dot`; arrow keys change the colour. All variant images sit on top of each other in the same `aspect-ratio` box with `position: absolute; inset: 0`, and only `opacity` changes, so the layout never shifts when the colour changes (CLS 0 in the demo). Reflect the choice with `.product:has(#r-colour:checked)` on the image, the colour name in the legend and the buy link. If the browser does not support :has, the default variant's image, name and link stay visible.
4. The default variant's image is the LCP element: fetchpriority="high", not lazy. The other variant images get loading="lazy" decoding="async". Variant photos must be shot from the same angle, on the same canvas and with the same crop; otherwise the product jumps when the colour changes. Ask me about it rather than trying to match differently angled photos by cropping.
5. Do not let a button class's `display` value such as `.btn-buy` override the visibility of the variant buy links. In the demo the rule `.vb { display: none }` was overridden by `.btn-buy { display: inline-flex }` further down, and all four buy buttons showed at once; write the rule with a more specific selector such as `.product :is(.vb)` and check in the browser that only one button shows.
6. Sticky buy bar on mobile: below 768 pixels, a `position: fixed; bottom: 0` bar with the product name and price, the selected colour's name and a single "Buy" button (at least 48 pixels). Keep the button text short and on one line (`whitespace-nowrap`); put the colour name inside the button as sr-only text for screen readers. Give the body a bottom padding equal to the bar's height so the bar never covers content or the footer, and check that the last link at the bottom of the page stays above the bar. The bar is hidden on desktop.
7. Tables: the specifications table has `<th scope="row">` row headers, a visually hidden `<caption>` and a sentence stating the test conditions (for example room temperature, lid closed). In the comparison table compare only your own models, with no competitor names or competitor claims; highlight the model on sale with a background colour but do not rely on colour alone. Wrap the table in `<section aria-label="..." tabindex="0" class="overflow-x-auto">` so it never overflows on narrow screens; do not write role="region", which html-validate flags as prefer-native-element.
Setup and known traps (each one cost points or failed a gate in the demo measurement, do not skip):
1. If a site is already live on the server, tell me first, because setup overwrites index.html and the assets folder. Preview scaffold_site with confirm=false first, then call confirm=true once I approve. Then read site_design_guide and site_seo_guide. Before writing code, write the design direction (typography, colour, grid, signature element, motion language and the libraries that will NOT be loaded) into a short ART.md outside assets and show it to me.
2. Compile Tailwind, do not load it from the CDN. Install `npm i -D tailwindcss@3` with site_run_command and background=true, and follow it with site_command_status. The content paths in `tailwind.config.js` must cover every HTML file including subfolders, the `_src/*.tpl` templates and any JS file that writes classes. `_src/tw.css` holds the line `@import "../assets/app.css";` and the three `@tailwind` lines; compile it into one file with `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remove the cdn.tailwindcss.com script, the inline tailwind.config, chrome.js and motion.js from the pages and link only `/assets/site.css`. Recompile after every HTML change. If you set the colour dots with arbitrary value classes such as `bg-
[#28385C]`, they are compiled because they appear in the HTML.
3. Self-host the fonts. Read the Fontshare CSS with one request per family and weight (`https://api.fontshare.com/v2/css?f[]=family@weight`), download each woff2 file into `assets/fonts/` with site_fetch and write the @font-face rules with `font-display: swap` into `assets/app.css`; design-check looks for the custom font there. Preload EVERY weight used above the fold (heading, body and buttons) on every page with `<link rel="preload" as="font" type="font/woff2" crossorigin>` and put these lines before the stylesheet link. Most Fontshare fonts have no ₺ sign, so write prices with "TL".
4. Make the menu and footer static HTML. Write a small `chrome-stamp.mjs` that reads the nav list from site.config.js and stamps `_src/header.tpl` and `_src/footer.tpl` between the `<!-- nav:start --><!-- nav:end -->` and `<!-- footer:start --><!-- footer:end -->` markers on every page, adding aria-current="page" to the active link. Do not give the templates a .html extension and use placeholders like `
[[NAV]]` instead of `{{...}}`. Build the mobile menu with `<details>` and no JS. Keep the business name, address and phone in the footer as plain text, and make footer and breadcrumb links at least 44 pixels tall.
5. Convert images while downloading them with site_fetch: write the same photo to separate files with resize="480x", "800x" and "1120x" (or the widths the page needs), image_format="webp" and quality=65. Give every `<img>` srcset, sizes and a width and height that match the real ratio. The main above-the-fold image gets fetchpriority="high" and is not lazy; give fetchpriority only to the real LCP element, and loading="lazy" decoding="async" to the rest. Download the variant images at 4:5 with resize="480x", "720x" and "960x".
6. Write a small `favicon.svg` in the site root and add `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` to every page; if there is a PNG logo, make an apple-touch-icon with site_fetch, resize="180x180" and image_format="png". Without a favicon the browser logs a 404 for /favicon.ico and Best Practices drops to 96.
7. HTML validator rules: start every document with an uppercase `<!DOCTYPE html>`, quote attributes with double quotes, use ` ` for the spaces in the visible text of tel: links, never use a style="" attribute (if you need a CSS variable, use a Tailwind arbitrary property class such as `
[--r:-4deg]`), give every button type="button", do not put aria-label on role-less elements such as `<ul>` or `<div>`, and use `<section aria-label="...">` instead of role="region".
8. A touch target audit may flag the visually hidden radio as 1 pixel; the real touch target is the label around it. Measure that the label is at least 44x44 pixels and note the reason in the report.
SEO, AEO and GEO:
1. Use directory-style URLs with a trailing slash (/garanti-ve-iade/, /iletisim/, /gizlilik/ or their equivalents in your language). Fill in the seo block of site.config.js and run `node seo-stamp.mjs`. For a brand with no physical shop, set localBusiness:false in site.config.js. Home page: ItemPage (mainEntity the product), the product schema and FAQPage. Product schema: with a single variant, Product and Offer; with colour variants, a ProductGroup (productGroupID, variesBy https://schema.org/color, brand, description, material) and inside hasVariant a Product per colour (sku, color, image) with an Offer (price, priceCurrency TRY, availability, itemCondition, the variant's store URL as url, seller @id, shippingDetails with OfferShippingDetails and hasMerchantReturnPolicy with MerchantReturnPolicy). Publish the same MerchantReturnPolicy with its @id in its own block on the warranty and returns page. Add GTIN, ratings or reviews only if I have real values. Write every page-specific schema in its own `<script type="application/ld+json">` block and link it to the base graph with @id. Do not nest BreadcrumbList inside @graph; keep it in its own block, because that is the only way seo-check sees it.
2. Titles 48 to 60 characters (seo-check treats over 65 as an error), descriptions 145 to 158 characters, one h1 per page. The main content of every page is at least 150 words. In the demo the warranty and returns, privacy and contact pages came in at 141, 124 and 106 words on the first try and were completed with real information such as "return steps", "who the data is shared with" and "what a warranty claim needs".
3. The first paragraph of every page answers the page's question directly, and the h1 is phrased as that question. Write the page's own FAQ with `<details>` and mark it up as FAQPage. Show the publishing organisation and a "Last updated" date with `<time datetime>`.
4. In robots.txt, write your decision with the reason for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot and CCBot, and point to the sitemap. sitemap.xml has a real lastmod. llms.txt has an accurate two-sentence summary of the site and a list of the important pages.
5. No invention: do not write reviews, ratings, awards, customer counts, certificates, opening hours, coordinates, prices or product figures without asking me. Leave any field you do not know out of the schema entirely.
Gates (in order; do not say "done" until all pass):
1. With site_run_command, run in order `node chrome-stamp.mjs`, the Tailwind build, `node seo-stamp.mjs`, `node seo-check.mjs` (0 errors, 0 warnings), `node design-check.mjs` (0 errors; justify any remaining warning) and `npx html-validate "**/*.html"` (0 errors).
2. View every page with site_preview, view="mobile" and view="desktop". site_preview captures the page with motion turned off; if the content is not complete in that capture, the no-motion state is broken. Lazy images further down may be blank in a full-page capture; do not count that as an error, but check their paths.
3. Run core_web_vitals for every page with strategy="mobile" and strategy="desktop". Acceptance: on mobile Performance at least 95 and Accessibility, Best Practices and SEO at 100; on desktop all four at least 95, target 100. For a page that misses, find the slow file with resources=true, fix it and measure again. Then run seo_audit on the home page with strategy="mobile" and runs=2. The network request list must contain no address outside your own domain (store and WhatsApp links are links, not requests).
4. No horizontal scrolling at 360, 390, 768 and 1440 pixels wide, touch targets at least 44 pixels, no console errors.
Interaction check: since site_preview cannot show motion or clicks, tell me what to look for in my own browser: on desktop, moving the mouse over the product tilts the card toward the pointer with the badges floating in front, and it returns to the tilted pose when the mouse leaves; clicking a colour dot or pressing an arrow key changes the image, the colour name and the buy link without anything on the page shifting; with JavaScript off the colour picker still works; on a phone the bottom bar is always visible and does not cover the links at the end of the page; with reduce motion on the card does not tilt.
After publishing: preview the rule `/assets/* Cache-Control: public, max-age=31536000, immutable` with site_headers and apply it once I approve; from then on, version the file name whenever CSS or JS changes (site-v2.css and so on). Submit sitemap.xml with gsc_submit_sitemap and check the home page with gsc_url_inspect. At the end give me: a per-page score table (page, four mobile scores, four desktop scores, LCP, CLS), the gate results and the list of fixes you applied.
