Design Spatial

Design — spatial composition

When to Use

Use this skill when you need design — spatial composition.

A model cannot trust its own UI output. Everything else follows from two failures.

1. It can't see what it made

UI is generated as a token stream, never as pixels — so the model cannot perceive collisions, overlap, imbalance, or broken spacing. It will write a headline that runs into the hero image and have no idea.

Render it and judge the image, not the code. Serve with any static server (e.g. python3 -m http.server or npx serve) and screenshot headless via Playwright. Screenshot at a few widths.

Critique with fresh eyes — not your own. Grading your own output rationalizes it; the builder looks at its overlapping headline and calls it fine (this is exactly how a real collision shipped in testing). Use a separate judge — a subagent that did not write the page — and tell it to hunt for what's wrong: collisions, edge tangents, ragged alignment, lopsided weight, no clear focal point, breaks at some width. Fix, re-render, re-judge.

2. Its first idea is the average

Whatever it produces first is the mean of its training data — and there is more than one mean:

• the generic-AI mean: Inter, purple-on-white gradients, centered single column, three equal cards;
• the designer-trend mean: oversized condensed caps, dark-mode + grain, monospace "vibes" microtext, sticker badges.

Landing on the second isn't taste — it's a more flattering average, which is why it slips past. Treat your first instinct as the mean and deviate deliberately — toward this product's specific world (use design-thinking's domain / color-world / signature as the direction), not toward another trend. If the result could be any startup, you shipped the mean.

3. So don't prescribe a style

Any fixed rule — a 12-col grid, an 8-point scale, "mono = data" — becomes next cycle's mean, and a blind model executes it into collisions anyway. Prescribe the process, not the look: see it with fresh eyes, and push off the average toward the domain. Taste supplies the direction (design-thinking / design-philosophy); this skill only insists you look and don't ship the mean.

For iterative spatial tuning, a local page with live controls (sliders, pickers, drag handles) beats one-shot critique.

4. NEVER ship horizontal overflow — THE mandatory gate, no exceptions

BLOCKING GATE. You may not call any web UI "done", "working", "fixed", or "looks good" until you have run the scrollWidth check below at a narrow width THIS turn and seen 0. Not "I added overflow-x:clip so it's fine." Not "it looked fine at my width." MEASURE. Narrow. Every time. If you didn't measure, it isn't done — say "haven't checked overflow yet" instead of claiming done.

A side-to-side scrollbar that doesn't match the content is the single most common and most embarrassing layout failure, and it ships over and over because the dev viewport is wide enough to hide it — the overflow only appears once the window is narrower than some element. It is invisible at desktop width, so the §1 render-critique loop will NOT catch it unless you screenshot narrow. Separate, explicit, non-negotiable gate.

It recurs because layouts GROW after they were last checked. Every time you add a nav tab, a toolbar button, a header control, a chip, a wider equation/<pre>, or any new item to a flex/inline row, you have invalidated the last overflow check — the row that fit yesterday now pushes past the edge between ~720–1200px while your 1440px dev window shows nothing wrong. (Real ship, 2026-06, TWICE: a progress-bar edge label overflowed 23px; then a flex-wrap:nowrap header that grew 4 tabs scrolled the whole page 309px across 720–1200px — both invisible at dev width, both caught only by measuring narrow.) So: any change that adds an element to a horizontal row re-arms this gate. Re-measure.

Default defenses to apply up front (so the gate passes by construction):

• Header / nav / toolbar rows: flex-wrap: wrap, never nowrap. A growing single-row flex is the #1 source of this bug. Wrapping is a no-op when it fits and saves you when it doesn't.
• body { overflow-x: clip } as a backstop on every app (clip, not hidden — keeps sticky/anchored layouts working). A backstop, NOT a substitute for measuring.

The check — run before calling ANY page done: document.documentElement.scrollWidth - document.documentElement.clientWidth must equal 0, tested at your dev width AND resized narrow (≤1024px, and a phone width ~390px). If > 0, find the offender:

document.querySelectorAll('*').forEach(el=>{const r=el.getBoundingClientRect();
  if(r.right>innerWidth+1||r.left<-1) console.log(Math.round(r.right), el);});

Safety net: overflow-x: clip on body (prefer clip over hidden — it clips without creating a scroll container, so it won't break position:sticky/anchored layouts). But a net is not a fix — find and kill the root cause:

• position:absolute + white-space:nowrap anchored at an edge (left:100%, right:0): a centered nowrap label on the right edge juts past the viewport. (Real ship, 2026-06: a progress bar's "300 · learned model" milestone label at left:100% with translateX(-50%) overflowed 23px → phantom horizontal scroll at sub-1180px widths.) Anchor edge labels inward — right end right:0; transform:none, left end left:0; transform:none.
• 100vw — includes the scrollbar width (~15px), so on any vertically-scrolling page it guarantees ~15px of horizontal overflow. Use 100%.
• flex / grid children without min-width:0 — they refuse to shrink below their content and blow out the track (a long title in a flex card, a <pre> in a grid cell). Add min-width:0.
• long unbreakable strings (URLs, hashes, tokens): overflow-wrap:anywhere or word-break:break-word.
• fixed pixel widths wider than the viewport; large negative margins; oversized position:absolute elements.

The generalization: anything pinned to an edge or sized in viewport units is a horizontal-overflow suspect — test narrow, measure scrollWidth, clip the body as backstop, and anchor edge-pinned content inward.

5. Lay out in TASK order — minimize transition cost

Before placing elements, walk the user's actual step sequence for completing the page's action, then arrange elements in that same perceptual/view order. The layout should read like the task: orient → work → confirm. Any mouse travel or scrolling that serves no practical purpose is a defect.

• Orient at top: controls/options up top are good — they tell the user what the page is for and what it can do before they commit to reading it.
• Confirm where the work ENDS: if the task is "review a long list, then act" (approve, flag, submit, save), the action buttons must ALSO exist at the bottom — where the user's eyes and cursor are when they finish. The original failure: a delete-review page with confirm buttons only in the top toolbar — after scrolling through 120 images, the user had to scroll all the way back up to click "flag the rest." Duplicate the action bar at the bottom (or make the toolbar sticky); both are one line of code, the scroll-back is paid per page.
• The heuristic: save the user transit time. Every interaction has a path: where the eyes/cursor are when a step ends vs where the next step's control is. Sum those distances; shrink the big ones. Fitts's law for the page as a whole, not just one button.
• Check it in the render-and-critique loop (§1): ask the judge "trace the task: where is the user when they finish each step, and how far is the next control?" — a layout can be aligned, balanced, and still force a round trip.

6. Balance is measurable — don't eyeball it (or trust a VLM's eye)

§1 says render and have fresh eyes critique it. That qualitative pass catches collisions and ragged alignment, but a model has no reliable sense of visual balance — ask a VLM "is this centered / balanced?" and it confabulates a verdict. The fix is to stop asking opinions and measure a number, then keep that number honest with an independent check. Use both: §1's fresh-eyes critique AND the hard number below. (This pairs a live in-browser box model + auto-balancer with an offline pixel-oracle that re-measures the rendered screenshot — see the layout-audit.js companion script in this skill.)

The principle. Visual balance is the center of mass of visual weight. It's arithmetic, not taste — so compute it.

Optical center, not geometric. Target x = 0.50, y ≈ 0.46 — slightly high, because a centroid at literal 50% reads as sagging.

Visual weight = area × ink-density, not area alone. Same-size ≠ same-weight: a solid-black heading is heavy; a grey/ASCII/light image reads far lighter than its area; body text is sparse. Calibrated starting multipliers (from asym.html, re-tune per project — these were hand-guesses until corrected against the pixel oracle):

const DENS = {portrait:0.34, h1:0.82, kicker:0.42, lead:0.22, body:0.16, meta:0.5};

Centroid. Per axis, centroid = Σ(wᵢ·posᵢ) / Σwᵢ; balanced ⇔ the centroid sits on the optical center. To FIX imbalance, think see-saw: what counts is the moment = weight × distance-from-axis, so a heavy element near the edge is counterweighted by (a) an opposing weight, (b) a bigger element on the other side, (c) pulling the heavy element inward (shorter lever arm), or (d) shrinking it. That's exactly the auto-balancer's escalation order in asym.html — grow the opposing heading first (cheapest), then add weight, then pull the heavy element in, then shrink it (last resort).

Two models — and why you need the independent one:

• Cheap box model (live tuning): put each element's weight at its bounding-box center. Instant, fine for dragging sliders. BUT it has a systematic bug — left-aligned text's ink sits left of its box, so the box model misplaces the weight. A metric that shares the layout's own assumptions is circular; it once reported "balanced" at a pixel-measured 0.93 lopsided.
• Ground-truth pixel oracle (analyze.py): rasterize the rendered page (Playwright screenshot or html2canvas) and take the centroid of actual non-paper pixels, weighting each pixel by its distance from the background color. It knows nothing about the layout's intent — it just counts ink. When the box model and the pixels disagree, the pixels win. (asym.html closes the loop: it regresses the box-vs-pixel discrepancy and offers a trust dial α to blend toward the oracle.)
• Acceptance criterion (measurable): |centroid_x − 0.50| < 0.03 and |centroid_y − 0.46| < 0.04, plus low left/right and top/bottom imbalance (|w_left − w_right| / total).

The verification gate (lighter than §4's, same spirit). Before calling a balance-critical layout "balanced", do NOT assert it from the code or a VLM opinion — screenshot the rendered page, compute the ink-centroid offset from optical center, and report the actual number. This is the design-skill application of verify-outputs-rule: look at the real artifact, and make the validating check (pixels) independent of the thing you tuned (the layout). It's the quantitative complement to §1's qualitative critique.

7. The layout audit — metrics that MEDIATE the eye, never replace it

§6 covers balance; this generalizes it to a full deterministic sweep, and fixes the failure mode that matters most: the model reads a metric/JSON and never looks at the screenshot, so it can't apply the common sense that catches the metric being wrong.

scripts/layout-audit.js is a dependency-free pass you run via Playwright MCP browser_evaluate on a rendered page. It measures six things deterministically — all geometry, color, and pixels, no "does this look right?":

What makes it mediate rather than replace: it doesn't just return JSON — it draws every finding as an SVG overlay onto the page, so the next browser_take_screenshot is an annotated screenshot. The number tells you WHERE to look; you then look and decide. This is mandatory, not optional:

browser_evaluate({ function: "() => { <paste scripts/layout-audit.js> ; return __audit({}); }" })
browser_take_screenshot()      // ← the overlay is now on the page. VIEW IT. Reason over it.

Pass {align:'.card .title,.card .price', space:'.feature-list'} to scope the two selector-dependent checks; pass {contentSelector:'…'} for non-semantic layouts where collision needs help finding the blocks.

These are HEURISTICS, not laws — and they split into two kinds you must not conflate:

• GATES = correctness (overflow, contrast, tap). These measure accessibility/ usability facts, not taste. Failing one is a real defect. Safe to block on. (Collision is a near-gate: usually a real bug, but can be intentional — so eye-confirm, don't auto-fail.)
• SIGNALS = convention (balance, alignment, spacing rhythm). These measure how closely the layout matches a symmetric, regular, gridded aesthetic — which is exactly the generic mean §2 tells you to push away from. Optimizing a layout to maximize these scores makes it blander. An off-center balance, a deliberate misalignment, an uneven rhythm are core creative tools and frequently the best thing on the page. Treat signals as "worth a look," never as defects to fix.

The discipline (the whole point — bias hard toward this):

• Never accept a metric you have not looked at. A flag is a pointer to look, not a verdict. Reading collisions: 1 and acting without viewing the annotated shot is the exact failure this section exists to kill.
• Use signals to catch ACCIDENTS, never to enforce convention. A 7px alignment drift you didn't mean, a phantom scrollbar, a 1.9:1 caption — catch those. But the same balance/alignment/spacing signal fires on deliberate asymmetry, intentional overlap, and expressive rhythm. When the metric and the interesting choice conflict, the interesting choice usually wins. Do not "fix" a signal toward symmetry/evenness unless the eye judges the deviation actually worse. A model that maximizes these scores designs the mean.
• Overrule flags the eye judges intentional. Brutalist headline overlap, avatar on a banner, asymmetric hero — the metric flags them; common sense overrules. Proven live in the worked example: obeying the collision check on the brutalist mock removes the overlap and the design goes flat.
• Gates are necessary, not sufficient. gates_pass:true (overflow/contrast/tap all 0) clears the deterministic floor — it does not mean the layout is good. A bland centered template passes every gate and is still the mean. After gates pass, the real judgment (§1 fresh-eyes critique, taste, brand fit) still has to happen.

The proof, made concrete: build a page that runs all six algorithms live on a few realistic mock sites in different styles, each with a toggle between the layout as designed and the version obeying the metric, plus on-render overlays. It shows both halves: obeying a gate fixes a real bug (low-contrast CTA, sub-44 tap target, overlapping cards), while obeying a signal makes it worse (an asymmetric editorial hero is the more interesting layout; "correcting" a deliberate brutalist overlap flattens it). That explorable is where layout-audit.js was distilled from.

8. Optical craft — perception beats geometry

The audit's alignment check (§7) measures geometric edges. The eye doesn't read geometry, it reads perception — so a few cases need a manual nudge the metric can't make. These are eye-judgments, not gates. (From the Web Interface Guidelines, vercel-labs/web-interface-guidelines @ 4e799d4.)

• Optical alignment — nudge ±1–2px when it looks off though it measures centered. A play-triangle in a round button must shift right of geometric center to look centered (its visual mass is left-biased). Glyphs, arrows, and asymmetric icons often need the same. Text vertically centered by box metrics frequently sits a hair low — lift it. Geometry is the starting point; the eye is the judge.
• Balance icon/text lockups. When an icon sits beside text, match their visual weight — adjust the icon's stroke, size, spacing, or color so neither overpowers. A thin-stroke icon next to medium-weight text looks weak; thicken its stroke (or size it up slightly) so they read as one lockup. Optical size, not equal pixel size, is the target.
• This is the same principle as the §6/§7 debias: the number gets you close; the eye makes the final 1px call. Don't let a geometric alignment metric prevent an optical correction.

Limitations

• Use this skill only when the task clearly matches its upstream source and local project context.
• Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
• Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.