seenry

Seenry

The standard is simple: clean, premium, no AI slop, at the level of the best big-company product design and the best independent studios (Stripe, Linear, Apple, Attio, Figma, ARKET, kargul.studio). Everything below serves that. Read this whole file before building; the rules that decide quality are here, not in the guides.

Work in the project's existing stack. If the project has tokens, components or a DESIGN.md, read them first and extend them.

Finished means the gate has seen it. Any new page, screen, dashboard or redesign is not done until node scripts/check.mjs <file or url> --brief <brief> --mode quick has run on it at desktop and phone, its blockers are cleared, and the critic's fixes are applied. Run it even when the page looks finished or the request was one line; never report done, or hand over a preview link, on a page the gate has not seen. Report the score and its level honestly: pass (9), leader level (8) or below leader level (7 or less) with the remaining gaps. Polish and showcase modes go further when the person asks for them. Never end your turn while image generation, a build or the check is still running in the background: wait for it, then finish, because in one-shot and headless sessions ending the turn ends the work.

Start complete, then remove the tells

Every screen starts from the complete, conventional version of itself: what the best products put on that kind of screen, with the affordances people look for (a welcoming header on an onboarding dialog, icons that help people recognize options, a billing toggle and FAQ on pricing, an identity row on a profile). Seenry's slop rules then remove decoration: eyebrows, rails, leading dots, gradient blobs, italic accents, filler. They never remove content, affordances or recognition aids. When a screen looks tidy but thinner than the leaders' version of it, it is unfinished.

Before building any screen, write its inventory: the eight to twelve things the best products put on that kind of screen. Cover the data each item shows (columns, facts, statuses including the edge ones such as out of stock, pending, overdue or failed), the actions on each item (edit, remove, change role, add to list), the actions on the whole screen (create, invite, import, filter, search, sort), and the states (empty, loading, error, a single item, many items). Use Seenry MCP when it is connected to see how leaders lay that screen out; otherwise use what you know of them. Build every inventory item that needs no new backend, wiring actions to handlers the owner can connect, then check the inventory off again when you verify. A screen missing an inventory item a user would look for is unfinished, however clean it is.

Inside an existing project

When the request adds or changes something in an app that already has its own screens and styles ("fix the settings page", "add a pricing page", "add an empty state", "make this modal nicer"), use this path instead of the flow below. The owner wants a pull request they can merge, not a rebrand. A change that looks great but does not look like their app is a failed change.

Read the app first. Find its styling method (Tailwind utilities, CSS modules, plain CSS with tokens, styled-components), its component library (shadcn, Radix, its own), its tokens, and two or three neighbouring screens. Render one of them. The new work must look like the same team made it: same type, colors, radius, spacing, density and component style. Bring Seenry's craft (hierarchy, alignment, spacing rhythm, readable sizes, states, copy) inside that system; do not import Seenry's defaults, kits, fonts or palette over it.
Keep the behavior, fix the presentation all the way. Every existing action, field, setting and piece of information architecture keeps working the way it did: no new save models, no persistence the app did not have, no tabs that are really anchors, no renamed actions ("Upgrade" stays "Upgrade"). Presentation is yours to fix completely, and a timid cleanup is a failed change too: replace raw controls with the app's own components (its inputs, selects, buttons; switches for on/off preferences), give each group the same container and label layout the app uses elsewhere, put destructive actions in a calm, clearly separated zone with a normal-case outlined or destructive button, fix shouting copy ("DELETE WORKSPACE" becomes "Delete workspace"), and add short helper text where a setting is unclear. The bar is that the changed screen becomes the best-looking screen in their app. Copy is presentation too: cut long paragraphs to one or two sentences, make first-use actions say what they do ("Create your first project", not "New project"), and where someone has to decide something, fold the guidance or example into the sentence that is already there instead of adding another line. An onboarding or welcome dialog opens with a centered welcome: the brand's mark or one small illustration on the dialog surface or a very light tint (never a heavy saturated band), a friendly title and one sentence. The backdrop dims the page clearly (around 40 to 50% of the ink color) at every width so nothing behind competes. Checkboxes and radios are styled in the brand (rounded, filled with the accent when selected, checkmark drawn), never the browser default. On phone, a short question and its stepper share one row. Choices are tiles with a small icon from the app's icon set, a clear selected state (tint plus check) and real multi-select controls for multi-select questions; numbers use a stepper. The footer pairs the primary action with the secondary one as a real button, not a faint link. Dialogs keep a visible close button, and focus rings appear for keyboard focus only (:focus-visible), never as a ring on a control the moment a dialog opens. Use product and plan names exactly as the owner wrote them. Add the sections that kind of surface normally has, and nothing decorative beyond them. A redesigned screen also gains the standard parts of that kind of screen that a user would expect, as long as they need no new backend: a profile section opens with an identity row (avatar, name, email) and a "Change photo" action wired to a file input or handler the owner can connect; when the app's navigation uses icons, section headers carry the matching icons from the same set; fields that need a word of explanation get one line of helper text. Plain and tidy is not the goal; complete and calm is. A collection screen (recipes, products, projects, files) gives each card the actions people expect on it, usually save or favorite and the item's key facts, with any category label at readable size (at least 14px, never a tiny eyebrow). A featured item is not repeated in the grid below it, and the grid still fills its rows evenly and matches any count shown (feature a different item, or keep the full set in the grid). The featured item offers the real next step for that product ("Add to this week", "Open project"), not a minor action like favorite. Give every image in a collection one consistent treatment (same crop ratio, similar light and tone). Give the collection one featured moment that ties into the product's main flow (a recipe to "Plan this week", a project to "Open board"). On phone, filters never clip off the edge: they wrap into at most two neat rows of chips, or collapse into one "Filter" button that opens a sheet, and the collection starts within the first screen. A settings or preferences list gives every row the same anatomy: a short title of two to four words and a one-line description beneath it, on every row or on none. Rewrite sentence-length labels into that pair ("Notify me when a request I voted on ships" becomes "Shipped requests" with "When a request you voted for is released"). Off switches must stay clearly visible as available (track at least 3:1 against the surface), and a destructive zone explains itself once, inside its own card. An empty state is three things in a calm card or centered block: a plain headline that names the condition ("No projects yet"), one sentence on what the thing is for, and one primary action. While the list is empty, hide whatever repeats it on the same screen (a "0 projects" count, a toolbar button that does the same thing as the empty state's action, an empty table header). Tint the icon with the app's accent at low strength rather than grey. It fills the region the list would occupy (the list's own card or panel, at least about 60% of the visible content height) on a calm surface, with the content centered inside it, so the page reads as a placeholder for the list rather than a small card above blank space. Alongside the primary action offer one secondary path (import, use a template, or learn how it works). Under the action add one short line of guidance that says what to start with ("Start with a product, an app or an area of your business"), one step smaller than the body text, muted but readable (at least 14px). A new surface must be complete enough to use: a pricing page puts a monthly/yearly segmented toggle above the cards with the saving on it, gives each plan exactly one primary action, keeps the other price visible as a line under the main one ("or $48 a year, save 20%"), marks the recommended plan, and closes with a short FAQ that answers billing, cancellation and what happens to data on the free plan; every plan on a pricing page has its own clear action (link it to the app's existing sign-up or upgrade route, or a handler the owner can wire up), the recommended or paid plan carries the primary action, and every state the request names is reachable. Never put implementation caveats in interface copy ("saved in this browser", "demo data").
Write in the project's idiom. Tailwind and shadcn projects get utilities and the existing components, never a block of page-specific rules in the global stylesheet. Plain-CSS projects get styles beside the component using the existing tokens. Use tokens and existing variables, never new hard-coded hex values.
Research when the screen changes shape. A new surface (a pricing page, an onboarding flow, an empty state) or a request to fix how a whole screen looks ("the settings page looks ugly", "make the dashboard better") gets one quick Seenry research call before you edit: research_design_brief with the request, family websites or apps, an asset_query naming the screen (settings, pricing, team members) and two or three structural queries, then one compare_measurements on the references you keep. Take the parts leaders put on that screen and their measured spacing and type into the edit, in the project's own components. Skip research for a bug, a single control or one state. No idea generation, three-way exploration, signature component, motion spec, design sheet or critic loop unless the owner asks for a redesign.
Verify the way a reviewer would. Build. Render the changed screen at 1440 and 390, check every state you touched, and render one untouched screen to confirm nothing else moved. Run node scripts/review_board.mjs <url of the changed screen> --out $TMPDIR/seenry-review (about ten seconds) and fix every blocker your change introduced, such as an eyebrow, a repeated photo or a typed-symbol icon; leave the app's existing type scale and weights alone unless the request is about them. Fix what you see, then stop.
Leave the repo clean. Screenshots, notes and scratch files go outside the project (for example $TMPDIR/seenry-<project>/), never into .seenry/ or the working tree. Do not create DESIGN.md unless the project already has one or the owner asks. The diff contains only the product change.

Report in three or four sentences: what changed, what stayed the same on purpose, and anything the owner should decide.

One-line requests for a new site

When the whole brief is one line ("landing page for my habit tracker", "I'm a wedding photographer, need a portfolio site"), the person expects a complete site they could publish today, not a restrained sketch, and they are waiting for it. Run the flow below in quick mode unless the person asks for more; aim to finish in about ten to fifteen minutes, as fast as any design skill, because the quality comes from the research, the idea and the rules, not from review loops (in testing, first builds already scored at leader level and long loops added 0–1 point). Preview on the dev server while you iterate and run the production build once at the end; when check.mjs lists blockers, fix every one of them before running it again rather than one per round: one research_design_brief call plus one borrow_references call, reading pixels only for the two strongest results; build the three first screens for pick.mjs as quick first-viewport sketches (the pick is what gives the page its identity, so never skip it); source or generate all imagery in one batch with one variant per slot and one photo check; and run check.mjs --mode quick: it clears the automatic blockers, asks the blind critic once, and you apply its fixes once and deliver with the score and level (pass 9, leader level 8, below leader level 7 or less). Use --mode polish (up to four critic rounds, stopping at leader level) when the person asks for polish or a production-ready page, and --mode showcase (the full gate with a second direction, an hour or more) only when they ask for a showcase, a portfolio piece or the best possible result. In quick mode, a score below leader level is reported as such with the critic's top gaps, never as finished work. Hold the result to these:

Include what that kind of site always has. App landing page: what the product is and who it is for in the first line, the product shown large and real, three to five features each shown rather than listed, proof, pricing when it is a paid product or the navigation mentions it, a closing call to action, footer. Portfolio: the person's name and strongest work first, galleries or case studies, an about section with a portrait, process or packages, kind words from clients, an inquiry form. Dashboard: believable populated data, working filters, every figure readable.
Every navigation link leads to something that exists on the page or in the build.
Restraint is not sparseness. Calm comes from hierarchy and spacing, never from leaving content out. Each section carries specific material at real size; a section that is mostly empty tint or a small mockup in a large field is unfinished.
Write as the owner. Copy is in their voice with realistic placeholders they can swap; stock imagery stands in for their work, so it carries no visible creator credits (those go on a credits page or footer link), and the page never names another person as its author.
The claim is specific and leads. The headline states this product's concrete promise with a noun, number or mechanism that only this product can claim (for an invoicing tool: "Paid in 2 days, not 30"; for a bike shop: "Flats fixed while you wait"), never a mood any competitor could print ("A little warmth. Anywhere."). Never reuse an example from this file: write the claim from this brief. The most ownable idea is the first screen, not a strip further down.
Design the middle, do not list it. Each section has one dominant element at large scale (the product doing one thing, a photograph, one number, one quote) and clearly smaller support. Never three or four equal cards unless the content is a true set of equals; feature one and let the rest support it. Consecutive sections change composition (split, full-bleed image, dominant product moment, dense data, single quote, schedule): the same heading, paragraph and cards rhythm twice in a row reads as a template.
Proof proves the headline. Every feature visual shows the specific claim beside it working (the missed-day recovery screen, the schedule with real spots left, the before and after), not a generic dashboard or a mood photo.
One memorable move. Restraint alone reads as a competent template. Give the page one ownable, confident move at real scale, carried from the hero to the footer: a display face with character set large, the brand color used as a full field, art-directed imagery with a consistent treatment, or a signature interaction. Everything else stays quiet so it can be remembered.
Its own identity. The accent and type come from this product's idea, never the default SaaS indigo, violet or blue, and never the common template of cream background, terracotta accent and italic serif accent words. Inter on every brand page is also a default: for lifestyle, food, wellness, hospitality and portfolio brands, choose a display face with character from the type table.
A confident identity. Pages that win look decided: one saturated or deep brand color used at full strength in one or two large fields (a hero ground, a product stage, a deep closing band) against near-black ink and neutral surfaces; a display face with character set large, at least three times the body size; and at least one dark or fully colored section to change the page's temperature. Take the color and type decision from the chosen idea; with Seenry MCP, use the kept references' get_tokens only to confirm you are not on the category's most common hue and face.
Write it as their real site. Use believable names, prices, hours and copy, and never print a note on the page that the content is sample, placeholder or yours to replace (check.mjs blocks it). Tell the owner what to swap in your summary and in DESIGN.md instead.
Consumer products need warmth. Habit, health, food, money, family and hobby apps are bought on feeling as much as features. Give the page one emotional anchor at real size: a photograph of the life moment the product serves, a full-bleed band in the brand color, or the product in a hand or a real setting. Vary section grounds (white, a tinted band, one dark or photographic band) instead of separating everything with hairlines.
Show the product, do not repeat it. One large product moment in the hero and at most two more, each showing something different (the daily check-in, the weekly view, a reminder). The same list or calendar appearing in several sections reads as padding. A landing page has no working forms other than sign-up or the waitlist; a try-it demo is a visual, not a second form competing with the call to action.
Landing-page type is larger than app type. Body 18, supporting copy 16 and nothing a visitor should read under 15 at 1440, including labels inside product mockups.

Taste

Taste is trained, not invented: it comes from looking hard at the best work and asking why it feels right. Seenry gives you the library for that; use it every time.

Unseen details compound. Nobody notices a 1px hairline, a concentric corner, tabular figures or a 140ms hover on its own. Together they are the difference between "tidy" and "expensive". Do all of them.
Remove before you add. Every element must help someone read, choose or act. When a page feels plain, the fix is almost always better material, scale or spacing, not more decoration.
One idea per view, carried all the way. One dominant element, one owned detail, one signature motion moment. Everything else is quiet so those can speak.
Real over representational. Real product UI, real photography, real data and specific copy beat any illustration of them.
Motion is part of the design, not a finish. A page that does not respond feels unfinished however good the stills look.

The flow

Brief (2 minutes). Audience, the one job of the surface, the real content, what is fixed. One sentence of intent.
Research with current Seenry MCP. Prefer connected tools: load get_library_guide, then research_design_brief with the actual brief, an explicit reference family and up to three focused queries. Inspect actual returned pixels and read coverage, gaps, constraints and the source-backed decision rubric. For scripted access run node scripts/research.mjs --brief BRIEF.md --type <landing|product|dashboard|studio|pricing|app> --family <websites|sections|apps|branding|decks|motion> --terms "<up to three comma-separated queries>". It uses SEENRY_PRO_KEY already configured in the environment; never ask for a secret in chat. The bounded script makes three tool calls, planned maximum 11 credits, and preserves results in .seenry/research/. Authentication, quota or tool errors stop the run. Without a script key it writes a clearly unresearched manual handoff; use connected MCP or permitted web research, not an invented pack.
- Draft the idea before you look. Before the first research call, write step 3's claim, proof and five candidate ideas in .seenry/idea.md (ideas only: no palette, typeface or layout). Write the brief and queries from the product, the audience and the job the page does ("habit tracker app for people who quit streak apps", queries "habit tracker", "fitness app", "streak"), never from a look you already have in mind. The survey tells you what the category always does; it does not choose your color, type or composition.
- Study the survey before choosing. The research result carries a contact sheet of up to eight candidates, one per product, with thumbnails. Look at every one and write two lists at the top of .seenry/refs/kept.md: conventions, what most of them do that helps people use the page (navigation, message order, where the action sits, pricing anatomy), which you meet; and clichés, what most of them do for identity (the same hue family, hero arrangement, mockup angle, type voice), of which you share at most one. Keep two or three screens for craft and say which lesson each sets (spacing, type detail, image finish, density). Use category words in queries ("analytics hero", "payments pricing", "meal kit onboarding"); the library matches each site's industry. If the category is still thin after that (fewer than five in-category candidates), also run scripts/bar.mjs on two or three category leaders' live sites and keep those as the craft bar; use the library only for structure. A weak survey (fewer than five candidates from this product's category, or ones you would not show the client) means a better query, not settling: try the category's other names and its nearest neighbours (habit tracker, then fitness app, journaling app, streak).
- Then read deeper only where it pays: the two deep reads carry measured evidence; open a kept survey item with its inspect call when you need its pixels at full size.
- Save what you kept as the bar, as decision cards. Put each kept reference's screen in .seenry/refs/ (open it at full size with its inspect call and save the image; the research script already saved survey thumbnails under .seenry/research/img/) and write .seenry/refs/kept.md with one card per file: the job that screen does; the decision it makes (message order, how it proves the claim, density, rhythm, where the eye lands first); its measured numbers (headline and body size, radius, control padding and brand color, from the research result's measured block, compare_measurements or get_tokens); the craft lesson you will meet or beat; and the one thing you will deliberately not do because it is this category's cliché. A studio studies to decide, not to trace.
- Study the middle of the page too, not only the hero. After the survey, run one more search for the page's most important body section (features and proof, pricing, schedule, work, menu) with search_sections or a sections-family research_design_brief, keep the one or two that compose it best, and give each a decision card: how it makes one thing dominant, how it varies from the section before it, and how its visual proves the claim.
- Borrow from outside the category. Call borrow_references with the job your leading idea must do and the category to leave out (a habit tracker whose idea is "a streak that forgives" might find scoreboards, almanacs or learning-app streak charts). Keep one, inspect it and give it a card. The ownable move comes from here and from the idea, never from the category survey.
- Give references different jobs. Category references set the conventions and the craft bar; the outside reference feeds the idea. The hero composition, color world and display type come from the chosen idea and must not match the category's most common arrangement, and no section reproduces a single reference's arrangement, imagery treatment or signature device. check.mjs shows the kept screens to the blind critic: the page passes when it reaches their craft class (reference fit 7 or more) and copies none of them.
- Name the category's best and compose in their class. Write down at least three of the best brands in this exact category by name (independent watchmaking: Laurent Ferrier, Akrivia, NOMOS; invoicing: the two or three leaders, not whatever matched the word) and pull them by name (list_sites {q: "<brand>"}, search_designs {q: "<brand>"} or a named research_design_brief query), not by category word. The library does not hold every brand: when a leader is missing, capture its live site with node scripts/bar.mjs --type <landing|product> --sites <domain>,<domain> (bot checks are skipped, never bypassed) and keep those screens in .seenry/research/bar/ as the bar. Never settle for whatever matched the category word because the leaders were not indexed. Record in kept.md the composition class they share: the object owns the frame (luxury goods, hardware, food, hospitality), a product moment at real scale (software), an editorial or type-led page (media, studios, culture), a dense working surface (data tools). The hero is built in that class with its own idea; the leaders set the class, the average site's arrangement is what to avoid. A software split (headline left, product boxed in a rounded card right, tabs or toasts around it) is never the composition for a physical or luxury product. The critic scores category_fit against exactly this.
- Read pack.md and evidence.json, inspect one or two task-relevant sources at full size, and save inspected craft targets to .seenry/refs/ for comparison. Adjacent mobile references do not establish desktop product fit. The apps family contains captured mobile apps; choose websites/sections for web surfaces unless a mobile analogy is intentional.
- In DESIGN.md, list the references you kept and the ones you set aside, explain what each kept source proves, what you adapt and which relationships remain unverified. The design is your own: take patterns, never copy a page. The final summary credits the kept references by name. Query matching and numerical critic scores do not certify taste.
- Measure before you set type, radius and spacing. Call compare_measurements on 2 to 4 of the references you chose (5 credits) for their shared headline and body sizes, radii and control padding, or get_tokens on one page for its colors and families. Record them in DESIGN.md and use them as floors and ceilings for reading and control craft only (body size and line height, control height and padding, radius proportion, section spacing; the research result's measured.floors). Display size, headline scale, palette and composition are never averaged: the idea and the type table set them, and going past the measured headline range is expected when the idea calls for it. Without MCP, use benchmarks.
- For complete flows, split-page captures, measured design context, motion and PDF rules follow current MCP research. Study recordings only when relevant motion evidence is needed.
Find this brand's idea. Follow design thinking: write the product's claim, proof, moment and material; generate at least five ideas with different designer moves (make the claim literal, let them do it now, proof inside the language, before and after, a physical truth, the detail that proves care, take something away, change the unit); score them on truth, clarity, distinctiveness, restraint and buildability; choose one and carry it through hero, signature moment, imagery, copy and one detail. Save it as .seenry/idea.md. Kits and references are how to build the idea, never the idea; two different briefs should never end up with the same signature.
Explore the first screen, then pick blind. Build three first screens from your three highest-scoring ideas in .seenry/idea.md, one idea each, as separate files; with Seenry MCP, at most one follows the category conventions as the safe control, each of the other two breaks a listed cliché, and one of them is built on the outside-category reference, so the three candidates are three studied directions rather than three guesses. Choose the three ideas from idea.md by distinctiveness first; references inform how each is built, never which ideas survive (.seenry/explore/a.html, b.html, c.html). They must differ in what the visitor sees first (a working product moment, the claim made literal, a single photograph, type alone), not only in arrangement: three layouts of the same headline, field and photo is one option, not three, then run node scripts/pick.mjs .seenry/explore/a.html .seenry/explore/b.html .seenry/explore/c.html --brief <brief> --refs .seenry/refs/<a>,<b> (the task-relevant craft targets you inspected). Build the page on the winning idea, record it as the chosen idea in idea.md, and fold in what the pick says to take from the others. Studios never ship their first composition; neither does Seenry.
Direction in five lines. Neutral temperature and one action color; type from the table below; radius family; imagery; the one owned detail and the one signature motion moment. Pick the obvious premium answer before a clever one. For a new or changed identity, also follow seenry-branding (its skill) and its project guidelines.
Motion spec. Read seenry-motion now. When reference motion is relevant, retrieve and play the selected recordings (signed links expire), pull frames around their most-movement window with python3 ../seenry-motion/scripts/video_frames.py, and write .seenry/motion.md: for each moving thing, the trigger, what moves, duration, easing or spring, stagger, interruption and reduced-motion behavior, and which reference it came from. Include the signature moment and every in-place change (numbers, filters, add-to-bag).
Material. Photography and imagery via seenry-assets, art-directed and passed through photo_check.mjs (see Imagery). Illustration and ambient visuals per Craft below.
Build on the floor. New app screens can start from the product kit; established products retain their component and motion system. Implement .seenry/motion.md with that system, or use motion.css and motion.js when a plain page needs a starting point. Do not load a second runtime merely to satisfy this step; use the compatible components and purposeful signature moment described below. Set font, neutrals and accent from step 3.
Check. Run node scripts/check.mjs <file or url> --brief <brief file> --mode quick by default (one critic round; --mode polish or --mode showcase when the person asks for more, as in the one-line section). The rest of this step describes the full showcase gate. It verifies the research pack, references, motion spec and DESIGN.md exist, checks slop, readability, radius and interaction evidence, sends photographs through the photo check, then asks a blind critic, a fresh model that sees only the screenshots, the brief and your reference screens, to score the page, and runs the motion judge, which samples eligible controls, records their transitions, measures durations, easing, animated properties, layout shift and reduced motion, and scores purpose, timing, spatial logic, smoothness and consistency. Apply every design and motion fix it prints and run it again until PASS (critic 9+ and every declared web-motion criterion and reviewed interaction row at 9+, with complete captured-label coverage and no reported motion violations). Scores are heuristic review signals, not competitor superiority claims. This applies only to the interactions actually captured; untested components remain unverified, and native-video legacy results do not certify the web per-criterion bar. The final result must be a checked version: if you edit after the last round, check.mjs runs one more verification round. On LAST ROUND, make the one root-level change it asks for; in --mode showcase, on STOP or STOPPED below the target, the concept is the problem, not the polish: go back to step 4, build the page on a different idea from idea.md (a different first thing the visitor sees, not a re-layout), and run check.mjs --new-direction once, which archives the first direction's rounds and gives the new one a fresh budget. Only if the second direction also stops, return the better of the two with an unresolved status and its remaining failed or unverified criteria. A best-so-far result is not a pass; unavailable judging or an exhausted repair budget must not become acceptance. Never finish on your own opinion of the page: in testing, self-review rated 9 what blind review rated 6–7. Native apps (SwiftUI, UIKit, React Native, Flutter) use the same gate on simulator output: node scripts/check.mjs --screens home.png,detail.png,sheet.png --video rec.mov --brief <brief>, with screenshots in flow order and a screen recording of the interactions (xcrun simctl io booted recordVideo rec.mov, or adb shell screenrecord); the critic scores the screens against the bar and motion_video.mjs judges the recording.
Review and deliver. For a second opinion on states and accessibility use seenry-review. Write the "Brand guidelines" section of DESIGN.md and give the report below. The design sheet is optional and comes last (sheet).

For changes inside an existing app, follow Inside an existing project instead of this flow.

Design first: do what AI usually does not

Every model reaches for the same first screen: headline and subhead on the left, two buttons, a product card or illustration on the right, a pill badge, three stats. Plain models already build that cleanly, so matching it is no result. Before writing code, write in .seenry/idea.md the AI default for this brief in one line, then build at least one of these moves into the first screen, taken from the category's best brands:

Art direction carries the page: one real photograph, a product at full bleed or type set as the image, not a framed mockup beside text.
Scale contrast: one element far larger than anything else (a number, a word, the object), everything around it quiet.
A specific claim: a noun, number or mechanism only this product can say ("612 pairs, each numbered by hand"), never a mood.
Editorial composition: an asymmetric grid, a crop that leaves the frame, a page that reads like a publication rather than a template.
The product's own behavior made visible: the one interaction or detail that proves the claim, at real scale. If the first screen could swap in another brand's name and still work, it is the AI default; rebuild it before the gate. The critic scores idea and category_fit against exactly this.

The standard

Leading teams look premium for one root reason: they ranked the job, then removed everything that does not serve it. Calm is the visible result. The reasons behind each rule are in premium.

Never ship these (check.mjs blocks most of them):

Eyebrows: a short small line above a title, in any case ("Good to know", "Your neighborhood yoga studio" over the h1). Cut it; the title says it, and card facts such as duration or level go under the title. Uppercase letter-spaced labels are slop anywhere.
Numbered labels: "01 /", "(001)", "No. 03", "Step 01". Numbers only where order is real, as plain figures.
Weights of 700 or more in UI, or more than three weights on a page.
Italic serif accent words in headlines; trendy default faces used for flavor (Instrument Serif, Fraunces, Playfair, Space Grotesk, Clash Display).
The default AI palettes: cream + terracotta or orange, plum + peach, navy + lime, forest green + cream as a costume, purple gradients.
Clip-art imagery: sunset circles, vinyl records, flat SVG product stand-ins, tilted floating cards with sticker badges, gradient blobs, glows.
Colored KPI hero cards with rings or stripes, a decorative icon tile in every card (icons that help people recognize an option or a section are fine), a card per row, saturated pill badges down a column.
Generic slogans ("X is better together", "Built for the way you Y"), fake stats, lorem.
Text people must read under 13px, or in a light grey that fails contrast.
Template furniture: rows of example chips, four-up icon feature grids, logo walls of nine or more marks, outlined mini-cards repeated down a section. Show one clear example, three strong points, or the six marks people recognize.
Framework default colors as the brand: Tailwind blue-600/indigo-500, violet-600, emerald-500, orange-500 on near-black. Derive the accent from the brand or its material and correct it in OKLCH (below).
One-sided borders as decoration: an accent rail down the left edge of a card, quote or callout (border-left: 3px solid), or a selected tab, filter or link marked with border-bottom on an element with a corner radius, so the line bends at its ends. Separate cards by surface tone and spacing; draw a tab indicator as its own straight bar (check.mjs blocks both).
Text symbols standing in for icons or a logo: an asterisk, sparkle, star or emoji as the brand mark, Unicode arrows (↗ → ←), check marks or bullets typed as characters inside buttons and links. An asterisk, sparkle, star, burst or flower is the default AI logo whether it is typed or drawn as SVG, and so are decorative ✳ ✦ ✧ scattered as ornaments; never use one. Logos are a wordmark set in the brand type, or a mark drawn from the product's own idea; icons come from one real icon set as SVG (Lucide, Phosphor or Tabler) at a consistent size and stroke (check.mjs blocks typed symbols).
A short rule or dash in front of a label ("— A notebook that thinks with you", a 20px line before an eyebrow). The label stands alone, in sentence case, or is cut.
Colored dots in front of text ("● Active", "● Paid", status pills with a leading dot). A dot is only right when it is the whole message: a live or recording indicator, online presence on an avatar, an unread marker in a list; mark those with data-seenry-dot="live|presence|unread" (check.mjs blocks any other dot before text).
"Many" drawn as a cloud or wall of tiny chips, domains, logos or dots (it turns the claim into decoration), and production notes in the page body ("these marks are invented", "demo data", "placeholder"); a one-line disclosure in the footer is fine.
Placeholder art: blurred gradient blobs, CSS gradients or code-drawn shapes standing in for album covers, product photos or avatars.

Color. Neutrals do the work, defined as roles: canvas, surface, selected, rule, three text levels. Pick the temperature once and keep every grey in it. One action color, used only for the primary action, selection and focus, so it is always findable. Status in data views (tables, lists, dashboards) is a quiet tinted pill with the word only (14/20 500, pale tint of its tone, no leading dot); the exception that needs action (Overdue, Failed) may be the one strong color. Outside data views, pills and chips need a real reason (a filter you can remove, a selected token, a live count); decorative pills, "New" chips and pill-shaped labels by reflex are slop. A brand surface may have one bold field (a dark band, a photograph); never a second accent.

Build it in OKLCH with python3 scripts/palette.py "<accent hex>": neutrals share one hue with chroma 0.002–0.012; steps are even in lightness (canvas 0.985, surface 1.0 or 0.97, rule 0.92, text 0.22/0.45/0.58 in light). The accent sits at lightness 0.50–0.62 and chroma 0.12–0.20; its hover is 0.04 darker; its subtle tint is lightness 0.96 at chroma 0.03.
Premium palettes that work: cool graphite + one electric accent (Linear, Vercel: neutrals hue 250–270, accent indigo or blue); warm stone + deep ink accent (Aesop, ARKET: neutrals hue 60–80, accent near-black green, oxblood or navy); pure white + black + one saturated brand color used sparingly (Apple, Stripe). Sample the accent from the hero photograph or the product when there is one, then correct it to the lightness and chroma above.
Own a color world; there is no house palette. Take the hue from the product's own world and the idea (crust and butter for a bakery, track orange for a running app, ink and paper for a notes tool), never from a default, and choose the canvas as a decision: a light neutral canvas with bold color fields, a canvas in the brand color itself, or a dark canvas. Warm off-white with charcoal text and one muted green or olive accent is the AI default; use it only when the idea makes the case, and say why in DESIGN.md.
Committed, never washed. Pale tints (lightness above about 0.9 with a little chroma) are for a selected row or a small status, never for section or card backgrounds. A page built from mint, lavender and peach panels reads cheap and unfinished. Use neutral surfaces for structure and put the brand color at full strength where it counts: the primary action, one or two bold fields (a full-bleed band, the product's background, a deep footer) and the key figure. One bold color used with conviction reads premium; five pale ones read like a template. check.mjs blocks pages with several tinted panels.
Dark mode is its own palette, not an inversion: canvas lightness 0.14–0.17 (never #000), surfaces step up by 0.03–0.04, text 0.96/0.72/0.58, borders at 8–12% white, accent raised 0.06–0.1 in lightness, shadows replaced by lighter surfaces.
Color on images and gradients: text on a photograph gets a scrim from the image's own darkest tone, never a generic black overlay; gradients are allowed only as one soft light falloff in a single hue, never as a multi-color background.

Type. Use the brand's face if it has one. Otherwise pick from this list; these free faces are the closest to what the big companies use, and each needs its tuning to look expensive:

Surface	Face (Google Fonts, self-host the WOFF2)	Tuning
App screens, dashboards, SaaS	Inter (variable, with `opsz`)	`font-optical-sizing: auto`; `font-feature-settings: "cv11", "ss01"`; titles 600 at −0.015em; body 400 at 0
Developer and technical products	Geist + Geist Mono	display 500–600 at −0.035em; mono only for code, IDs and keys
Consumer tech and product marketing	a grotesk with character for display (Schibsted Grotesk, Familjen Grotesk or Instrument Sans) with Inter for text; Inter Display or Geist when the brand is deliberately neutral	display 56–80 at 500–600, −0.03em, line height 1.02–1.08
Lifestyle, food, wellness, hospitality, local business	a roman serif with presence for display (Newsreader or Source Serif 4 at display optical size, or Libre Caslon Display) with a quiet grotesk for text and UI	display 64–96 at 400–500, −0.02em, line height 1.0–1.08, roman only; the serif carries every headline, not one accent word
Photography, portfolio, studio, editorial brand	the work leads: a large roman serif display (Newsreader, Source Serif 4 display, Libre Caslon Display; Bodoni Moda for fashion) or a refined grotesk, set big against generous space	display 72–120, tight; captions and metadata in the grotesk at 14–16
Commerce, fashion, craft goods	Inter Tight for display with Inter for text, or Hanken Grotesk	product title 40–56 at 500, −0.02em; prices 500 tabular
Apple-feel web	`system-ui` (SF Pro)	display 600 at −0.02em; never download SF Pro
Editorial, long reading, hospitality	the sans above + Newsreader or Source Serif 4 for long-form text only	serif at 400 for reading, never as italic accents or display flavor
Civic, public service, cultural, premium consumer (America.gov, publications)	a neutral grotesk for all UI and headings (Inter, Geist, or a licensed Helvetica Now) + an editorial serif for one or two display moments (Newsreader or Source Serif 4 at display optical size, or a licensed face such as Rhymes or GT Super)	the serif only for the hero line and at most one closing statement, at weight 400, tracking −0.04 to −0.06em, line height 1.05–1.15, roman never italic; section headings stay in the grotesk at 500

Never reach for DM Sans, Plus Jakarta Sans, Space Grotesk, Poppins or Montserrat as defaults; they read as templates. An editorial serif is not slop when it is used like a publication uses it: rarely, large, regular weight, tight, roman, against a quiet grotesk. It is slop when it is a trendy face (Instrument Serif, Fraunces, Playfair) sprinkled through headings or used as an italic accent word. One family per page plus a mono or reading serif only with a reason. Tune the chosen face: display tracking −0.02 to −0.03em, text-wrap: balance, real punctuation. Weights by role: 400 values and body, 500 labels, controls and row anchors, 600 titles and the key figure. Minimum sizes at 1440 (check.mjs blocks below them): paragraphs 16, any other readable text 15, short labels such as table headers and chips 14; pages are judged scaled down, so what reads as comfortable at 100% reads as faint in review; body text at least 4.5:1 contrast, never a pale grey. Table cells and row metadata use text-1 or text-2, never text-3; secondary grey is for labels, not for data people read. App screens: 28/34 page title, 16/24 body, 15/22 cells and row text, 14/20 meta and table headers in Title Case; the key figure 32–40 at 600. Brand surfaces: display 56–80 at 500–600, lead 20–22, body 18, supporting copy and captions 16, UI inside product mockups at least 14 at 1440. Money: sans, right-aligned, tabular in columns, consistent cents, real minus sign.

Radius and elevation. Radius says what a shape is and how big it is; getting it wrong is one of the fastest ways to look generated.

Pick the family once, from the brand: sharp (0–4, editorial, fashion, technical: ARKET, Swiss print), product (6–12, tools and commerce: Stripe, Linear, Apple Store cards at 12–18), soft (16–24, friendly consumer). Every radius on the page comes from that family.
Radius by role and size: small parts (tags, checkboxes, 28–32px buttons) 4–6; controls (36–48px buttons, inputs, selects) one shared value, 6–10; cards, panels and tables 12; large media, sheets and dialogs 16–20; full pill only for status chips, toggles, avatars and segmented-control thumbs.
Proportion: a control's radius is at most 25% of its height (40px tall → 8–10) or exactly a full pill. Anything between 26% and 49% looks like a mistake (check.mjs flags it).
Neighbors match: a button beside an input, and every control in a toolbar, share one radius and one height.
Concentric nesting: inner = outer − inset (card 16 with 8 inset holds 8; card 12 with 16 inset holds square or 4 content). Never the same radius on a parent and its inset child.
Edges: anything full-bleed or touching a container edge is square on that side; media flush in a card takes the card's radius only on the touching corners. Tables: container rounded, cells square. Product cut-outs and photographs of objects are not rounded beyond the family's media value.
Smoothness: where supported, corner-shape: squircle inside @supports (corner-shape: squircle) on cards and media (raise the radius about 1.3× so the visual size matches); rings, focus outlines and shadows follow the same shape.
Separation and elevation: separate by space and surface tone, not lines. Group rows with spacing, tint the selected or open row, and nest a panel one surface step darker or lighter than its parent (inner radius = outer − inset). A surface edge on a same-tone background may carry one 4–8% inset ring; never stack rules between rows, under headers or around every card. Only menus, popovers, dialogs and sheets get a shadow, and they use the large radius.

Scale on desktop. Premium pages use the whole 1440 canvas with confidence; a phone layout enlarged onto a wide screen reads as a template. At 1440: content spans 1200–1280; the hero image or product media takes 55–60% of the width and most of the first screen's height; the page or product title is 40–56 on product and commerce pages (56–80 on marketing heroes); controls are 44–48 high with 15–16px labels; the primary action is visible in the first screen on desktop and within the first screen and a half on phone. Selected states are decisive: a 2px dark border or a solid fill, never a pale tint plus a hairline.

Proof at real scale. Product UI, answer cards, diagrams and mock screens shown on a page render at real size (text at least 14px, controls at their true size); if it does not fit, show fewer rows or a crop, never a shrunken miniature. On phone they become a single readable column. The proof is the loudest small text on the page: source lines, dates, agency or author names, figures and diagram labels are at least 15px in text-1 or text-2, never faint.

Composition: fewer, larger, fuller. Big-company pages feel confident because every section is one large thing at real scale, not a heading over a small list. On brand surfaces:

Every section has an anchor: one visual that takes 40–60% of the content width, or the full width, at real scale: the product working (an answer arriving, a result, the real UI with specific data), one strong photograph, a large figure with its meaning, or a diagram people can read. At most one text-only section per page, and it is a large statement (40–64px), not a paragraph.
Section headings are 40–56px (500 in the grotesk, or 400 in the display serif if the page has one) with a 20–22px lead; the hero display is 64–96px. A 28–32px section heading on a 1440 page reads as a phone layout.
Five to seven sections, each earning its height: 120–160px between sections on desktop, and each section fills most of a screen with its anchor. Merge thin sections instead of stacking many short ones; a list of four small rows is part of a section, never a section.
Rhythm: every major section is composed differently. Stacking the same heading, paragraph and bordered module down the page reads as a template even when each part is good. Plan the page as a sequence of distinct compositions before building, and use each at most twice: a full-bleed scene (dark or photographic band, the artifact edge to edge), one oversized artifact alone (a single product moment at 70-100% width with a one-line caption), a split (text 5 columns, artifact 7), a large statement or figure with nothing else, a comparison shown as one image, a quiet list or pricing close. Write the sequence in .seenry/idea.md. Change scale between neighbours too: a dense section is followed by an open one.
One focal moment per demo. A product demo, chart or card shows one thing happening, larger than everything around it (the paid invoice, the balance that moves, the reminder being sent); supporting figures sit smaller and quieter. Three KPIs, a chart and three status cards at equal weight is a dashboard screenshot, not a moment. Pricing is the one place equal cards are allowed, and even there the recommended plan leads.
One dominant element per view. On the first screen that is the headline with the one action, over or beside one image; supporting proof (an example answer, a preview) comes after the action or appears on use, never competing with it.
Replace, never just remove. When a critic or rule takes something out (a stock photo, a chip cloud, a repeated claim), put stronger material in its place, usually the product working at real scale; a section that loses its anchor and keeps only text got worse. Every section adds new proof: never repeat an example, a claim or a photo scene.
Content max 1200–1280, gutters 32 desktop and 16–20 phone, 8px spacing scale, gaps between groups at least twice the gaps inside, left-aligned text.

Layout on app screens. Summary as 0–3 figures in one divided strip, then the work (table or list) within the first screen; rows 44–56.

Imagery. Imagery is the most-cited gap between generated pages and big-company pages, so it is art-directed and checked, never accepted on the first try.

Software: the real product UI with specific data is the image. Commerce and brands: photography of the real subject. Source it in this order: supplied brand photos; the host's own image tool; node scripts/image.mjs --prompt "<prompt>" --out assets/<name>.png (or --batch jobs.json for a set, one at a time), which generates through the Codex CLI's image model from any host, Claude included; seenry-assets with an API key; license-clear photos. Generate the whole set (hero, detail, context) in one batch with the same light and surface words so it matches.
Photograph the idea, not "a person using the product". The generated-stock tells: people smiling at a phone or laptop, a parent and child looking at a screen, teams high-fiving, a hand holding a phone to camera, props that suggest a different story. Instead shoot what the idea is about: the place, the object, the moment before or after (a passport on a kitchen table, a queue that no longer exists, the city at the hour the service is used), candid and mid-action, people not looking at the camera or at a screen. Each photo on a page shows a different moment; never repeat the same scene.
People photography at most once per page. Generated photos of people top out around 7 and critics read them as staged lifestyle imagery, so use at most one (usually the hero, candid, no one looking at a screen). Every other visual slot shows the product working at real scale (an answer arriving, the result of an action, the real UI with specific data), the object or place the idea is about without posed people, or type. A section that only needs a mood photo usually needs no image.
Best of three, always: generate every shot with node scripts/image.mjs --batch jobs.json --variants 3 --brand "<brand>" --refs .seenry/refs/<a> so the photo check keeps the strongest variant; ship nothing under 7, and replace a slot that stays under 7 with type, product UI or a line drawing.
One photographic look for the whole page: decide the style once (for example candid documentary, warm daylight, fine film grain, real and varied people, eye-level 35mm) and put the same style words in every prompt, so hero, section and card photos read as one shoot.
Name the real state of the subject: roasted beans are "medium-light roasted" (unroasted beans are green), a worn product shows wear, food is plated as served.
Shoot like Apple, Aesop and ARKET: one subject, one large soft motivated light (upper left, diffused), a controlled soft shadow, a quiet seamless or natural surface (limestone, linen, pale wood, paper) in the page's neutral temperature, 85mm product height or 50mm for context shots, true geometry, a color grade that matches the palette. Plan the set, not one image: hero (subject fills 70–80% of the frame height, 4:5 or 1:1), a detail or texture close-up, and one in-use or context shot, all with the same light and surface.
Only when image.mjs and every other image route are unavailable, and sourced photos score under 7 on the photo check, do not use photos. Compose without them: the real product UI at large scale, typographic covers (the title set in the brand face on one solid color field from the palette, like editorial album art or book covers), one monoline illustration system (Craft), or the product's own data. A weak or generic photo costs more than no photo; a gradient blob is never acceptable.
Expert subjects must be plausible. A generated watch movement, engine, instrument, circuit or dish is judged by people who know the real thing. If the photo check cannot pass it for physical plausibility, do not show the mechanism: crop to the case, dial, material or the hand at work, or use a faithful 3D render. A fake mechanism fails the page, not just the image.
A real product needs its real photographs. For a client's physical product (a watch, a bottle, a dish, a room), ask for their product photography before generating any. Generated product shots are placeholders: say so in the delivery and in DESIGN.md, and never present them as the finished hero. Critics cap imagery when nothing proves the product is the client's own, so without real photos expect the gate to stop short of 9 and report that as the reason.
Keep text out of generated images: leave labels blank or minimal and set brand names in HTML, because generated lettering garbles. No clichés: scattered beans, steam wisps, floating objects, sunset circles, gradient blobs, fairy-light bokeh.
Run node scripts/photo_check.mjs <images> --use "<slot, ratio, position>" --brand "<brand>" --refs .seenry/refs/<a>,<b> before layout. Regenerate anything under 8 with the better prompt it writes; after three checks check.mjs accepts the strongest versions, so do not loop on imagery. Crop to the slot's exact ratio and export 2x WebP.

Copy. Plain, specific, short. Headlines say what it is or does for this audience; labels name the thing; empty states say what happened and the one next action.

Motion. The core rules, from seenry-motion:

No hover lift. Cards and tiles never rise or grow a shadow on hover; that move reads as a template. Hover is a one-step surface or border change; press feedback goes on :active. motion_scan.mjs blocks it.
Frequency decides. Used 100+ times a day (keyboard, command menus, list arrows): no animation. Tens of times (hover, tabs, toggles): 120–160ms, color and opacity. Occasional (menus, dialogs, sheets, toasts): 180–240ms enter, faster exit. Rare (first load, success, onboarding): room for one expressive moment.
Easing: ease-out for things entering or responding (cubic-bezier(0.23, 1, 0.32, 1)), ease-in-out for things moving on screen, never linear except for continuous loops; springs for anything dragged or interrupted.
From where, to where. Anchored layers grow from their trigger (transform-origin at the trigger); a centered confirmation dialog can use a centered origin and native backdrop. Choose the origin and exit for the relationship being explained. When a scale entrance is appropriate, start near full size, not scale 0; keep essential content immediately readable for keyboard and reduced-motion paths.
Let the flow determine dismissal. A directly expanded card or toggle surface can keep its return control at the source action point. A confirmation dialog uses its meaningful actions, such as Cancel and Delete, with appropriate Escape and native focus behavior; it does not need a redundant X. A navigation flow uses Back when that is the intended return. Preserve the relationship to the trigger when it helps orientation, without forcing every surface into the same shape or dismissal layout. Never delay readable decision content or an accepted keyboard action for choreography.
Blur is focus, not decoration. Entering text and digits may come in from a 4–8px blur with opacity and a small offset (so focus arrives rather than things sliding); only at text and icon size, never on large surfaces. Changed digits move individually, direction following the value, outgoing about 150ms ease-in, incoming about 280ms ease-out, fixed-width columns.
Interruptible. Prefer CSS transitions for simple reversible properties. When geometry or choreography needs WAAPI, retarget from the current rendered state, cancel owned work and guard stale completion. A second input replaces or reverses the accepted state instead of waiting for decoration.
Stagger 30–60ms per item, at most 5–6 items, then everything at once. A result (an answer, a search result, a confirmation) reveals as one unit with its source or proof at 0ms delay, 200ms on E, never a slow cascade; replacing one result: old out 120ms on X, new in 200ms on E, same slot. Lock a submit while it is pending instead of stacking requests.
Only transform and opacity in anything that runs often; no animating width, height, top or box-shadow on scroll.
Scroll scrubbing (progress tied to scroll, not triggered once) is for explaining a sequence: a product assembling, steps of a flow, a before-to-after. Use animation-timeline: view() or scroll() with a JS fallback (the scroll story in the signature kit), scrub transform, clip-path and opacity only, keep parallax under 40px, pin at most one section per page, never hijack wheel speed or snap. Content is readable at every scroll position and in a full-page screenshot: scrubbed elements never start below 0.6 opacity or fully clipped.
The signature moment: one crafted piece per page, built from the chosen idea, with studied references from any category informing its craft and timing (a hero reveal, a line illustration that draws in, a product UI that plays a real interaction, a canvas field behind the first screen). It runs once or ambiently, never blocks reading, and has a static reduced-motion state.

Every accepted state change must be understandable, including when it is instant. Apply the frequency and reduced-motion decisions above before adding movement. Extend the project's existing motion system; for a plain page without one, motion.css and motion.js provide a classic-script starting point. Use SeenryMotion.number(el, value, intlFormat), SeenryMotion.swap(() => render()), or a purposeful confirmation only where motion helps explain the change. Do not animate every value or delay a real result merely to satisfy a visual pattern. check.mjs samples interactions and evaluates their evidence; animation presence alone is not proof of quality, and appropriate instant keyboard/frequent/reduced states are not defects by themselves. Use the scoped motion verification checks and seenry-motion recipes for the changed interaction.

Phone. Recompose, do not squeeze: on the first screen, type never crosses a face or a busy area (stack the headline above the photo or use a phone crop with calm space, object-position chosen per breakpoint), and the primary action or field sits within the first 560px; secondary copy and controls at least 15px and 44px; bottom tab bar or menu (never a clipped scrolling tab row), compact two-line rows, 16px inputs, 44px targets. A sticky buy or action bar appears only after the in-flow button has scrolled out of view, hides again while the options it depends on (size, grind, plan) are on screen, reserves its height at the page end, and shows the full price at 15px or larger.

Components

Do not hand-roll common components. Copy the core kit (seenry-ui.css + seenry-ui.js: buttons, fields, select, checkbox, radio, switch, segmented control, tabs, menu, tooltip, dialog, sheet, toast, accordion, badge and status, avatars, cards, sortable and filterable table, pagination, empty state, stat strip, breadcrumb, kbd, skeleton, command menu) into the project, set its tokens from the direction, and restyle only through tokens. Open its gallery.html to see every state in light and dark. In React, Vue or Svelte projects, use the README's snippets or the project's own library (Radix, Base UI, shadcn) styled to the same tokens; never ship two component systems.

Any interactive component the kits do not have (hold to confirm, slide to confirm, a status island, a morphing button, a reorderable list, a scrubber, a gauge, anything with states and motion): before writing code, fill in the component brief from interaction craft (job, one idea, state graph, geometry, motion score with reasons, interruption rule, input contract, accessible result, reduced motion, runtime budget, demo, must-not-happen) and save it as .seenry/components/<name>.md; build to it, then review the result with that guide's checklist.

Transitions (chosen for the interaction)

Make state changes understandable with the existing motion system. For a compatible plain page, Seenry Transitions (seenry-transitions.css + .js) is an optional implementation: apply by attribute (data-st="modal", data-st="number" …) or the small JS API. Its tokens come from production motion, measured frame by frame from real products: curves E enter cubic-bezier(.16,1,.3,1), M move (.4,0,.2,1), F fade (.2,0,.2,1), X leave (.4,0,1,1); durations 0 / 80 / 120 / 160 / 180 / 240 / 280ms chosen by distance × size × frequency, never one duration everywhere. Anything the hand moves or that retargets often (indicators, sheets, switches, dialogs) runs on the kit's springs (--st-spring-snappy, -smooth, -gentle, -bouncy, -thumb: SwiftUI-style response and bounce baked into CSS linear()), so it reverses from wherever it is; exact values and text never overshoot. Apply the frequency, keyboard and reduced-motion decisions above to each recipe; an appropriate instant state does not need decorative movement. When motion is warranted, choose by situation:

Modals, sheets, menus and popovers use motion and dismissal appropriate to their job. Menus and popovers stay related to their trigger; a directly expanding card can preserve a source-point return control; a confirmation dialog keeps its safe Cancel action and appropriate Escape behavior. Do not add a Close or X button solely because a surface is a dialog. Bottom sheets may follow the finger and dismiss on distance or flick; a search button opens into its command palette; a card expands into its detail with cover and title travelling.
Every tab set and segmented control: a shared indicator that relocates; keyboard selection instant.
A value change that benefits from animation: only changed digits move in the value's direction, with stable numeric alignment. Frequent or keyboard-driven updates can stay instant; blur remains optional and respects reduction.
For an animated content swap (tab panels, segmented views, filters or before/after), preserve the accepted state and any outgoing paint needed to finish or reverse smoothly. Keeping layers mounted is one option, not a semantic requirement. Inactive content must not remain focusable or exposed as an active panel; apply hidden, inertness or removal at a lifecycle boundary that preserves the chosen transition, and guard stale completion. Avoid blank frames, double paint and exposed duplicate content. The motion skill's "From 8 to 9" lists what the judge checks.
Every async action: the control morphs in place within one reserved footprint (label swap, spinner, success check drawn), acknowledgement before any ornament; copy-to-clipboard rolls to "Copied" and back.
Every form error: a bounded 3px shake on the field frame plus a persistent message.
Every list change: surviving rows relocate, removed rows fade before they collapse, latest state wins.
Every loading state: skeletons in reserved geometry that cross-fade to content on readiness; AI thinking and streaming states from the kit, never dots.
Page and view navigation: side-by-side in the direction of travel, or a View Transition. Richer interactive components (slide to confirm, hold to delete, status island, combobox, date range, reorderable list, waveform player and more) come from the interaction kit, restyled to the project tokens; anything not in it follows the component brief in interaction craft.

The signature moment (always, on Seenry's own initiative)

Every new page or redesign Seenry builds gets one crafted, creative component that makes the product's behavior or the brand's idea visible (not edits inside an existing app). Do not ask whether to add it; choosing it is part of the design. The signature comes from the idea chosen in step 3, not from a menu. When the page makes one big claim, one strong move is often the claim made visible: show it literally, in the product's own unit and at a size people read, with a pause control for anything that loops longer than 5 seconds. "Many" is never a cloud of tiny chips, domains, logos or dots: show three to five readable instances and the one result they become; if a visitor cannot read it, it is decoration. A large editorial statement with the brand's proof set inline (logos, marks, an icon for the promise, one action button) is available as the statement component when the idea calls for it. Otherwise start from the signature kit and its "Choosing the signature moment" guide: product demo player (a cursor clicks and types inside the real UI), line illustration draw-in, ambient field, scroll story (a sticky visual that changes with each step, scrubbed by scroll), live numbers, logo marquee, compare slider, case-study card with hover preview. Adapt it to the brand (content, color, drawing, timing from .seenry/motion.md) so no two pages look alike, or build an original one when the brief has a better idea. One per page, placed where it explains the most (usually the first screen or the product section), with data-seenry-signature="<name>" on its root element (check.mjs looks for it); it has a complete still state and never blocks reading.

Craft: illustration and ambient visuals

Independent studios (kargul.studio, Linear's illustrations, Stripe's diagrams) separate themselves with a drawn visual language. When the brief calls for it:

One system, not assets. Pick one language and use it everywhere: monoline isometric or orthographic line drawings (1–1.5px strokes in text-2 on the surface color, one accent at most), or precise product diagrams built from real UI parts. Write it as SVG by hand or with code, on the 8px grid, with consistent angles (30° isometric) and stroke weights; never mix flat icons, 3D clay and line art.
Explain, do not decorate. Each drawing shows the thing it sits beside: the service's structure, the product's flow, the data's shape. Abstract blobs, gradients and generic "tech" swirls are slop.
Ambient canvas. A slow field, grid or line animation behind a first screen or a closing section may carry the brand's movement: start from seenry-motion's signal field, boundary trace and image reveal and adapt; keep it under 10% CPU, pause offscreen with IntersectionObserver, stop for reduced motion, and never put text on moving pixels.
Bento and feature cards. Give each card one drawing that shows its feature, all in one hairline isometric language. When a figure of hairline (MIT, npm i @lucasmarkes/hairline, React or plain DOM) fits the feature, use it: exploded or phone for an app in layers, terminal or branches for developer tools, plot or phosphor for data, cabinet, router or patch for infrastructure, vault or padlock for security, elevator for scale, riffle for a stack of items, keyboard, laptop and drawer for what they are. Theme it to the page with its CSS variables (--hairline-plate set to the card's background, --hairline-hi, --hairline-edge, --hairline-mid, --hairline-lo), one figure per card, and keep its read-out outside the drawing. When none fits, draw your own in the same language (with the hairline-create skill if it is installed): rounded solids drawn as a silhouette plus one dim inner crease, never twelve box edges; the stroke is the only highlight (one bright edge says where to look, no fills, glows or shadows); a composed, uneven rest pose that holds up as a still; no words, digits or icons inside the figure; motion on springs that sleeps offscreen and settles at once for reduced motion.
Draw-in, not fly-in. Line illustrations reveal by stroke (stroke-dashoffset) or a mask sweep in 600–900ms when first visible, once.
Portraits and people: real photographs, or one consistent illustrated style for the whole set (same line weight, same crop, same background); never mixed.

Grid and alignment

4px base, 8px layout values, spacing 4 8 12 16 24 32 48 64 96 128. Align ink, not boxes: a title's cap height meets the media's top edge, icons sit on the text keyline; edges are exact or at least 8px apart (alignment, optical). Components have at most 3 sizes and 3 weights (components); pages share one shell (pages).

Guides

Need	Read
Why leading teams choose their colors, radii, weights and density; premium, clean, elegant rules	premium
Concept, directions, type voice, palette origin, signature component, generated-page defaults	art direction
Tokens, grid, spacing, radius, elevation, starter CSS	system
Exploring compositions inside a fixed frame, studio critique	exploration
Constructing and speccing components, anatomies	components
Page shells, section archetypes, page templates	pages
Font choice by product type, scale, tracking, numerals	typography
Palette roles, dark mode, contrast	color
Keylines, ink-level alignment, optical inset, proportion	alignment
Optical centering, size compensation, side bearing, icon nudges	optical
Optical corrections, icons, hit areas, states	craft
Headlines, labels, errors, empty states	writing
Which library to use instead of hand-rolling a component	libraries
Phone browser quirks: viewport units, tap, zoom, safe areas	mobile web
Keyboard, semantics, zoom, reduced motion	accessibility
Choosing material; sourcing and generating it	imagery and `seenry-assets`
Seenry MCP recipes and offline research	research
The design sheet: rationale, research, anatomy, guidelines	sheet
Measured evidence from leading product sites	benchmarks
Libraries and frameworks by design target	stack
AI tells and their fixes	anti-slop
Faithfully reproducing a supplied design	replication

Use seenry-assets for images, icons and fonts, seenry-motion for transitions and interaction, seenry-apps for native mobile, seenry-branding for identity systems, seenry-review for audits, diffs and stress tests.

Tools

Core components, transitions, interaction components, signature components and the statement: copyable, token-driven, accessible, light and dark, each with a gallery.
Research pack: bounded scripted research (credit balance, library guide, one research_design_brief, at most 11 credits) saved with its images and evidence into .seenry/research/.
Bar: without Seenry MCP, captures category leaders' live first screens (desktop, or phone for apps) as the critic's bar and starts a pack to complete by hand.
Screens and motion from video: the review board and motion judge for native apps and anything filmed instead of clicked; check.mjs --screens … --video … runs both.
Pick: renders several first-screen compositions side by side at desktop and phone and has a fresh model choose one blind against the references.
Check: the finishing gate. Runs the review board, blocks on slop, then the blind critic against the reference screens; prints PASS or the fixes to apply.
Image generation: photographs through the Codex CLI's image model from any host; single or batched.
Motion judge: samples eligible controls, records their transitions and a rapid double click, measures animations (properties, durations, easing), layout shift, long frames and reduced motion, blocks hard violations and scores the motion blind.
Photo check: a blind art director scores each image for its slot against the references and writes a better prompt for anything under 8.
Blind critic: a fresh Codex or Claude process scores the page against the references with the premium standard and returns ranked fixes.
Review board: the page at review scale beside the references, plus craft blockers the grid audit cannot see (legibility at scale, eyebrows, numbering, weights, font loading, figure spacing, phone clipping, fixed overlays, motion coverage). Run it every review round.
Product kit and motion floor: the starting quality floor for app screens and interaction.
Page audit: one command for any project (URL or HTML file) at several widths; runs the system and optical audits and prints fixable findings. Needs Playwright.
Optical audit: rasterizes icons to measure ink; reports off-center icon buttons (including asymmetric shapes), icons missing their label's cap-height center, labels not centered in controls, unbalanced icon-side padding and headline side bearing, each with a CSS nudge.
Motion scan: reads the project's CSS, HTML, scripts and Tailwind classes and checks every duration, delay, easing and animated property against the motion tokens, plus transition: all, layout-property transitions, stagger steps and a missing reduced-motion branch, in well under a second and without a browser. check.mjs runs it every round; run it yourself after any motion change.
System audit: counts rendered font sizes, weights, families, radii, shadows and colors; lists off-grid padding, gaps and margins; flags non-concentric corners, wrapped control labels and components over 3 sizes or weights; per component, measures ink-level alignment (cap tops, baselines, drawn glyphs, media edges): near-miss edges, media anchors and optical insets. Run it on every screenshot pass.
Design sheet and anatomy capture: the end-of-task deliverable, styled like seenry.design.
Exploration sheet: renders variant files side by side at real widths for critique.
Grid overlay: development-only columns, gutter and 8px checks.
Palette: OKLCH ramps from one brand color, two-tier tokens for light and dark, and WCAG + APCA measurement of every pair; --check FG BG for one pair.
Starter tokens and DESIGN.md template.
Text collisions, control geometry, visual inventory, token contrast, contrast check.

Report

Lead with a brand guidelines summary the user can read without opening anything, then the paths:

Idea:      <the chosen idea in one sentence, the claim and proof it comes from, and where it shows on the page>
Bar:       <the 3 reference screens and the five lines on why they look premium>
Direction: <intent in one sentence>
Type:      <family and weights by role; why>
Palette:   <name hex role> · … ; temperature and why
Radius:    <family by role>; elevation rule
Imagery:   <what the images are and how they were made>
Owned detail: <the one detail this brand owns>
Rules:     3–5 testable do/don't lines for future work
Critic:    <round-by-round blind scores from check.mjs, e.g. 6 → 7 → 8 → 9> and what moved it
Motion:    <motion judge score, durations and curves used, the signature moment>
Verified:  <widths, interactions, contrast>; not verified: <…>

Write the same guidelines into DESIGN.md under "Brand guidelines". State the critic's final score, never a self-score.