# Signature Design > Design and build client-ready websites and mobile web apps in the proven house style behind the cinematic reference and the instrument reference: tinted grounds, editorial typography, obsessive specificity, and proof over promise. Carries the whole working loop (brief, design contract, build, localhost review gate, multi-lens agent audit, ship), two verified token systems, and the signature component patterns. Also carries the mobile web-app playbook (density budget, bottom tab bar, compaction, coach overlays and shadow galleries, borrowing 21st.dev components) and the imagery rules (real photography from Unsplash and other free sources, chosen for the right context, labelled honestly). Trigger on "make it look expensive", "make it beautiful", "high end design", "make it gorgeous", "client ready", "on brand professional", "our house style", "make it look like the cinematic reference", "design this landing page", "build a web app design", "make it more like an app", "too much scrolling", "add bottom navigation - Skill: `sva-admin/signature-design` (Agent Skill, multi-file: 12 files) - Install (CLI): `npx skillmds@latest add sva-admin/signature-design` - Raw SKILL.md: https://api.skillmd.com/api/skills/sva-admin/signature-design/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: sva-admin (https://skillmd.com/u/sva-admin) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/sva-admin/signature-design --- # Signature Design One house style, extracted from two shipped client projects and generalised so it can be applied to new work. Throughout, they are referred to only by the register they belong to: - **The cinematic reference**: a coastal property site, built to make a visitor feel something and then enquire. - **The instrument reference**: a members-club booking app, built so a person on a phone can finish a task. The client work itself is private, so every example here is invented or generalised. What is real is the method: the token systems, the component mechanics, the copy rules, the audit, and the failures that shaped them. ## Why this skill exists at all Most design skills, `impeccable` and `high-end-visual-design` included, are built to invent a **fresh** point of view for every brief. That is correct for agency work, and `impeccable` even warns itself against converging: if the last surface was restrained-on-cream, the next one must not be. This skill does the opposite on purpose. It carries **one aesthetic that has already been paid for**, so a newcomer can produce work in that idiom without having taste yet. Taste is the slow part. A proven system is the shortcut. Use both. `impeccable` owns the universal laws (OKLCH colour handling, motion curves, the six absolute bans, the AI-slop test). This skill owns the specific house answer and the client workflow around it. Where they disagree, note it out loud rather than silently picking, and see `references/taste.md` for the one place they genuinely conflict (the serif choice). ## First decision: which register Everything downstream depends on this. The two builds look nothing alike because they answer different questions. | | **Cinematic** (the cinematic reference) | **Instrument** (the instrument reference) | |---|---|---| | The user is | deciding whether to care | trying to get something done | | Success is | a feeling, then an enquiry | a completed task, fast | | Layout | full-bleed sections, scroll narrative | dense cards, facets, lists | | Type | display serif + letterspaced sans | one sans, many sizes | | Motion | ambitious, first-load allowed | functional only | | Mobile | a smaller cinema | a native-feeling app with a tab bar | | Verdict | marketing site, launch, brand | booking, dashboard, catalogue, account | If the answer is genuinely both (a marketing front door plus a logged-in app), build them as two registers under one token system rather than compromising into a mush. The instrument reference does exactly that: a cinematic home surface sitting on top of an instrument. Write the register down before touching a file. It decides the type stack, the density, and what counts as a defect later. ## The five laws These are the load-bearing ideas. Everything else is detail. Each is drawn from what actually shipped, and each has a reason, because a rule you understand survives contact with a new situation and a rule you memorize does not. ### 1. Specificity is the luxury signal Real numbers, real names, real distances. The cinematic reference says "214.60 sqm", "38m above the water", "two minutes from the water". The instrument reference says "3 of 12 places", "09:20 to 14:05", "6 min from the central station, north exit". Vagueness reads as either hiding something or not knowing. Precision is expensive to fake, so it signals the real thing. This is also the cheapest upgrade available on any page: replace every "spacious residences" with the square metres and the page gets more premium without a single CSS change. Corollary: **placeholder content is a design defect, not a content to-do.** Lorem ipsum and "Feature One" hide exactly the quality this style depends on. ### 2. Proof over promise Every claim carries the evidence next to it. The cinematic reference does not say the views are beautiful; it flew a drone to the exact position of nearly every residence and says "Not an artist's impression. Your view, on file." It does not say the materials are good; it says every material in the renders exists today in the sales gallery, go and touch it. It shows the render and the photograph side by side and invites the comparison. The instrument reference applies the same move to onboarding: "The dates and the places left are counted out of the database as the page is built, not written by hand. When a table fills, this number drops." When you write a claim, ask what would make a sceptic believe it, then put that thing in the layout. This is what separates the style from ordinary luxury pastiche, which asserts and hopes. ### 3. The ground is never white and the ink is never black The cinematic reference sits on `#F7F2E9` warm ivory with `#40301D` brown ink. The instrument reference uses white paper but a green-tinted `#141A18` ink and an `#F3EEE3` secondary surface. Pure `#FFF` on pure `#000` is the default of something unconsidered, and the eye reads the tint as intent even when it cannot name it. Tint every neutral a little toward the brand hue. `impeccable` says the same thing in OKLCH terms and its reasoning is worth reading. ### 4. Anything interactive must announce itself This is the most-repeated correction in the entire project history, so treat it as the house's sorest point. The cinematic reference labels its carousel "SWIPE, DRAG, OR USE THE ARROWS" and its comparison slider "Drag the line to move the sun". The 360 viewer got a side-arrow scroll cue specifically because a user could not tell it was scrubbable. A control that only reveals itself on hover does not exist on a phone. If a thing can be dragged, swiped, scrubbed, or expanded, say so in words, show an affordance, or animate a hint on first view. Discoverability is not decoration. ### 5. On mobile, density is respect The instrument register exists because of a specific correction: too much negative space and too much scrolling, most people are on a phone, and they should not have to wade through sections. Build for the thumb: a bottom tab bar, content above the fold, facets instead of endless scroll, and real information on every card. Airy full-viewport sections are a cinematic-register privilege. Spending them on an instrument is a defect. ## The anti-slop clause The sharpest critique this house gives is "too generic and ai slop, including the fonts". The instruction that followed matters as much: look at classpass.com, airbnb, agoda, then **create our own style**. So the method is benchmark, then diverge: 1. Name three real products that solve a similar interaction problem well. 2. Say in one sentence each what they actually get right, mechanically. 3. Take the mechanism, never the skin. 4. State what this project will do differently, and why the brand demands it. If the palette and type are guessable from the category name, it is the training-data reflex and it has to be reworked. `impeccable`'s category-reflex check covers this well. ## The loop This is the sequence the good work actually followed. The gates are the point; skipping them is how projects go wrong. ### 1. Brief, out loud, before any file State the register, who the user is, what the one action is, and what the brand already owns (logo, photography, a document, an existing site). Client assets often arrive as a `.docx` or a folder of photos, so extract the real brand from them rather than inventing one. `design-dna` is the right tool when a screenshot or reference image is the input. **Gate: say the plan before building it.** The standing instruction in this house is to explain how you will do it first. This is not ceremony; it is the cheapest possible place to catch a wrong direction. ### 2. Design contract Lock the decisions before components exist, because retrofitting a type scale across forty files is how a week disappears. Write tokens down, then treat them as the only source of truth: no raw hex or px in components. Both proven token systems are in `references/tokens.md`, including the semantic patterns worth stealing wholesale (radius by role, colour by state, named z-index, app-chrome heights). Read it before inventing your own scale. ### 3. Build Component patterns with real markup are in `references/patterns.md`: the section-header triple, the stat counter row, the affordance-labelled carousel, the comparison slider, the proof pair, the event card, the bottom tab bar, and the first-run coach overlay. **If the register is instrument, read `references/webapp.md` before building anything.** It carries the density budget (a real number you measure), the footer tab bar spec, eleven compaction moves, and the delight components worth their weight: the shadow coach overlay, the spotlight cutout, the shadow gallery, tickers, skeletons and the sticky commit bar. It also covers borrowing 21st.dev components without inheriting their skin. **Photography is not optional.** Zero images is a bug, not a restraint, and the usual failure is a pretty image with the wrong context (a tropical beach on a Chiang Mai page). `references/imagery.md` covers choosing for context, the free sources and their licences, the Unsplash URL shape, how many and which, and the labelling rules that keep stock imagery inside the honesty system. Copy is part of the design, not a later pass. `references/copy.md` carries the voice, which is the least copyable and most valuable part of the whole thing. If the project uses the house engineering spine (Cloudflare Workers, Drizzle, Wrangler, Vitest, a generated asset manifest), `references/stack.md` describes it and the photo-derivative pipeline. ### 4. The localhost review gate **Never push to show work.** The standing rule is to put it on localhost and hand over the link first. Then verify it yourself before claiming it works, at 375px, 768px, and 1280px, because "I thought you checked everything" is what gets said when a hero video silently fails on mobile. `scripts/shots.mjs` captures the three widths in one command so review is a glance rather than a chore. ### 5. Critique, in the house vocabulary Work is reviewed with a small, consistent set of words. Treat each as a named defect class and check for it *before* presenting, since finding your own faults is much cheaper than being handed them: cluttered · chopped off · out of place · odd · over complicated · too generic · ai slop · negative empty space · too much scrolling · irrelevant · not seamless `references/taste.md` turns each into something checkable. ### 6. Multi-lens audit before any customer sees it Before a client preview the question asked is always some version of "check and verify, no loose ends". One reviewer misses things a panel catches, so fan out across independent lenses and then verify each finding against the source before keeping it, because unverified findings waste more time than they save. `references/audit.md` describes the five lenses and `scripts/design-audit.mjs` is a ready-to-run harness. ### 7. Ship, then check the live URL Deployed is not done. Load the real domain on a real phone viewport and confirm the thing you fixed is actually fixed in production. ## Cost gate for paid generation If a step spends money (image or video generation, paid APIs), print the plan and the expected cost and get a yes first. A costly render that came back wrong after a long planning phase is a specific, remembered failure in this house. The `generate` skill enforces budget caps and is the right front door. ## House hard rules - **No em dashes or en dashes anywhere**, in code, copy, comments, or commit messages. Use commas, colons, periods, or parentheses. - Mobile navigation is consistent on every page, and stale pages get deleted rather than left to rot. - Self-host fonts as `woff2` and preload the two that matter. Both live sites do this; it is why they feel instant. - Thai and Latin should share one face where possible. The instrument reference uses `LINE Seed Sans TH`, which carries both and saves a whole fallback problem. - Accessibility is not optional polish: real contrast, real focus states, real alt text. Sample rendered pixels rather than trusting the token values. ## What this skill bundles ```bash # The review gate: every route, three widths, with the numbers that matter. node ~/.claude/skills/signature-design/scripts/shots.mjs \ --base http://127.0.0.1:8788 --routes / /gallery /contact --out ./shots # reports HTTP status, scroll height in screens, horizontal overflow, broken # images, rendered em/en dashes, console errors. Then LOOK at the PNGs. # Generate the six-agent audit, with your paths and priors filled in. node ~/.claude/skills/signature-design/scripts/design-audit.mjs \ --repo /path/to/source --base http://127.0.0.1:8795 \ --routes / /events --tests 271 --out ./audit-workflow.js # then run it: Workflow({ scriptPath: "./audit-workflow.js" }) # A copyable design contract to start from. cp ~/.claude/skills/signature-design/assets/tokens-starter.css ./src/tokens.css ``` `shots.mjs` finds `playwright-core` in the npx cache on its own, so there is usually nothing to install. If it cannot, it tells you the one command to run. ## Where to go next Read the reference that matches the step you are on. They are written to be read one at a time, not all at once. | File | Read it when | |---|---| | `references/taste.md` | Deciding what "good" means here, or self-checking before a review | | `references/tokens.md` | Writing the design contract or starting a new project | | `references/webapp.md` | **The register is instrument.** Density budget, footer nav, compaction, the delight components, 21st.dev | | `references/patterns.md` | Building a specific component | | `references/imagery.md` | **Any page with photographs.** Choosing images with the right context, free sources, labelling, performance | | `references/copy.md` | Writing any user-facing words | | `references/stack.md` | Standing up the app skeleton or the asset pipeline | | `references/audit.md` | Preparing for a customer preview | For the Blender 360 virtual tour, that is a different toolchain entirely and lives in the `signature-360` skill.