---
name: design-harness
description: Generate non-slop landing pages and UI by anchoring to the user's local eye library (Awwwards SOTY/SOTM/SOTD captures) and craft-recipe vocabulary. Use for any landing page, hero section, marketing site, or component where visual quality matters and defaults must not be generic.
---

# Design Harness

The single rule: **design quality is the harness's problem, not the model's.** This skill encodes the pipeline that prevents AI-slop output regardless of the model behind it.

## Never do these (hard bans — the skill fails review if any are present)

- **Do not ask "what aesthetic"** or "what style" or "what vibe." The process below answers it without the user.
- **Do not center the hero headline** on a gradient blob with a pill-shaped "Get Started" button below. This exact pattern is the slop signature.
- **Do not produce a 3-card pricing grid** unless the product is pricing-comparison-first (and even then, rethink).
- **Do not produce a feature-icon-headline-subtitle strip** of three identical bullets.
- **Do not ship a testimonial carousel** with rounded avatars and star ratings.
- **Do not default to Inter, Roboto, Arial, or system fonts.** Pick a distinctive family deliberately.
- **Do not ship purple-gradient-on-white** or any lazy color scheme.
- **Do not ship without a dominant visual anchor** — a scene, image, 3D graphic, large photograph, or functional graphic element that OWNS the hero. A page that is "just text, well-set" is a Substack post, not a landing page worth shipping.
- **Do not lean on decorative italic serif** for every project. That itself is a taste pattern you can overuse.

If you catch yourself producing any of the above, stop and restart the relevant section.

## The process (execute in order, do not skip steps)

### Step 1 — Inspect the user's eye library

Before designing anything, look at:

```
~/.sandcode/eye/awwwards/<slug>/
├── shot.png        # full-page static capture of an award-winning site
├── motion.webm     # (if present) 8-second scripted interaction
├── meta.json       # tier (SOTY/SOTM/SOTD), tags, live URL
└── motion.json     # (if present) derived motion descriptors
```

Read as many `meta.json` files as needed to understand the user's taste cluster. Score by tier weight: `SOTY=1.0, SOTM=0.85, SOTD=0.7`. If the user has a `~/.sandcode/eye/filter.json`, multiply by `love=1.3, keep=1.1, unseen=1.0, reject=0.0` — rejected entries are excluded entirely; loved entries weight the cluster.

**If the library is empty or sparse:** tell the user once: *"Eye library is empty. Run `/eye-ingest run` to populate it from Awwwards. Proceeding with domain→identity map for now."* Do not ask again.

### Step 2 — Infer the domain

From the user's brief, project context, and first prompt, classify the product into one of the domain buckets in `references/04-domain-map.md`. If no brief exists (blank-slate), pick the most specific domain defensible from the product name alone and commit.

### Step 3 — Match to the library cluster

Filter the user's eye library by domain relevance + tech-tag overlap + style-tag overlap. Aim for 3–6 references that match the project's register. Exclude anything whose register is wrong (example: a WebGL 3D game-site reference is wrong for a print-journal domain, and vice versa). Write the matched set to the user for transparency.

### Step 4 — Derive constraints (generator NEVER sees the reference pixels)

From the matched set, derive — not copy — the following constraints:

- **Palette** (3–5 colors): dominant background, primary ink, one accent hue max, atmospheric tint if cluster has one. Use OKLCH internally. Never pure black — use off-black (~#0A-#14 range).
- **Typography**: one display family + one text family + optionally one mono. Must be distinct across projects. Pull from `references/01-anti-slop.md` "recommended distinctive families" list. Never Inter, Roboto, Arial, or system stack.
- **Grid**: columns, whether asymmetric, whether bleeding off edges, margin-vs-content bias.
- **Motion descriptors**: scroll-linked ratio range, hover latency/duration bounds, preferred easing curves, FPS target. If cluster has WebGL-heavy members, motion profile includes canvas/3D primitives.
- **Depth profile**: `minimal | editorial | technical | experimental` — drives shadow vocabulary, layering, atmospheric effects.

Write the derived constraints as a commit line to the user in the format:
> *"Going [identity] for [product] — [display-font] + [text-font] + [mono-font], [palette summary], [grid summary], [motion summary]. References pulled from the eye library: [slug1], [slug2], [slug3]. Building."*

One-line commit. No menu. No A/B options. User can veto in a single sentence; silence means accept.

### Step 5 — Compose from the craft library

Generate output by composing from the motion/depth/3D recipes in `references/02-craft-recipes.md`. Do not improvise motion patterns — pick recipes whose signature matches the cluster's motion descriptors. Valid code only — no placeholder comments like `// add animation here`.

**Non-basic defaults** — every new project scaffolds with these unless the cluster explicitly rejects them:
- Smooth-scroll normalization (Lenis or equivalent)
- Non-linear easing bank loaded (no `ease-linear` outputs)
- View Transitions API polyfill for route changes
- Hero with staggered reveal OR scroll-linked parallax OR full-viewport scene
- Hover states with real transitions, never default browser underline

### Step 6 — Dominant visual anchor (MANDATORY)

Every page must have ONE thing that owns its hero:
- A large image / photograph that bleeds off an edge, OR
- A large functional SVG or CSS-drawn graphic specific to the domain (e.g., a camera aperture for a lens brand, a compass for a cartography product, a waveform for audio work), OR
- A WebGL or canvas scene if cluster + tech stack warrant it, OR
- Large-scale display typography acting as the visual (only if done at 10%+ bigger than a reader would expect and asymmetrically placed)

A page that would be captioned "big text on cream" in a gallery review has no anchor. Reject and re-plan.

### Step 7 — Copy voice

Anti-slop extends to words:
- No "Get Started Free."
- No "Join the waitlist" / "Start your free trial."
- No "Learn more" as a button label.
- No generic "We help X do Y" value props.
- Copy must sound category-specific: a print journal talks about paper stock; a lens brand talks about glass and brass; a running app talks about pace and hills. Place the copy in the actual domain, not in SaaS-speak.

### Step 8 — Self-critic before you stop

Before marking the design done, check every item:

- [ ] No centered hero + gradient blob
- [ ] No 3-card pricing grid
- [ ] No feature-icon-headline strip
- [ ] No testimonial carousel with star ratings
- [ ] Fonts are not Inter / Roboto / Arial / system
- [ ] Palette doesn't match a generic SaaS template
- [ ] Hero has a dominant visual anchor (not "just text")
- [ ] Motion exists, uses non-linear easings, respects `prefers-reduced-motion`
- [ ] Copy reads like a specific product in its actual industry, not SaaS boilerplate
- [ ] References cited from eye library OR clear statement that library was empty
- [ ] Every derived constraint traces back to a reference or the domain map
- [ ] No `any`, no `TODO` stubs, no placeholder comments — production code only

If any item fails, fix before delivering. Three iterations max, then escalate to the user with a specific question about the failing item.

## When to invoke this skill

- User asks for a landing page, marketing site, hero section, product launch page, portfolio
- User asks to "design" or "redesign" a UI surface
- User asks for a component where visual identity matters (not "add a dropdown," but "design the nav")
- User critiques an output as "generic" or "slop" or "AI-looking"

**Do not invoke for:**
- Internal admin tools / dashboards (use `design` skill for utilitarian UI)
- Code refactors that don't touch visual surface
- Backend logic

## Relationship to the `design` skill

The existing `design` skill generates award-quality UI from compiled design knowledge. This skill layers on top: it enforces the non-slop pipeline, consults the user's personal eye library, and blocks the anti-patterns at the review gate. When both apply, invoke `design-harness` — it will read the `design` skill's references when it needs specific values (OKLCH palettes, spacing scales, etc.) but applies the harness workflow.

## Reference files

- `references/01-anti-slop.md` — full banned-pattern list with visual signatures + recommended distinctive font families
- `references/02-craft-recipes.md` — motion, depth, and 3D recipes to compose from
- `references/03-eye-library.md` — how to query the user's local eye library
- `references/04-domain-map.md` — domain → identity map for blank-slate projects

Read each reference file when the step above says to. They are not optional — the reference content IS the harness knowledge.
