---
name: auro-design
description: Design and build a complete small-business website from an AURO client brief — distinctive per client, warm, usable by anyone from an 80-year-old to a power user, findable by search and AI engines, and beautiful even with zero client photos. Use whenever producing a website or design for an AURO client from a brief, even if the request just says "make the site for this client".
---

# AURO Design Skill — v2 (experimental)

> **Status: v2, compiled 2026-08-03.** Maintainers: this file is a rendering of
> `lab/LEDGER.md` (galen repo) — change the ledger first, recompile, log both in
> `CHANGELOG.md`. v2 folds in the design curator's interview (motion, harmony, mobile,
> intensity) and the round-1 floor findings (honesty split, structural variance). The skill's
> *shape* (design-only scope, single file, this output contract) remains as provisional as its
> content. Runners: none of that concerns you — everything you need is in this file and
> `craft-base.md` beside it; follow them as written.

## What you are doing

AURO is a small web agency for businesses that never properly went online: the garage with 20
years of word-of-mouth, the restaurant that has run for 30 years, the one-man gardening company.
Their owners don't know the web and will agree to almost anything — so this skill is opinionated
**on their behalf**. Their customers are everyone: the 80-year-old who struggles with phones and
the 17-year-old who lives on them. What you produce is not a draft or a wireframe: it is the
site, ready to deploy, and it must look like it cost thousands of euros more than it did. A
human design curator will judge your output against exactly that bar — and his sharpest anger
is reserved for defects that were *seen and shipped anyway*.

## Input: the brief

You receive one client brief (`brief.md`). It is the only client truth you have, and it may be
imperfect or incomplete — brief formats are still evolving.

- Where the brief is silent on something load-bearing, make the conservative choice and log it
  in `ASSUMPTIONS.md` (one line per assumption: what was missing, what you chose, why). Client
  facts follow the prohibition list in rule 9 — some may never be guessed at all.
- Where the brief conflicts with a hard rule below, the rule wins — but record the tension in
  `ASSUMPTIONS.md` instead of silently overriding. These owners agree too quickly; flagging is
  part of protecting them.

## Craft base

First, read and fully apply `craft-base.md`, in the same directory as this file (a vendored
snapshot of the frontend-design skill). If it is missing, note that in `ASSUMPTIONS.md` and
continue with this file alone.

It is your craft floor: intentional, distinctive, anti-generic design with a real token plan.
Two adjustments where AURO's context differs from its studio framing:

- **Precedence:** where that file and this one conflict, this one wins.
- **The risk dial:** it asks for "one real aesthetic risk". Keep the distinctiveness, but gate
  boldness by client-appropriateness — a 30-year family restaurant earns quiet confidence, not
  avant-garde. Spend the boldness where the brief's own character invites it.

## Hard rules

1. **Never a maze — and attention always has one home.** At any scroll position the visitor
   knows where they are and can jump anywhere: persistent compact navigation with a visible
   active state, distinct identity per page/section, footer wayfinding. And at every moment,
   the visitor's attention has one obvious place to go — beauty that fragments attention or
   makes people wonder where to look first has failed, no matter how striking.
2. **Any-user usability.** Body text ≥16px, generous tap targets, no hover-only or gesture-only
   interactions, strong contrast, visible keyboard focus. If the 80-year-old can't use it, it
   fails regardless of beauty.
3. **Content informs.** No filler, but never thin: a visitor should leave knowing what the
   business does, why to trust it, and how to act. Boring or empty copy fails as hard as
   clutter. When in doubt, add substance (a real page, a richer gallery), not ornament.
4. **One intention, total harmony.** Name one intention for the design and make every visual
   choice belong to it. Quiet or loud, static or dynamic — all legitimate if the client's
   identity calls for them; what is never legitimate is a choice that feels random or out of
   tune with the rest. Harmony is the invariant; everything else is a variable.
5. **Motion is choreography, gated by identity.** If the client's identity calls for stillness,
   still is right — motion is a lever, not a law. When you use it (the usual case for a wow
   moment): a new section *announces itself*; motion guides the eye in a deliberate sequence
   (look here → now here → now read) and then settles, leaving calm to read in; motion
   integrates with the typography and color system — never effects bolted on top. Cheap
   choreography beats expensive garnish: animation is the smallest lever — imagery and a
   coherent through-line come first. No autoplay carousels. Respect `prefers-reduced-motion`.
6. **No sameness — in tokens or in structure.** Every choice must be derivable from THIS
   brief's business, place, and character; no signature element reused across briefs. That
   includes the skeleton: do not default to the stock small-business page anatomy (sticky
   header → hero with eyebrow/heading/lead/two buttons → trust strip → services grid → story →
   FAQ → CTA band → footer) or a stock reveal spec. Derive the section order, hero
   construction, and motion vocabulary from what THIS brief most needs to announce first. If
   your skeleton or motion spec could be pasted into another client's site unchanged,
   restructure. Aim for "totally different, yet fits the conditions" — surprise bounded by
   harmony, clarity, and the client's identity.
7. **No AI-default looks.** The generic purple gradient look, the near-black + acid-accent
   look, the cream + serif + terracotta look — all forbidden as defaults (see the craft base's
   calibration). If the brief genuinely calls one of them in, justify it in the design-system doc.
8. **Photo-poor beauty.** If the client has no photos: no stock imagery, ever. Build the visual
   richness from typography, color, spacing, texture/atmosphere, and inline SVG. If the brief
   says photos exist but none are attached: design art-directed photo slots (styled frames with
   specified crop/treatment) and write `PHOTO-BRIEF.md` — a shot list the client can follow with
   a phone.
9. **Never invent client facts — and never ship a seen defect.** Hard prohibition list: opening
   hours, prices, quotes attributed to real people, service-area or municipality lists,
   certifications, review counts. If the brief doesn't state them, use a visible placeholder
   (e.g. "[openingsuren volgen]") — never a plausible guess, and never let a guess leak into
   JSON-LD. Structural inferences (section labels, connective copy) are allowed but logged in
   `ASSUMPTIONS.md`. Keep the brief's placeholder contact details verbatim. Not noticing a flaw
   is unintentional; noticing one and shipping it silently is deliberate — flag honestly instead.
10. **Language.** All copy in the brief's market language. For Belgian clients: Belgian Dutch —
    Netherlands-Dutch vocabulary reads foreign there. Match register to the business, not to
    marketing-speak. Recommend a native-speaker proofread in `ASSUMPTIONS.md`.
11. **Findability floor.** Semantic HTML5 landmarks and heading hierarchy; unique title +
    meta-description per page; JSON-LD structured data (LocalBusiness with the brief's contact
    data; FAQPage where an FAQ exists); a real FAQ section with questions customers actually
    ask, whenever the brief supports one. JSON-LD must mirror visible copy string-for-string —
    no facts that exist only in structured data, no empty or degenerate nodes. This floor is
    part of the product, invisible to the client.
12. **One primary action.** The single contact behavior the brief names (call, WhatsApp, quote
    request) is reachable from every screenful without hunting — and nothing competes with it.
    No contact form on a static site: a form that silently discards messages is worse than none;
    link the real channel instead.
13. **Mobile is a taste surface.** The designed feel must survive at 375px — same intention,
    same quality of composition. A site that turns basic or amateurish on mobile fails
    entirely, regardless of how beautiful the desktop version is.

## Direction

- **The bar:** "it does what it needs and it looks nice" — polished, warm, alive; never a
  tech-demo. Failure mode: an over-designed portfolio piece that intimidates the owner.
- **Looks expensive — by maximizing the envelope.** The visitor should assume the site cost
  thousands. The way there is squeezing every drop of visual quality out of the brief's
  constraints; cheap-but-maximized beats expensive-but-wasteful. Failure mode: anything that
  reads as a template with the logo swapped.
- **Feel first — and the feel is derived, not chosen.** Before any code: read the client's
  identity signals in the brief (the trade, the place, how the owner talks, what they say
  matters most) and name what the visitor should feel in the first seconds — the movie poster
  before the trailer. Then derive the token plan from that feel per the craft base's process.
  Never start from components, and never choose a tone from designer preference.
- **Intensity is derived; there is no house default.** Calm or loud, static or dynamic — read
  it off the client's identity and audience (technical readers need clear, structured calm; an
  expressive trade can carry heat). For AURO's segment the derivation will often land on calm —
  but that's an output, never an input. Failure mode: any fixed default.
- **Represent, then elevate.** The site expresses the client's actual identity at its best —
  the makeover, not the mask: never invent an identity that isn't there, never settle for a
  passive mirror either. A real person runs this business; their story, standards, and honesty
  are design material, presented with more confidence than they'd manage alone. Failure mode:
  corporate gloss that could belong to a chain — or aspirational styling that lies.
- **Simplicity adorns; contrast balances.** Unnecessary complexity rarely improves
  communication — but restraint is the client's register, not a house minimalism, and contrast
  is the balancing tool that keeps simplicity alive. Failure mode: minimalism as dogma.
- **Copy is design.** Short, concrete, jargon-free, in the owner's register; every sentence
  either informs or directs. Failure mode: paragraphs nobody reads — or terseness so extreme
  the site fails rule 3.

## Process

1. Read the brief twice; extract the business's character, audience, and the one primary action.
2. Derive the feel from the client's identity signals; write the one-line intention; build the
   token plan (palette, type pairing, spacing, motion, signature) per the craft base; derive
   the page skeleton from the brief's content priorities. Check the plan against Hard Rules 4,
   5, 6 and 7 before writing code.
3. Build the site per the output contract.
4. Self-check against the floor checklist; fix what fails; then write `SELF-CHECK.md` with an
   honest pass/fail per item. An honestly-reported failure is worth more than a false pass —
   downstream evaluation depends on it, and a knowingly soft-passed item is the one
   unforgivable defect (rule 9).

## Output contract

Write into `./site/`:

- Static pages per the brief (typically `index.html` + services + contact; follow the brief's
  package). Real content throughout — no lorem ipsum, no placeholder headings (fact
  placeholders per rule 9 are the deliberate exception).
- One `styles.css` (plus minimal vanilla JS in one file if motion needs it). No frameworks, no
  build step, no external JS libraries. Web fonts via standard font CDNs are allowed; all other
  assets self-contained (inline SVG over image files).
- Works opened directly from the filesystem (relative paths).

Beside it (in the working directory):

- `DESIGN-SYSTEM.md` — the one-line intention, then the token plan: named colors, type roles,
  spacing scale, motion spec (the choreography: what announces, what guides, where calm
  returns), the signature element, and one paragraph on why this feel fits this business.
  (This doubles as the developer-handover design-system document.)
- `ASSUMPTIONS.md` — every gap, guess, placeholder, and brief-vs-rule tension, one line each.
- `SELF-CHECK.md` — the floor checklist below, honest pass/fail + one-line evidence each.
- `PHOTO-BRIEF.md` — only when rule 8's photos-exist case applies.

## Floor checklist (self-check, and the external evaluation floor)

1. Orientation: visitor always knows where they are; nav shows active state; attention has one
   obvious home at every moment (rule 1).
2. 80-year-old test: text size, contrast, tap targets, no hidden interactions (rule 2).
3. Informative: services, trust signals, and practical info all present and true to brief (rule 3).
4. Harmony: one named intention in DESIGN-SYSTEM.md; every visual choice traces to it (rule 4).
5. Motion: choreographed (announce → guide → settle) or deliberately still, justified by the
   brief's identity; reduced-motion respected; no autoplay carousels (rule 5).
6. Distinctive: palette/type/hero AND skeleton/motion vocabulary derivable from this brief
   only; not the stock anatomy; no AI-default look (rules 6–7).
7. Imagery: zero stock; photo slots art-directed if applicable (rule 8).
8. Honesty: prohibition list respected — no invented hours/prices/quotes/areas/certifications;
   placeholders visible, JSON-LD clean of guesses; assumptions all logged (rule 9).
9. Language: correct market language and register throughout (rule 10).
10. Findability: semantics, titles/metas, JSON-LD present, valid, and string-matched to visible
    copy (rule 11).
11. Primary action reachable from every screenful; nothing competes; no dead contact form (rule 12).
12. Mobile: the designed feel survives at 375px — not merely functional (rule 13).