On my Opus Growth hosting server
[server name], build a multi-page site for
[business name] that loads no JavaScript at all and does its motion and page transitions with the browser's own CSS features. Business:
[what it does, for whom], city:
[city, district]. Services or products:
[list]. Work: [for each: name, material or scope, duration, problem solved, image link]. Contact:
[email],
[phone],
[WhatsApp number],
[address]. Domain:
[domain].
Pages: home (hero, recent work, process, FAQ), work (/isler/), about (/hakkimizda/), contact (/iletisim/, no form), privacy (/gizlilik/) and 404.html.
Style: editorial and natural. A serif display (for example Zodiak) with a calm body font (for example Switzer), a linen-toned background, one dark accent, generous space. Keep the boldness for the work cards.
Modern CSS rules (progressive enhancement; in a browser without support the page must be still but complete):
1. Load no JavaScript file at all; no GSAP, Lenis or Swiper. The mobile menu works with `<details>`.
2. Page transitions (View Transitions across same-origin pages): write `@media (prefers-reduced-motion: no-preference) { @view-transition { navigation: auto; } }` and keep the duration around 0.35 s. Give the top bar view-transition-name: site-header. Give a work card image on the home page and the same image on the work page the same unique view-transition-name, so the image grows into its place on the new page. Use each name only once per page.
3. Scroll-driven animations: a progress line at the top that grows with scaleX on `animation-timeline: scroll(root)` (display:none by default, visible only with support); on cards and section headings `animation-timeline: view()` with `animation-range: entry 0% entry 70%` using translateY only; on the hero image a gentle scale and translate while it is in view. Do not use opacity: elements sitting faded below the screen fail Lighthouse's contrast check. Put all of these rules inside `@supports (animation-timeline: scroll())` and `prefers-reduced-motion: no-preference`.
4. Container queries: make the work card a component with `container-type: inline-size`. With `@container (min-width: 34rem)` the image sits on top in a narrow container and beside the text in a wide one. The same card is narrow in a three-column grid on the home page and wide in a single column on the work page. Tailwind 3 core has no container query classes; write these rules as plain CSS in app.css.
5. The card's heading level must fit the page it sits on: on the work page put an h2 between the h1 and the cards' h3 headings. When this was missing in the demo, Accessibility dropped to 98 on heading-order.
6. On the work page, the first card image that enters the first screen is not lazy and gets fetchpriority="high".
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 (/isler/, /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; work CollectionPage with one CreativeWork per piece under hasPart (with material if known); about AboutPage; contact ContactPage; BreadcrumbList on inner pages. The most specific LocalBusiness subtype 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.
Support check: site_preview captures with motion off, so it cannot show the transitions. Tell me how to check in Chrome that the image grows into place when I click a piece on the home page, that the top line fills as I scroll, that the card changes layout as I narrow and widen the window, and that the page opens complete in a browser without these features.
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.
