Opus 5.5

Go to Awwwards, pick a winning site you find genuinely impressive, and rebuild it pixel for pixel.

Context you should know: this is going into a video watched by a large audience, your clone is put on screen next to the original site against two other frontier models doing the same task, and your work will be credited to you by name. Every model gets this identical prompt. The comparison is literal — your build and the real site, side by side, at the same viewport.

**First, read the methodology.** Clone `https://github.com/per-simmons/clone-app-pat-pro-public` and read `SKILL.md` and `references/00-contract.md` before you do anything else, then the stage references as you reach each stage. The contract defines the workspace layout, the artifact filenames, the stage inputs and outputs, the verification gate, and the convergence loop. Follow it. `scripts/assert-styles.mjs` is the gate.

Two overrides to what that repo says, and they win where they conflict:

- **Ignore the stop-and-check-in gate.** That repo was written for an interactive session with a human. You are running unattended. Do not stop between stages, do not ask for approval, do not ask questions. Run the whole pipeline start to finish and report only when it's done.
- **Use your own browser automation** — headless Playwright or Puppeteer, installed and driven by you — anywhere the repo says to use the Claude Chrome extension. The contract's real rule is unchanged and it is the one that matters: **computed styles read off the live page are the ground truth.** Read them through the CSSOM. Screenshots are a visual reference only; never build the gate on a pixel diff.

Requirements:

1. **Pick your own target on Awwwards** — Site of the Day, Site of the Month, or a Developer Award winner. Pick something you actually find impressive rather than something easy to match. It must be publicly reachable without a login or paywall. Record the exact URL, the award, and why you chose it in the project README. If a site turns out to be unclonable for a hard reason — it's down, it's gated, it's a video with no site behind it — pick another and note the swap.

2. **Recon every view before you write code.** Every route, every breakpoint, every interactive state — hover, focus, active, open menus, modals, scroll-triggered states, loading and transition states. The repo's `01-recon.md` covers this. What you miss in recon you will not build.

3. **Extract, don't guess.** Pull real computed values off the live page: the full type scale, the color palette with exact values, spacing, radii, shadows, borders, grid and container widths, breakpoints, easing curves and durations, font families and weights. `02-extraction.md` and `03-design-spec.md` are the shape of this. Never read a value off a screenshot.

4. **Rebuild it.** Every page, every component, every state, at every breakpoint. The motion is part of the clone — scroll behavior, page transitions, hover choreography, entrance animations, any WebGL or canvas work. A static skin over a site whose whole identity is motion is a failed clone.

5. **No lifted assets.** Do not hotlink from the original and do not download its images, video, or fonts. Regenerate imagery in code, substitute freely-licensed equivalents, or author placeholders that match the original's role, aspect, and color. Fonts come from an open CDN, matching the metrics as closely as you can. Say what you substituted in the README.

6. **Prove the match.** Run the verification gate: read the clone's computed styles, compare them to the extracted design tokens with `scripts/assert-styles.mjs`, and iterate the convergence loop until there are zero style-assertion failures and the project builds clean. Then eyeball your clone against the real site at the same viewport, at every breakpoint, and fix what your eye catches that the assertions didn't.

7. **Ship it runnable.** A real project — a modern framework is fine — that installs and runs with a documented command, plus a README naming the target URL, the award it won, what you substituted, and your final assertion results.

8. **Depth over breadth if you have to choose.** One page cloned to a genuinely indistinguishable standard beats five pages that are approximately right.

Work completely autonomously. Do not ask for anything until it's finished.

DONE when: the clone passes the style-assertion gate with zero failures, runs from a documented command, reproduces the original's motion and interactive states, and holds up next to the real site at full screen.

Rebuild https://en.manayerbamate.com/ as closely as you can, using the cloning methodology in
./clone-skill/.

Context you should know: this is going into a video watched by a large audience, your build is put on
screen next to the real site against two other frontier models doing the same task, and your work
will be credited to you by name. Every model gets this identical prompt and the identical target.
The comparison is literal, so anything you skip will be visible.

This is an evaluation exercise, not a site to ship. It is never published as the brand's own site.

**Read the methodology first.** `./clone-skill/SKILL.md` and `references/00-contract.md` before you
do anything else, then each stage reference as you reach it. `references/stage-prompts.md` and
`references/tooling.md` are worth reading early. The contract defines the workspace layout, the
artifact filenames, the stage inputs and outputs, the verification gate and the convergence loop.
Follow it. `scripts/assert-styles.mjs` is the gate.

Two overrides that win where they conflict with the skill:

- **Ignore the stop-and-check-in gate.** That skill was written for an interactive session with a
  human. You are running unattended. Do not stop between stages, do not ask for approval, do not ask
  questions. Run the whole pipeline start to finish and report only when it is done.
- **Use your own browser automation** — headless Playwright or Puppeteer, installed and driven by
  you — anywhere the skill says to use the Claude Chrome extension. The contract's real rule is
  unchanged and it is the one that matters: **computed styles read off the live page are ground
  truth.** Read them through the CSSOM. Screenshots are visual reference only; never build the gate
  on a pixel diff.

Requirements:

1. **Recon every view before you write code.** Every route, every breakpoint, every interactive
   state: hover, focus, active, open menus, modals, scroll-triggered states, loading and transition
   states, the language switcher. What you miss in recon you will not build.
2. **Extract, do not guess.** Pull real computed values off the live page: the full type scale, the
   colour palette with exact values, spacing, radii, shadows, borders, grid and container widths,
   breakpoints, easing curves and durations, font families and weights. Never read a value off a
   screenshot.
3. **Rebuild it.** Every section, every component, every state, at every breakpoint. The motion is
   part of the clone: scroll behaviour, page transitions, hover choreography, entrance animations,
   any canvas or WebGL work. A static skin over a site whose identity is motion is a failed clone.
4. **No lifted assets.** Do not hotlink from the original and do not download its images, video or
   fonts. Regenerate imagery in code, substitute freely-licensed equivalents, or author placeholders
   that match the original's role, aspect and colour. Fonts come from an open CDN, matching the
   metrics as closely as you can. List every substitution in the README.
5. **Prove the match.** Run the verification gate: read your clone's computed styles, compare them to
   the extracted design tokens with `scripts/assert-styles.mjs`, and iterate the convergence loop
   until there are zero style-assertion failures and the project builds clean. Then eyeball your
   clone against the real site at the same viewport, at every breakpoint, and fix what your eye
   catches that the assertions did not.
6. **Ship it runnable.** A real project that installs and runs with a documented command, plus a
   README naming what you substituted and your final assertion results.
7. **Depth over breadth if you have to choose.** One page cloned to a genuinely indistinguishable
   standard beats five that are approximately right.

Model the adidas Adizero Adios Pro Evo 3 in Blender as photorealistically as you can, then
build its product page with that model live and interactive on the page.

Context you should know: this is going into a video watched by a large audience, your page is shown
on camera against two other frontier models doing the same task, and your work will be credited to
you by name. Every model gets this identical prompt and the identical reference photographs. What
is being judged first is how close your shoe looks to the real one.

**Reference photography is in `./refs/`** — official adidas studio shots of colourway Cloud White /
Core Black / Solar Turbo, style code KH7678. `evo3-3.jpg` and `evo3-8.jpg` are profile views and are
your primary geometry reference. `evo3-2.jpg` is the sole plan, `evo3-1.jpg` top-down, `evo3-5.jpg`
rear three-quarter. `evo3-13.jpg`, `-6`, `-7`, `-10` are macros of the midsole step, the upper
texture, the collar and the lacing. Look at them before you model anything, and keep checking back.

## Use Blender, headlessly

Blender 5.1.2 is at `/opt/homebrew/bin/blender`. Drive it with
`blender --background --python <your_script.py>`. Build the model in Python so you can iterate:
re-run, render, look at the render, fix, re-run. Do not hand-place vertices you cannot regenerate.

Render turntable and detail stills to `./renders/` with Cycles and actually look at them. A model you
never rendered is a model you never checked.

Export `./shoe.glb` (glTF 2.0, Draco compression on) for the web page. Keep it under 8 MB.

## The construction, which is published and specific

Get these right. They are the difference between this shoe and a generic running shoe.

1. **There is no plate.** It uses **ENERGYRIM**: a carbon perimeter rim in a **U shape, open at the
   front**, leaving bare foam underfoot. It is **asymmetric** — continuous along the lateral side,
   but on the medial side it stops in the heel and reappears in the forefoot. A full-length carbon
   plate is wrong and will be visible in the cutaway.
2. **Midsole: Lightstrike Pro Evo.** Off-white, matte, visibly foam rather than plastic — sculpted,
   with open cell structure at the cut edges. It is **two-tier**: an upper body and a stepped lower
   keel, with a **thin black pinstripe tracing the bond line** along the sidewall. Stack is 39 mm
   heel; adidas markets 36 mm forefoot but independent measurement puts it nearer 33 — model nearer
   39/33 and the rocker will read correctly. Aggressive forefoot rocker, toe tip lifting ~6.5 cm off
   the ground.
3. **Upper: ultralight ripstop**, derived from kitesurf sail material. Translucent white with a fine
   square grid. It is **non-stretch**, so it drapes and wrinkles rather than shrink-wrapping the
   foot — model the wrinkles, they are the tell.
4. **Three Stripes as a halftone dot matrix**, not solid black. Large dots thinning toward the edges.
5. **Outsole: Continental rubber**, a single teardrop pad over the forefoot only with about six
   curved sipes, plus a small translucent heel window. Everything else is bare foam. The rubber is
   charcoal with a violet cast, not black.
6. **No heel counter, no insole, no gusset on the tongue.** The tongue is thin and unpadded with a
   second lace loop low on the side. Laces are flat, white and short, running through translucent
   film loops.
7. **Stamped text** in small condensed caps: `LIGHTSTRIKE PRO EVO` on the foam, `ADIZERO ADIOS PRO
   EVO 3` on the upper.

Sampled colours from the official photography: whites `#EAEEEF`, blacks `#2F3032`–`#3A3B3F`,
Continental rubber `#48474D`, Solar Turbo accent `#FE7875` bright / `#D34144` in shadow.

## The page

8. **A single self-contained `index.html`** that loads `shoe.glb` and puts it on the page live —
   orbitable, lit properly, with real materials. three.js via CDN is fine. No build step, no server,
   no API keys.
9. **Scroll drives a sequence**: the shoe rotates, the upper fades to expose the ENERGYRIM, the
   midsole separates from the outsole, annotations appear anchored to each part. Scrubbing backward
   runs cleanly in reverse.
10. **A complete product page**, not just a viewer: hero, the scroll sequence, a spec table (weight
    97 g at UK 8.5, stack 39/36 mm, 3 mm drop, $500), a section on the record run, a materials
    section, and a purchase call to action. Write copy that sounds like adidas, not placeholder text.
11. **Sixty frames per second** while scrolling and orbiting. Profile it and fix it.
12. **Responsive** down to a phone.

## QA

13. Put your render side by side with `refs/evo3-3.jpg` and compare silhouette, midsole step, stripe
    placement and rocker angle. Fix what is off. Then load the page, scroll it top to bottom and back
    several times, orbit the shoe, check the frame rate and the console. Write `BUILD_NOTES.md`
    covering what you got close on and what you could not match.

Build a playable browser clone of RollerCoaster Tycoon 2: an isometric park where you lay
coaster track piece by piece, test the ride, and open it to paying guests who decide for themselves
whether it is worth riding.

Context you should know: this is going into a video watched by a large audience, your build is
played on camera against two other frontier models, and your work will be credited to you by name.
Every model gets this identical prompt. The audience has played this game. Go all out.

## Rendering

1. **2:1 dimetric projection, done correctly.** `screenX = y − x`, `screenY = (x + y) / 2 − z`.
   Tiles are 32 world units and render as a **64 × 32 px** footprint. Exactly **four** camera
   rotations, cycled with `& 3`. Height step of 8 units per level.
2. It should read as RCT: a tile grid, chunky readable sprites or low-poly geometry in that style,
   paths, grass, water, scenery. Programmer art is a failure.

## Track building

3. **Lay track piece by piece** on the grid: station platform, chain lift hill, slopes at the
   discrete pitch set, banked turns, flat turns, a helix, a vertical loop, a corkscrew, brake run,
   **block brakes**, and a photo section. Steel and wooden coaster types with different piece sets.
4. **Validity gates before a ride can open**: the circuit must be complete and return to the station,
   the station must be at least 2 tiles, and block brakes must be spaced so two trains can never
   occupy one block. An incomplete circuit is not testable.
5. **Build → test → rate → price → open.** No ratings exist until a test run completes. This ordering
   is the spine of the game; do not let a player price an untested ride.

## The physics

6. Chain lift pulls at a fixed speed. After the crest, velocity comes from gravity on the pitch,
   with quadratic drag. Track G-forces: vertical, lateral, longitudinal.
7. Speed readout in mph is `(velocity * 9) >> 18`.
8. **Crash conditions, correctly.** A train that cannot crest a hill rolls back. Two trains in one
   block collide. Derailment from G-force applies **only** to trains without upstop wheels on
   uncovered track, at lateral > 1.50 G or vertical < −0.40 G.

## Ratings — the three numbers

9. **Excitement, Intensity, Nausea**, computed from the layout: drop height, top speed, air time,
   G-forces, ride length, inversions, and proximity to scenery and other track.
10. **Six named bands, at these exact thresholds** (they are multiples of 2.56 because the game
    computes `rating >> 8`): Low below 2.56, Medium 2.56, High 5.12, Very High 7.68, Extreme 10.24,
    Ultra Extreme 12.80.
11. **The intensity penalty**: excitement is multiplied by 0.75, cumulatively, at each of 10.00,
    11.00, 12.00, 13.20 and 14.50 intensity. An Ultra Extreme ride keeps about 23.7% of its
    excitement, which is why the nastiest rides always read Low excitement. Implement this.
12. **Guests refuse to ride above 10.00 intensity**, hard.

## Guests

13. Guests are agents with **Happiness, Energy, Hunger, Thirst, Nausea, Bathroom and Money**. They
    walk the paths, queue, ride, get nauseous, buy food, get lost, and leave.
14. Each guest has a personal intensity window, widened by happiness. They weigh excitement against
    intensity, queue length and price.
15. **Price ceiling**: a guest will pay at most **2× the ride value**, hard-capped at **£20.00**.

## Money and park rating

16. **Park entry fee XOR per-ride pricing** — the two are mutually exclusive, pick one per park.
17. Running costs, staff wages per month (**Handyman £50, Mechanic £80, Security £60, Entertainer
    £55**), loans with interest.
18. **Park rating 0–999**, from guest count, ride quality, litter and crowding. **29 consecutive days
    below 700 closes the park.** Remember the formula prefers average excitement ≈3.68 and intensity
    ≈5.20 rather than rewarding maximums.

## Shipping

19. **Single self-contained `index.html`.** Any library via CDN. No build step, no server, no API
    keys, no hotlinked sprites — generate art procedurally or author it in canvas/SVG/WebGL.
20. **Sixty frames per second** with a full park and a few hundred guests. Profile it and fix it.
21. Playable within ten seconds of load, with one line of on-screen controls. Ship a small starting
    park so there is something to look at immediately.
22. **QA it by playing it.** Build a coaster, test it, check the ratings look sane, open it, watch
    guests actually queue and ride, confirm the money moves and the park rating updates. Fix what
    breaks. Write `BUILD_NOTES.md` covering which systems you implemented and which you stubbed.