docs(prompting): level 6 — scale chapters + variables CSS-shadow correction

docs/prompting/design-systems.mdx

@@ -3,6 +3,8 @@ title: Design systems and brand
 description: "Point the agent at a source of brand truth — a design spec, a site, or a Figma file — instead of asking for 'on-brand', and let it compose the frame."
 ---
 
+Everything so far was one scene at a time. This level is about videos as systems — design that persists across scenes, edits that don't regress, output that ships. It starts with the most systemic thing a video has: its brand.
+
 "Make it on-brand" is the single vaguest thing you can ask. The agent has no way to know what your brand *is*, so it invents one. The fix is always the same: give it a **source of brand truth** — a design spec, a live site, or a Figma file — and name it in the prompt. Everything on this page is a way to do that.
 
 ## Point at a spec, don't describe a vibe
@@ -86,3 +88,5 @@ The engine rationale: a workflow's preset is a coherent, tested system — color
     Attach a brand guide or screenshot to seed a first draft from your look.
   </Card>
 </CardGroup>
+
+*Next: [Variables and templating](/prompting/variables-and-templating) — turn the brand tokens that repeat across a series into named slots you fill per render.*

docs/prompting/editing-existing-videos.mdx

@@ -3,7 +3,7 @@ title: Editing existing videos
 description: "Direct the agent like an editor — trim, move, retime, swap, restyle — with the NLE verb you already know mapped to the prompt that lands it in one pass."
 ---
 
-Most HyperFrames time isn't the first render — it's the twenty edits after it. A composition is plain HTML with `data-*` timing attributes and a GSAP timeline, so every edit you'd make in a non-linear editor maps to a specific, inspectable change in the source. You don't re-specify the video; you name the edit the way you'd say it to a human editor, and the agent makes the smallest change that does it.
+A templated composition still gets edited, and so does everything else you build. Most HyperFrames time isn't the first render — it's the twenty edits after it. A composition is plain HTML with `data-*` timing attributes and a GSAP timeline, so every edit you'd make in a non-linear editor maps to a specific, inspectable change in the source. You don't re-specify the video; you name the edit the way you'd say it to a human editor, and the agent makes the smallest change that does it.
 
 This page maps the editor verbs to the prompts that land them. The examples name elements from a typical composition — swap the noun ("the lower third", "scene 2") for whatever yours is called. Two habits from [Iterating](/prompting/iterating) apply to every one of them, so keep them in mind: **change one thing per render**, and **state targets as absolute values** ("scene 2 = 2 seconds", not "a bit shorter") so the agent lands it in a single pass instead of oscillating.
 
@@ -128,3 +128,5 @@ Visual tweaks — color, size, weight, position of a single element — are wher
   <Card title="Timeline editing" href="/guides/timeline-editing">Which edits the Studio timeline persists, and how</Card>
   <Card title="Video editor cheatsheet" href="/guides/video-editor-cheatsheet">The `data-*` attributes as timeline controls</Card>
 </CardGroup>
+
+*Next: [Iterating](/prompting/iterating) — the discipline behind every edit on this page: one variable per render, absolute targets, freeze what works.*

docs/prompting/iterating.mdx

@@ -3,7 +3,7 @@ title: Iterating
 description: "Talk to the agent like a video editor — small targeted edits beat re-specification."
 ---
 
-HyperFrames is a conversation. After the first render, talk to the agent the way you'd talk to a video editor — don't re-prompt from scratch:
+[Editing existing videos](/prompting/editing-existing-videos) already leaned on two habits — one variable per render, absolute targets over relative nudges — for every verb on that page. This is where they come from, stated plainly, so you can apply them anywhere: HyperFrames is a conversation. After the first render, talk to the agent the way you'd talk to a video editor — don't re-prompt from scratch:
 
 > Make the title 2x bigger.
 
@@ -36,3 +36,5 @@ When you're dialing in a look, relative corrections oscillate — "make the dots
 - ✅ `glow at ~35% peak opacity, always subtler than the orb itself`
 
 And freeze what already works: "the framing and motion are right — don't touch them; only change the dot size." Without the freeze clause, a rebuild can drift on axes you'd already settled.
+
+*Next: [Recreating something you saw](/prompting/recreating-references) — the same absolute-target discipline, applied to matching a specific reference frame by frame.*

docs/prompting/recreating-references.mdx

@@ -3,7 +3,7 @@ title: Recreating something you saw
 description: "Transcribe motion, iterate with absolute targets, distill the constants — and know where the text-only ceiling is."
 ---
 
-In practice, matching a specific reference from text alone reaches roughly 90% — but only with a specific workflow, and knowing where the ceiling is.
+[Iterating](/prompting/iterating) covered the discipline in general. This page is its hardest test: matching a specific reference you watched rather than a look you're inventing. In practice, matching a specific reference from text alone reaches roughly 90% — but only with a specific workflow, and knowing where the ceiling is.
 
 **Transcribe motion, not just composition.** Watch the reference frame by frame and write down: the exact duration, the camera's path, what each element does with timestamps, how entrances overlap, which layers are blurred, sampled colors. A prompt built this way one-shots ~75% of the target — structure and motion arc land, rendering calibration doesn't.
 
@@ -32,3 +32,5 @@ A distilled spec that one-shots a broadcast-style animated globe:
   </Accordion>
 
 The honest ceiling: words carry discrete, countable things losslessly and underdetermine continuous perceptual qualities — bloom falloff, material feel, optical color mixing. That last 10% doesn't close from text; it oscillates. If pixel-exact matters, keep the composition file.
+
+*Next: [Rendering and output](/prompting/rendering-and-output) — once the cut is locked, the words that pick the right export.*

docs/prompting/remotion-migration.mdx

@@ -3,6 +3,8 @@ title: Porting from Remotion
 description: "What to say to migrate an existing Remotion (React) composition's source into HyperFrames HTML — and what to expect the agent to refuse."
 ---
 
+This is the last chapter of Level 6, and the last before the capstone level — bringing an existing Remotion project into everything you now know: brand systems, variables, editing, iteration, reference-matching, and export.
+
 ## What this makes
 
 Not a new video — a **translation**. The [`/remotion-to-hyperframes`](/prompting/overview) workflow reads an existing Remotion (React) composition's source and rewrites it as HyperFrames HTML: the same frames, the same timing, the same visual output, running on GSAP instead of React's frame-callback model.
@@ -60,3 +62,5 @@ A translation that "looks right" in preview can still measure meaningfully below
 **Skipping validation on a non-trivial port.** A visual-only check misses timing/easing drift that only shows up in a frame-by-frame SSIM diff.
 - ❌ *(no request to validate — accepting on "looks right")*
 - ✅ `render both and report the SSIM diff`
+
+*Next: [Rules and anti-patterns](/prompting/rules-and-anti-patterns) — the failure modes and fixes that cut across every level.*

docs/prompting/rendering-and-output.mdx

@@ -3,7 +3,7 @@ title: Rendering and output
 description: "What to say to get the right file out — quality tier, format, resolution, framerate, and cloud rendering — without over-speccing a render that slows to no benefit."
 ---
 
-Everything before this point shapes the composition. This page is about the *export*: the words that pick a quality tier, a container format, a resolution, and where the render runs. The defaults — MP4, 1920×1080, 30fps, `standard` quality — are deliberately good, so most of the skill here is knowing when *not* to ask for more. The mechanics live in the [Rendering guide](/guides/rendering); this page owns what to say.
+Everything before this point — including the frame-by-frame matching in [Recreating something you saw](/prompting/recreating-references) — shapes the composition. This page is about the *export*: the words that pick a quality tier, a container format, a resolution, and where the render runs. The defaults — MP4, 1920×1080, 30fps, `standard` quality — are deliberately good, so most of the skill here is knowing when *not* to ask for more. The mechanics live in the [Rendering guide](/guides/rendering); this page owns what to say.
 
 ## Quality tier
 
@@ -113,3 +113,5 @@ The cheapest way to avoid a wasted `high`/4K/HDR render is to judge the frame fi
   <Card title="Rendering guide" href="/guides/rendering">Formats, quality presets, workers — the mechanics</Card>
   <Card title="AWS Lambda" href="/deploy/aws-lambda">Cloud rendering setup and cost</Card>
 </CardGroup>
+
+*Next: [Porting from Remotion](/prompting/remotion-migration) — bringing an existing Remotion project into everything you now know.*

docs/prompting/variables-and-templating.mdx

@@ -3,7 +3,7 @@ title: Variables and templating
 description: "Ask for the parts that should change to become named slots, then re-render the same composition with different values — one output per record."
 ---
 
-Most videos have a few things that vary and a lot that doesn't. When you know a composition will be reused — a card per customer, a stat per quarter, a name per recipient — say so in the prompt, and name the parts that change. The agent turns them into declared [variables](/concepts/variables): typed, labeled slots filled at render time instead of hardcoded into the HTML.
+[Design systems](/prompting/design-systems) covered the parts of a video that should *never* change per render — the brand. This page covers the parts that should: a card per customer, a stat per quarter, a name per recipient. When you know a composition will be reused, say so in the prompt, and name the parts that change. The agent turns them into declared [variables](/concepts/variables): typed, labeled slots filled at render time instead of hardcoded into the HTML.
 
 The trigger phrase is simple — call out the slots:
 
@@ -65,6 +65,10 @@ A few inputs are read once at compile time and no variable can move them: compos
 
 If total length must differ per output, that's a different root `data-duration` per render, not a variable. See [what can't be a variable](/concepts/variables#what-cant-be-a-variable) for the full list and the compile-time-vs-live-DOM rule behind it.
 
+<Note>
+  An authored CSS custom property always wins over a same-named variable. If your composition already defines its own `:root { --accent: ... }` (a hand-written theme token, say), a variable called `accent` never overwrites it — the authored value stands. A render-time `--variables` override still wins over both. If you need to override an authored value per render, use `--variables`, not a same-named declared variable.
+</Note>
+
 ## Related
 
 <CardGroup cols={2}>
@@ -81,3 +85,5 @@ If total length must differ per output, that's a different root `data-duration`
     Brand tokens as variables that re-skin every reuse from one value.
   </Card>
 </CardGroup>
+
+*Next: [Editing existing videos](/prompting/editing-existing-videos) — the editor verbs that turn a first render into the twenty edits after it.*