On my Opus Growth hosting server
[server name], build a dark, multi-page product site for
[product name] that tells its story as the visitor scrolls. Product:
[what it does, who it is for]. The three steps a user follows in the product:
[three steps]. Key features:
[4 to 6 features]. Contact:
[email],
[phone],
[WhatsApp number],
[address if any]. Domain:
[domain]. Colour preference:
[colour or "you choose"]. Real product screenshots or photos:
[links or "none"].
Pages: home (/), product (/urun/), about (/hakkimizda/), contact (/iletisim/), privacy (/gizlilik/) and 404.html. Home sections in order: hero (h1, two-sentence description, two buttons, product image), the product story as the signature element, features, who it is for, FAQ and a closing call to action. No form on the contact page; use email, phone and a WhatsApp link with a prefilled message, because the server only serves static files.
Style: dark motion. Dark background, one restrained accent colour (not neon), a tight grotesk display from Fontshare (for example Cabinet Grotesk) and a calm body font (for example Switzer). No gradients and no WebGL; keep the boldness for the product story.
Motion rules (the hardest part, follow them to the letter):
1. Libraries: GSAP 3.13 core, ScrollTrigger, SplitText and Lenis. Download them from jsdelivr into `assets/vendor/` with site_fetch and pin the version. Load them only on the home and product pages; the about, contact and privacy pages carry no script at all. Do not load Swiper.
2. Do not attach these with `<script defer>`. Put a small loader at the end of the page: after the load event it waits two requestAnimationFrame calls and then requestIdleCallback, appends the scripts in order with async=false, and downloads nothing if `<html>` has no `anim` class. In the demo, deferred libraries pushed mobile LCP to 3.2 s and left Performance at 92; with this loader it reached 99.
3. A one-line script in `<head>` adds the `js` class to `<html>`, and the `anim` class unless prefers-reduced-motion is "reduce". Define hidden starting states only under `.anim`, so content is visible from the start with JS off or for visitors who prefer less motion, and the libraries are never downloaded for them. As a safety net in case a library fails to load, add a CSS animation that makes every hidden element visible after 2.5 s. If JS arrives later than that, do not hide visible content again; only build the pinned story.
4. SplitText heading entrance: the first-screen h1 is the LCP element, never start it hidden. The h1 starts visible in a dimmed colour that still passes AA contrast, and SplitText brings its lines to full colour one after another (mask and aria options on). Keep the masked, rising line entrance for the h2 headings further down and play it on scroll with ScrollTrigger.
5. Signature element: in the product story, use ScrollTrigger pin and scrub through gsap.matchMedia only at 768 px and wider (scrub around 0.6, end "+=180%"). On the left the three steps become active one by one; on the right the product screen fills in step by step. Do not dim inactive steps with opacity; change only the heading colour and the border line. In the demo, steps dimmed with opacity failed contrast on desktop and dropped Accessibility to 95. On mobile there is no pin; steps appear in normal flow. Without JS, the product screen shows its finished state.
6. Turn Lenis on only for `(pointer: fine)` devices so touch devices keep native scrolling. Drive Lenis from gsap.ticker and move focus to the target after scrolling to an in-page link.
7. The product screen is a decorative figure with aria-hidden and a figcaption that says what it shows. Every interaction works with the keyboard and the focus ring stays visible.
Setup and known traps (each one lowered a score in the demo measurements, do not skip):
1. If a site is already live on the server, tell me first, because the setup overwrites index.html and the assets folder. Preview scaffold_site with confirm=false and call it with confirm=true after my approval. Then read site_design_guide and site_seo_guide. Before writing code, put the design direction (typography, colour, grid, signature element, motion language and the libraries that will NOT be loaded) in a short ART.md outside assets and show it to me.
2. Compile Tailwind instead of loading it from the CDN. Install it with site_run_command and background=true: `npm i -D tailwindcss@3`, then follow it with site_command_status. The content paths in `tailwind.config.js` must cover every HTML file, the templates and any JS file that writes class names. `_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 and the inline tailwind.config from every page and link only `/assets/site.css`. Recompile after every HTML change.
3. Host the fonts yourself. Read the CSS of the Fontshare families you picked, download the woff2 file of each weight into `assets/fonts/` with site_fetch, and write the @font-face rules with `font-display: swap` into `assets/app.css`; design-check looks for a custom font there. Check the font-family name in the CSS you downloaded, because Fontshare can return a different family when a weight does not exist. Preload the font of the first-screen heading and the body font on every page with `<link rel="preload" as="font" type="font/woff2" crossorigin>`; in the demo this removed the layout shift caused by the font swap (CLS 0.024 to 0). Most Fontshare fonts have no ₺ glyph, so write "TL" for prices.
4. Make the menu and footer static HTML. Do not load chrome.js or site.config.js on the pages. Write a small `chrome-stamp.mjs` that reads the nav list in site.config.js and stamps `_src/header.tpl` and `_src/footer.tpl` between the `<!-- nav:start --><!-- nav:end -->` and `<!-- footer:start --><!-- footer:end -->` markers of every page, adding aria-current="page" to the current link. Do not give the templates an .html extension and use placeholders like `
[[NAV]]` instead of `{{...}}`, otherwise design-check and seo-check read them as unfinished pages. Build the mobile menu without JS using `<details>`. Keep the business name, address and phone in the footer as plain text.
5. Convert images while downloading them with site_fetch: write the same photo to separate files with resize="480x", "800x" and "1200x", image_format="webp", quality=65. Give every `<img>` srcset, sizes, width and height. The main first-screen image gets fetchpriority="high" and is never lazy; the rest get loading="lazy" decoding="async". If the main image fills the phone screen, serve a wider, smaller crop on mobile with `<picture>` (in the demo the mobile hero went from 89 KB to 43 KB).
6. Create a 48 px PNG favicon from the logo with site_fetch and add `<link rel="icon">` to every page. Without it the browser logs a 404 and Best Practices drops to 96.
7. HTML validator rules: start every document with an uppercase `<!DOCTYPE html>` (the kit's starter files use lowercase), use ` ` for the spaces in the visible text of tel: links, never use a style="" attribute, and give every button type="button".
SEO, AEO and GEO:
1. Use directory URLs with a trailing slash (/urun/, /hakkimizda/, /iletisim/, /gizlilik/). Fill in the seo block of site.config.js and run `node seo-stamp.mjs`. Write the page-specific schema (home WebPage and FAQPage; product SoftwareApplication and FAQPage; about AboutPage; contact ContactPage; BreadcrumbList on inner pages. For a software company without a physical shop set localBusiness:false in site.config.js) in separate `<script type="application/ld+json">` blocks and link it to the base graph with @id. Do not bury BreadcrumbList inside an @graph; give it its own block, because that is the only way seo-check sees it.
2. Titles 48 to 60 characters (seo-check flags anything over 65 as an error), descriptions 145 to 158 characters, one h1 per page. Every page needs at least 150 words of main content; contact and privacy pages tend to fall short.
3. The first paragraph of each page answers the page's question directly. Write a page-specific FAQ with `<details>` and mark it up as FAQPage. Show the publishing organisation and a "Last updated" date with `<time>`.
4. In robots.txt, write your decision with its 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 carries real lastmod dates. llms.txt holds an accurate two-sentence summary of the site and the list of key pages.
5. Do not invent anything: no reviews, ratings, awards, customer counts, certificates, opening hours, coordinates or prices unless I give them. Leave unknown fields out of the schema.
Gates (in order; do not call it finished until all pass):
1. With site_run_command run `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 (reduced-motion), so if content is missing in that picture, the motionless state is broken. In full-page captures, lazy images further down may show as empty; that is not an error, but check their paths.
3. Run core_web_vitals for every page with strategy="mobile" and strategy="desktop". Pass: on mobile Performance at least 95 and Accessibility, Best Practices and SEO 100; on desktop all four at least 95. On a page that fails, use resources=true to find the file that holds it back, fix it and measure again. Then run seo_audit on the home page with strategy="mobile" and runs=2. The network request list must not contain any host other than your own domain.
4. No horizontal scrolling at 360, 390, 768 and 1440 px width, touch targets at least 44 px, no console errors.
Motion check: site_preview cannot show motion, so describe the pinned section on the home page and tell me what to check in my own browser: on desktop the product story should stick to the top while the steps advance with scrolling, on a phone it should flow without sticking, and with reduce motion turned on in the operating system nothing should move and everything should be visible.
After publishing: preview the rule `/assets/* Cache-Control: public, max-age=31536000, immutable` with site_headers and apply it after my approval; from then on, rename CSS or JS files when they change (site-v2.css and so on). Submit sitemap.xml with gsc_submit_sitemap and check the home page with gsc_url_inspect. Finish with a per-page score table (page, four mobile scores, four desktop scores, LCP, CLS), the gate results and the list of fixes you applied.
