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.

One token system, everywhere

Studio work reads as decided because it uses few values, each on purpose: the studio sites we measured render 5 to 11 font sizes; Seenry pages rendered 15 to 26, with ten spacing values off the grid and a dozen durations, typed one at a time. Before any layout, new page or existing app, the project has one token file and every style uses it:

Type: six to nine steps (display, title, heading, lead, body, small, label), the display step may be fluid with
```
clamp()
```
defined once in the token. Never a size typed in a component.
Space: the 4px scale (4, 8, 12, 16, 24, 32, 48, 64, 96, 128, plus 20, 40, 56, 80 if needed). Component padding, gaps and section spacing come only from it.
Radius: at most three plus full; nested corners concentric.
Motion:
```
--dur-1/2/3
```
(120, 180, 240ms) for state changes,
```
--dur-scene-1/2/3
```
(600, 900, 1200ms) for page choreography,
```
--stagger
```
, and two or three easings. Every transition and animation uses them. Start from the starter tokens for a new site and change the values to the identity; in an existing project use its tokens or theme (Tailwind's scale, CSS variables). When the owner asks for that cleanup and its sizes, spacing, radii or durations are typed values (color variables alone are not a token system), never convert by hand (in testing that took the whole session and the design scored lower): run
```
node scripts/token_convert.mjs <styles folder>
```
to see the scale it builds from the values the app already uses (near sizes merged, spacing on the 4px scale, radii merged to three, durations on the motion tokens), then
```
--apply
```
to write the token block and rewrite the declarations in one pass, and spend the time on design.
```
token_lint.mjs
```
(run by check.mjs and existing_check.mjs;
```
--changed
```
for edits in an existing repo) blocks typed values and Tailwind arbitrary values wherever the project has a scale (every new site, Tailwind, or size and spacing variables) and only advises in a legacy stylesheet without one, where the conversion is the owner's call. For new sites the review board also blocks rendered drift: more than nine font sizes, padding or gaps off the 4px scale, more than seven durations or four radii.

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. Where the app's own values have drifted (several near font sizes, 9px and 14px paddings beside its 8 and 16), the screens you touch snap to its scale, or to the token file
```
token_convert.mjs
```
builds from its values (see One token system); the app gets more consistent, never a second system.
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. Screen-specific rules (a redesigned profile, collections, settings lists, empty states, pricing and other new surfaces) are in surfaces; read the part for the screen you are changing.
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, design sheet or critic loop unless the owner asks for a redesign.
Motion by default, from tokens. Unless the owner says no motion, every state change on the screens you touch gets a transition from the motion tokens: hover and press (
```
--dur-1
```
), toggles, tabs with a sliding indicator and segmented controls (
```
--dur-2
```
), dialogs, sheets, menus, toasts and list changes (
```
--dur-3
```
, enter with
```
--ease-out
```
, leave faster), loading as skeletons that cross-fade to content, and numbers that change in place. Use the app's motion library if it has one (Framer Motion, the component library's transitions), otherwise CSS. Keep a reduced-motion version. Interface motion only: no scroll scenes or page choreography in an app.
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/existing_check.mjs <url of the changed screen> --project .
```
(about a minute): it runs the review board, the token lint on the files you changed, the motion scan and a product-design review of the screen at 100% and on phone. Clear the blockers your change touched or introduced and, in a project with a token scale, every typed value in the files you changed (in a legacy stylesheet without one, use the values it already has; do not convert unless the owner asks), then apply the review's fixes once, most visible first (in testing, its notes were what separated a good team's screen from a Linear-level one: 13px+ meta text at 4.5:1, one control height, a clear save model, no dead space on phone). Run it once more and 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 three identity boards for

pick.mjs

(step 4; the pick is what gives the page its identity, so never skip it); start all imagery in one background batch right after the pick and build while it runs; 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. The one-call research budget above is for quick mode only: in polish and showcase modes do all of step 2, which means pulling at least three category leaders by name (capture the missing ones live with

bar.mjs

), at least three leaders of the composition class (for software: Linear, Brex, Midday, Retool, Intercom, Metronome and the like), and their full pages, not only their heroes. 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, fact or mechanism that only this product can claim (set it as type, not as a giant standalone numeral) (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. The identity's graphic device and type voice are the move, carried from the hero to the footer at real scale. 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. Type comes from what the leaders use, measured from the kept references (see type): usually one refined neo-grotesk, tuned tight; untuned Inter at weight 700 is the tell, not Inter itself.
A decided identity, loud or quiet. Pages that win look decided, in one of two registers chosen from the brand's voice (or from the reference the person shows). Loud: one saturated or deep brand color at full strength in one or two large fields against near-black ink and neutral surfaces, and at least one dark or fully colored section. Quiet premium (calm brands, finance, wellness, software that sells trust; the register of Stripe, Linear and most refined SaaS): warm off-white and ink, no brand-color fields, photography or the product as the only color, a headline of modest size with its second line in the secondary text color, generous white space and soft containers, and pricing, FAQ and footer as calm and carefully made as the hero. Both registers keep readable text at 14px and up. When the person attaches or links a reference, follow its register; the identity step works inside it.
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.
Product visuals are designed screens in real devices. Never draw a phone or laptop from divs, and never put a table or spreadsheet inside one. Design the app screen as its own page to app standards, render it with
```
scripts/mockup_screen.mjs
```
, frame it with device mockups, and compose it with imagery (a tile row of art or photographs with the device across it, a device in a photograph, an angled pair, or UI cards over a painterly field).
Imagery first, even without a generator. Check the image route before building (
```
image.mjs
```
with one test prompt, or seenry-assets
```
generate
```
with an API key). When none works, say so in the report and art-direct one set from The Met instead, never a type-only page:
```
python3 ../seenry-assets/scripts/assets.py art-set --style <family> --subject "<two or three subject words>" --count 8 --out img
```
. Choose one family for the whole page from the brand's voice:
```
impressionist
```
(calm, warm, human: finance, wellness, hospitality, consumer apps),
```
dutch
```
(food, craft, objects, interiors),
```
japanese
```
(precise and graphic: software, tools, travel),
```
drawings
```
(quiet, editorial, architectural),
```
american
```
(open landscape and light),
```
photographs
```
(black-and-white documentary). It trims the museum frames and drops works whose light or color break the set; look at the set together and drop any that still do. Use the paintings the way the quiet kit does: cropped tight as color fields behind real product cards and the device, one per tile, never a framed museum picture, and credit them in the footer. Openverse photographs (
```
assets.py images
```
) and product screens in device mockups fill the rest. The owner preferred this to every generated set.
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.
- Keep one studio-grade reference in the bar. Besides category leaders, save one studio site or a frame from a rebrand film to
```
.seenry/refs/
```
  with its card in
```
kept.md
```
  , so the critic judges the page against studio work, not only against the category's conventions.
- 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 identity sets 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. Then turn the idea into form: write
```
.seenry/identity.md
```
and its board, following Identity first. The idea is the claim; the identity is how it looks, and a claim set in a default layout is still a template.
Explore three identities, then pick blind. The identity boards are the exploration: there is no separate first-screen sketch round. Build three identity boards, quickly (about ten minutes for all three; they are sketches that decide the direction, and the drawn layer and motion score are written briefly on them and built fully in the page), from your three highest-scoring ideas in
```
.seenry/idea.md
```
(
```
.seenry/explore/a.html
```
,
```
b.html
```
,
```
c.html
```
), each following Identity first with its own type voice, color world, device and image treatment, each fitting one 1440×900 screen with its two posters (the hero and the hardest ordinary section). With Seenry MCP, at most one follows the category conventions as the safe control and one is built on the outside-category reference. For an app or software product whose voice is not loud, the page is built from the quiet premium kit (the owner's reference standard; the blind pick favored bolder boards and the owner rated those 7/10), so the three boards differ in the imagery, the app screen's idea and the copy, not in the layout or the register. When the person attaches or links a reference, follow its register and level closely but never its layout one to one: change the hero composition and at least two sections (the kit lists alternatives), and the owner rejected an exact copy even when it looked good. 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, and none may repeat an identity in
```
~/.config/seenry/history.json
```
. Run
```
node scripts/pick.mjs .seenry/explore/a.html .seenry/explore/b.html .seenry/explore/c.html --brief <brief> --refs .seenry/refs/<a>,<b>
```
, copy the winner to
```
.seenry/identity.html
```
, write
```
.seenry/identity.md
```
from it and record it at once with
```
node scripts/history.mjs
```
(so builds running beside this one can avoid it), fold in what the pick says to take from the others, and record the chosen idea in
```
idea.md
```
. The winning board's hero poster becomes the first screen. Studios never ship their first composition; neither does Seenry.
Direction. The winning identity from
```
.seenry/identity.md
```
(rewrite it if the pick changed it): type voice, color world, device, image treatment, voice line and motion behavior, plus the radius family and the composition model. 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, in the background. Start image generation right after the pick and keep building while it runs: write the jobs file from the identity's image treatment and run
```
node scripts/image.mjs --batch jobs.json --variants 3 --brand "<brand>" --background
```
, which returns at once and generates while you build; build the page with the final file names, and check.mjs waits for the images before it reviews (
```
image.mjs --wait
```
waits by hand). A page that waits for its photographs wastes five to twelve minutes. Photography and imagery via seenry-assets, art-directed and passed through
```
photo_check.mjs
```
(see Imagery in the standard). 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.
Edit like a studio, then the craft pass, then check. Before the gate, edit the page the way a studio creative director would, because over-density is now the most common gap between Seenry and studio work. Cut the copy by about a third: every section says one thing once, in one or two short blocks, and a section that does not earn its place goes. The first screen carries one message: the headline, one supporting line and one action, about 45 words at most outside the navigation; facts, captions, badges and secondary links move below it. Captions are one short line (18 words or fewer) and only where they add something the image cannot say. Secondary text gets room: at least 15px at 1440, line height 1.5 or more, and clearly more space between groups than inside them. When in doubt, remove: a calmer page with fewer, larger things reads as studio work, a rich page with everything in it reads as an agency. review_board flags crowded first screens, pages over about 700 words and long captions. Craft pass at full size, then check. Studios judge at 100%, section by section; the critic sees the page at half scale. Before the gate, render each section at 1440 (
```
node scripts/review_board.mjs <url> --out $TMPDIR/seenry-craft
```
writes the full-size first screen; screenshot the rest with Playwright at full size) and fix what only shows up close: optical alignment of type to images and rules, consistent spacing steps between and inside sections, headline line breaks and rag, image crops that cut the subject, and controls that do not share one height and radius. check.mjs also runs the detail critic (
```
scripts/detail_critic.mjs
```
), a fresh model that reviews each section at full 1440 size for craft only and returns fixes tied to an element, in px; apply them with the main critic's fixes, except any that would shrink the identity's scale, mute its color field or remove its device: tidiness never outranks the identity. In polish and showcase modes a page does not pass below 8 on craft; in quick mode the fixes are advice. Then 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 (this is not optional: never skip it because the critic rated the idea well, and never stop to ask whether to do it; in one-shot and headless sessions nobody can answer, so build it): 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.

Identity first: the studio method

Studios do not lay out a page and then pick colors. They design an identity, a few parts used with total conviction, and the website is one application of it. Look at any rebrand in Seenry (Sommerro, Wise, Murray's Cheese, Transavia, Toca Boca): a truth about the brand, one typographic voice set large, one color used as a full field, one graphic device that comes from the truth, one image treatment and a line in the brand's voice. Every touchpoint is built from those parts, so the brand is recognizable with the logo covered. AI pages, Seenry's included until now, do the opposite: a correct layout with a palette applied. Clean and correct is a 6; a designed identity is what makes a 9.

Before any layout, write

.seenry/identity.md

and render it as

.seenry/identity.html

, one screen like the opening frames of a rebrand film:

Truth. The one real thing this brand is or comes from (the building it occupies, a timestamp that proves who said what, the hour the bakery opens), taken from the brief, never invented history.
Visual idea. How the truth becomes form, not copy: a typographic device (letters cut by a rule, a stacked or split wordmark, a ligature), a grid (a ledger, a timetable, a contact sheet), a crop language (always tight, always cut by the frame), a material (paper, film grain, glass, enamel) or a behavior (things arrive in the order they happened). Write it so a designer could apply it to a poster with no website in sight.
Typographic voice and range. The family (usually one) chosen from the measured type of the kept references and the tiers in art direction, tuned the way they tune it; the text face stays quiet. Put three candidates on the board and keep one. Then give it range, the way an editorial designer would: a scale of five or six distinct levels (display, section display, lead or pull quote, body, caption, and an annotation voice such as small caps, tabular figures or the mono for data), plus the moves each level is allowed (a phrase set large in the text face, a hanging caption, an index or margin note, a run-in heading, a measured number with its unit set small). One treatment repeated down the page reads as monotonous even when it is strong.
Register and color world. Start
```
identity.md
```
with
```
Register: quiet premium
```
or
```
Register: loud
```
; the review board holds a quiet page to its rules (the first screen led by a photograph or painting, three or more image moments, no saturated brand bands, no visual shown twice). One hero color plus ink and paper, named for where it comes from. Loud brands use it as a full field; calm, premium brands (Aesop, Apple, a kiln studio) may keep it restrained and let photography, type and composition carry the identity. A recognizable identity does not have to be loud: restraint done with conviction is an identity too.
One graphic device from the visual idea that repeats across the page: a mark, a pattern, a rule system, a frame, a cut, a stamp. Never an asterisk, sparkle, star or flower. Every appearance carries information (a date, a measurement, a label, a route); a device repeated as a divider or filler reads as decoration.
Image concept and treatment. What the imagery says, plus one surprising angle that is not the category's first picture (an unexpected scale, crop, object or staging; a kiln studio shows a single plate edge-on at macro, not another shelf of bowls). Then one look for every image (crop, light, grade, grain and framing), applied in code as well as in the prompt: a CSS or canvas treatment (duotone, grade, grain overlay, cut-out) that every image passes through so the set reads as one shoot. At least one image works with the type or device (overlapping, masked, cut out), not only framed. Studios use generated images too; theirs look directed because of the concept and the treatment, not the generator. Every generated image carries it in its prompt. Golden-hour warmth and moody mist are the generator's defaults and judges now see them on every AI page; choose the light from the brand's truth instead (flat overcast, hard noon sun, on-camera flash, clean studio seamless, night under sodium light, an archival scan) and say why.
Voice line. One short line in the brand's voice that could sit alone on a poster.
Motion score. The page is choreographed like a film, not animated component by component. Blind studio judges scored pages with tidy 0.5s fade-ups on every block at 3–5 out of 10 for motion while everything else scored 8.5–9: that is the gap between a good agency and a top studio. Page choreography runs on its own clock, separate from interface motion (hover, tabs, dialogs stay at 140–280ms): entrances and reveals take 600–1400ms with one expo-out curve, and scenes are scrubbed to scroll. Write the score in
```
identity.md
```
under a
```
## Motion
```
heading and build all of it:
- Entrance (done by 1.2s, in order). The subject arrives first and with scale: the photograph or product unmasks (
```
clip-path
```
  inset to 0 over about 1s) while settling from
```
scale(1.06)
```
  to 1; then the headline by line (each line rising 24–40px inside an overflow mask, 80–120ms apart); then the supporting line and the action; the navigation last. The headline is fully readable by 0.8s and nothing that names the product arrives after 1.2s (judges mark down entrances that withhold the message). Never everything at once.
- Two or three held scenes. A section 160–250vh tall with a
```
position: sticky
```
  stage (or GSAP ScrollTrigger
```
pin
```
  +
```
scrub
```
  ) holds while the thing that proves the idea visibly transforms: layers separate, an image changes framing from the whole to the detail, a drawing builds and a band of light or data travels through it, a diagram or number resolves. Map the scene to a 0–1 progress with a reading hold before release (scroll choreography). Filter or opacity shifts alone are not a scene.
- The device travels. The identity's device or drawing draws itself in as each section reaches it (
```
stroke-dashoffset
```
  or a mask on
```
animation-timeline: view()
```
  ), and links the sections it crosses.
- Images arrive, text stays readable. Large images reveal by mask or framing change as they enter; body copy and rows stay at full opacity (no faint text arriving late).
- One idle loop at most, when it shows the product's own behavior. The fastest robust way is the bundled scene (
```
scene.css
```
  +
```
scene.js
```
  , no library): copy both into the project, mark a tall section
```
data-scene
```
  with a
```
data-scene-stage
```
  , and write the choreography in CSS from its
```
--p
```
  progress; its recipes (whole to detail, layers separate, a drawing builds, a row travels, a number resolves) and its
```
data-enter
```
  entrance cover most pages, already with the reduced-motion version. Otherwise build with CSS scroll-driven animations (
```
animation-timeline: view()
```
  /
```
scroll()
```
  with an
```
animation-range
```
  ) and the View Transitions API, or GSAP ScrollTrigger (
```
https://cdn.jsdelivr.net/npm/gsap@3.13.0/dist/gsap.min.js
```
  and
```
.../dist/ScrollTrigger.min.js
```
  , free for all uses); keep a complete reduced-motion version: write the resting CSS as the final state and let animations run from the start state (so a drawing or image is never left hidden), and under
```
prefers-reduced-motion: reduce
```
  drop the pins and the scenes' extra scroll height so each section closes up to its natural height. The review's full-page still is taken in that version, so blank travel or an undrawn layer shows there as empty space and stay under a 10% CPU budget.
```
check.mjs
```
  films the entrance and a scroll and a choreography critic scores it; apply its fixes in the same round.
Drawn layer. An illustration system drawn from the device, as hand-written SVG in one stroke weight and style (profile drawings, diagrams, marks, maps), used in at least two sections and drawn in on scroll. It is where a page gets its bespoke feel; see Craft: illustration.

The board shows the wordmark, the type scale with all its levels in use (one short passage that sets display, lead, body, caption and annotation together), the color world in its real proportions, the device, one treated image, one drawing from the drawn layer, the motion score as a short storyboard, and two posters made only from these parts: the hero, and the page's hardest ordinary section (pricing, FAQ, security or the team) designed in the same system, because blind judges found every page held its idea in the hero and fell back to stock bands below it. If the poster could belong to a competitor, the identity is not done. Study at least two identity presentations in Seenry first (

search_designs {family: "branding"}

; the rebrand films show one system across signage, print, packaging and web: download the video and pull frames with

python3 ../seenry-motion/scripts/video_frames.py

) and one studio site (

list_sites {q: "studio"}

), for how few parts a strong identity uses. Build your own; never take another brand's mark, face or device. Do not repeat yourself either. Run

node scripts/history.mjs --list

first: it prints the display face, hero color and device of the last identities built on this machine. Fit comes first: choose the identity that fits this brand best, then make sure it is not a copy of a recent one, never the same hue family and kind of device together; a face may repeat when it fits (two finance apps can share a fine grotesk), so when it is close, change the color or the device, never downgrade the type. Two pages from Seenry should not look like siblings, but variety never outranks fit. The examples in this file and in references are there to explain a principle, never to be reproduced.

Then the page is one application of the identity:

Ordinary components are designed, not defaulted. Judges who scored hero and sections 9 marked the page down for the parts every site has: product and pricing cards, forms, tables, the footer. Design each in the identity: its own composition from the device and grid (a price set like the brand's label, a form laid out like its ticket or order slip), field labels, table cells, timetables and metadata at 15px+ in full-contrast ink (every judge marked down "tiny utility text"), one control height and radius family, visible hover, focus and error states, and a footer that is a closing poster in the system, not four link columns. If a component could drop into any SaaS template unchanged, redesign it.
Phone keeps the proposition and the way around. The first phone screen shows the subject cropped to what identifies it (the label, the face, the building), the headline and the action; the navigation stays reachable as a menu button.
Borrow a structure, not a look. Choose one composition model from a studio site or category leader you inspected and write its structure in
```
.seenry/idea.md
```
from its full page, not its hero: the grid (columns, gutters, margins), the type scale (display, section and body sizes and their ratios), how sections alternate in scale and density, and how it crops images. Build on those measurements. Taking a reference's structure and filling it with this identity is how designers learn; copying its content, imagery or device is not.
The subject leads. When the brand has a real place, object or product, the first screen shows it large, full-bleed or nearly, with the type set on or beside it; color fields and type support the subject rather than replace it. Type-only or color-field heroes are for brands with nothing to show.
The board's poster is the first screen. Build the hero by scaling the poster from
```
identity.html
```
up to the full screen: the same type at the same confidence, the color field, the image crop and the device, with the navigation and one action added. In testing, the boards were studio-grade and the pages lost them by falling back to a web hero; the critic now sees the board and scores a page weaker than its own board as identity 6. One statement, one visual: the display type and one image, object or product moment at full confidence: the visual full-bleed or owning most of the screen, or the type itself as the image. Supporting copy is one line and the action is one button. Forms, fact rows, captions and secondary proof go below the first screen (a booking or search field stays only when it is the product, as on a travel site).
Avoid Seenry's own defaults. These have become recognizable as generated: a text column on the left with a photograph filling the right half; a giant numeral as the hero device (a count, a time, a date) unless the number is the brand's truth; a centered headline over a boxed product card; the same type everywhere with no tuning (default tracking, bold headlines). Use one only when the identity makes the case, and say why in
```
DESIGN.md
```
.
The system runs to the footer. Pricing, FAQ, security, testimonials and the closing band use the identity's type voice, field color and device as fully as the hero (a pricing table set in the device's grid, an FAQ indexed the brand's way, a closing band that is the board's second poster). A page whose second half could belong to any site is unfinished.
Typographic range in the middle. Every section below the first screen uses at least two levels of the scale in one composition, and neighbouring sections lead with different moves: a pull quote set large in the text face, then a section led by a dense captioned grid, then one led by a single measured number with its annotation, then an editorial two-column passage with a margin note. Change scale sharply inside a section (a 64px line beside 15px captions) instead of stepping everything one size down. Keep the display face for the statements it was chosen for; let the text face, weight, size and the annotation voice carry the variety. Italic accent words and eyebrows stay out; range comes from scale, rhythm and placement.
Compose sections as posters in the same system. Each section is one confident composition built from the identity's parts (the display type set as image, the color field, the device, a treated image cropped hard), the way a rebrand's applications are, not a heading, a paragraph and a module. Web conventions stay only where they are controls: navigation, buttons, forms, product cards and pricing. A section that could sit on any site with the colors changed is unfinished.

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 by reflex: 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.
The exception is a label or marker system that is the identity's own device, the way a studio uses one: one consistent marker or index that comes from this brand's idea on every section, in sentence case, set with the same care as the headlines. Mark its elements
```
data-seenry-device="<name>"
```
; review_board then treats it as a system and flags it when it appears fewer than three times. Uppercase letter-spaced labels stay out.
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.

The details live in the standard; read it before building, and apply all of it. In short:

Color. Neutral roles (canvas, surface, rule, three text levels) in one temperature; one action color; the identity's hero color at full strength in one or two fields, never pale tints as section grounds. Build it in OKLCH with
```
scripts/palette.py
```
.
Type. The identity's display voice at poster scale, a quiet text face; 2–3 weights, nothing readable under 15px at 1440 (paragraphs 16, short labels 14).
Radius and elevation. One radius family from the brand; control radius at most 25% of its height or a full pill; concentric nesting; separate by space and tone, shadows only on overlays.
Scale. Use the whole 1440 canvas; controls 44–48px; the primary action visible in the first screen.
Proof at real scale. Product UI and diagrams render at real size, never shrunken; proof text at least 15px.
Composition. Every section one large thing at real scale, each composed differently, five to seven sections, 120–160px apart; one focal moment per demo; replace what you remove with stronger material.
Imagery. Art-directed with the identity's treatment, best of three, nothing under 7 ships; software shows the product on a stage; people photography at most once.
Copy. Plain, specific, short, in the owner's voice.
Motion. Purposeful, 120–240ms for UI, springs for movement, interruptible, reduced-motion respected; the identity's motion behavior at the signature moment.
Phone. The first phone screen shows the hero visual (product, photograph or display type as the image) with the headline and one action; announcement bars and secondary buttons go below it (review_board blocks a phone hero with no visual). Recompose, do not squeeze; type never crosses a face; nothing clips.

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.

An idle loop may show the product doing its one job, step by step in the order it really happens, at most one per page, with a 4–6s period, paused on hover and off for reduced motion. Design it from this product's own behavior; never reuse a loop seen on another page or in a reference.

Craft: illustration and ambient visuals

Independent studios separate themselves with a drawn visual language, and every new site gets one (the identity's drawn layer), built from its device:

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.

seenry

NPX Install

Tags

SKILL.md Content