@nerdev/skillset 0.2.1

package/skills/ui/house-style/SKILL.md

@@ -0,0 +1,366 @@
+---
+name: house-style
+description: "How I want this codebase built: route-based file layout, UI that looks like Apple or Google shipped it (no AI purple slop), micro-animations that move only what changed, and docs that I write and you audit. Load before writing code, designing a screen, or touching documentation."
+---
+
+# House style
+
+This skill is how I like things done. It is my voice, not an upstream's. If a
+synced skill says one thing and this says another, this wins.
+
+> **UI/Design skill family:** This skill is the *law* (philosophy/aesthetics). The process skills that implement it:
+> - [`ui`](../ui/SKILL.md): whole UI job (pick direction, design system, build screen, redesign, verify)
+> - [`impeccable`](../impeccable/SKILL.md): commands/detectors for audit, polish, animate, etc.
+> - [`motion`](../motion/SKILL.md): whole motion job (name, decide, build, review, audit)
+> - [`pick-ui-library`](../pick-ui-library/SKILL.md): curated library picks for UI primitives
+> - [`imagegen`](../imagegen/SKILL.md): premium design image generation (references only)
+> - [`prototype`](../prototype/SKILL.md): build divergent UI variants behind a picker
+>
+> Load `house-style` + the relevant process skill(s) for UI/design/frontend work.
+
+Three rules cover most of it:
+
+1. Files follow the route, not the framework.
+2. The screen looks bought, not generated.
+3. The docs are mine to write, yours to audit.
+
+## 1. Files follow the route
+
+One route, one file. Every function that serves `/me` lives in `me.ts`,
+whether it GETs, PUTs, DELETEs or POSTs. Edge cases included: input shapes,
+error handling, the auth checks that route needs, and whatever stats the
+route must show.
+
+Example. A profile endpoint that shows my stats, the way LeetCode shows
+stats for a user, lives in `me.ts`:
+
+- `me.ts` holds every HTTP handler for `/me`: getting my info, updating it,
+  deleting sessions, posting achievements.
+- If `/me` shows stats, the code that loads, formats and returns those stats
+  lives here too. It can call shared helpers, but the route owns the flow.
+- Shared code is only code two or more routes genuinely use. When in doubt,
+  keep it in the route file. Splitting early turns files into treasure hunts.
+
+The exact split changes with the use case. A dashboard endpoint might own
+several aggregate functions. A tiny health check owns one. The rule stays:
+the route names the file, the file owns the route.
+
+## 2. The screen looks bought, not generated
+
+I do not want the default AI look. The purple gradient slop with the glowing
+buttons, oversized rounded cards, the same five icons everywhere. It makes
+every product look the same.
+
+When you build UI, ask one question first: if Apple or Google shipped this
+screen, would it look out of place? Their shared vocabulary is the target:
+
+- One clear action per screen. A CTA that quietly says what happens next.
+- Simple buttons. Flat or barely rounded, solid contrast, no glow, no
+  gradient.
+- Color in small doses. One accent, used only for things that matter.
+  Restraint is the accent.
+- Whitespace does the separating, not borders and shadows.
+- Real type hierarchy: a headline, a sentence, a hint. Not five sizes of
+  bold.
+- Small details done right beat big decorations. Alignment, spacing, hover
+  states, error states.
+- Clean typography and a clean design system. Consistent type scale, one
+  font family, consistent spacing tokens.
+- **Tailwind, strictly.** Component-based Tailwind CSS. Every visual
+  decision is a Tailwind utility or a small composable component. Raw CSS
+  only when Tailwind cannot do what the design needs, and only with a
+  reason.
+- **Feedback matches the action.** Manipulation (press, drag) gets a
+  visual state: pressed, hovered, active. Completed work (saved, sent)
+  gets a quiet status: a checkmark, a toast. Destructive work gets
+  confirmation. Nothing else moves.
+
+Eye-catching does not mean loud. The screens that stop people are the calm
+ones with one surprising detail: a perfect number, a sharp shape, one bold
+move in the layout. If any UI skill (impeccable, ui, whichever is
+loaded) suggests purple, gradients, heavy rounding or decoration, say no
+and go calmer.
+
+### Micro-animations: motion is a detail, not a decoration
+
+Motion follows the same rule as color: restraint. When nothing moves
+except what needs to, the one movement that matters is obvious.
+
+- **Move what changed, nothing else.** The clicked button, the reordered
+  list item, the flipped state. If the motion does not answer "what
+  happened?", cut it. No bounces, no confetti, no idle pulses. Nothing
+  animates on a loop: a pulse that never stops is a design that does not
+  know what to say.
+- **One motion per event.** Two springs competing at once read as glitch.
+  Everything else changes instantly.
+- **Spring curves, not keywords.** `ease-in-out` is the elevator; it does
+  not belong in a good UI. Arriving things default to an `ease-out`
+  spring (`cubic-bezier(0.16, 1, 0.3, 1)`), leaving things go sharper.
+  Raw CSS is allowed here when Tailwind's curves cannot do the feel: in
+  motion, the curve is the design.
+- **200ms in, 150ms out.** Micro means micro. A motion that needs more
+  than 300ms is a scene change with a storyboard, and it needs a reason.
+- **Matched to the element.** Small element, small motion. A checkbox
+  does not slide; a card does.
+- **State lands first.** Inputs respond the frame they are pressed.
+  Motion is polish on top, and interruptible: the next click cancels the
+  last spring. Nobody waits on a spring.
+- **Exits exist.** Whatever appears animated leaves animated. A one-frame
+  vanish is a flicker that cheapens the whole screen.
+- **Respect reduced motion.** `prefers-reduced-motion: reduce` means
+  instant state changes. No springs, no entrance sequences, no parallax.
+- **No effects that announce themselves.** No scroll-jacked pages, no
+  parallax, no staggered entrances on every load. They are purple slop
+  that moves.
+
+**Where the good stuff lives.** When a motion needs to feel right, study
+these first, then tune:
+
+- [Apple HIG Motion](https://developer.apple.com/design/human-interface-guidelines/motion):
+  the spec for how motion should feel: springy, brief, cancelable.
+- [Material 3 easing and duration](https://m3.material.io/styles/motion/easing-and-duration):
+  the spec for curves and timings, including the rule that exits beat
+  entrances.
+- [linear.app](https://linear.app): calm, precise, no wasted movement.
+  The default answer to "what should motion feel like".
+- [stripe.com](https://stripe.com): transitions where the content leads
+  and the effects follow.
+- [raycast.com](https://raycast.com): near-zero motion for a tool used
+  hundreds of times a day.
+- [apple.com](https://www.apple.com) product pages: scroll reveals done
+  with restraint.
+- [60fps.design](https://60fps.design): a gallery of shipped app motion,
+  real products instead of prototypes.
+- [emilkowal.ski](https://emilkowal.ski): the when and why of animating,
+  from the design engineer behind Linear-grade UI.
+- [Awwwards microinteractions](https://www.awwwards.com/websites/microinteractions/):
+  award sites that mostly show you where the line to "too much" is.
+
+The pattern every one of them shares: fast, physical, quiet,
+purposeful.
+
+### Gradients: restraint is the rule
+
+Gradients are not banned. Bad gradients are banned. The difference is
+purpose and subtlety.
+
+**What to ban:**
+- Purple or blue glow gradients on backgrounds. The AI signature.
+- Gradient text (`background-clip: text` with a gradient fill). Always
+  looks cheap.
+- Radial gradient halos behind heroes or sections. Decorative noise.
+- Repeating gradient stripes as surface decoration. Not a texture, just
+  noise.
+- Gradient buttons with saturated color shifts. Buttons are flat or
+  solid.
+- Any gradient where you can see the color stops. If the transition is
+  visible, it is too much.
+
+**What to allow:**
+- Subtle tonal shifts on backgrounds. Two near-identical shades of the
+  same gray, blending imperceptibly. Stripe does this. The eye reads it
+  as depth, not as a gradient.
+- Shimmer loading states. A linear-gradient animating across a skeleton
+  is functional, not decorative.
+- Fade masks on scroll containers. A gradient from opaque to transparent
+  at the edge of a scrollable area tells the user there is more content.
+  That is communication.
+- Duotone or tonal overlays on images. Two colors, high contrast, used
+  to unify photography with the palette. Not a rainbow.
+- Background gradients that are solid colors with a slight warm/cool
+  shift. Not chromatic. Think "this white is slightly warmer on the left"
+  instead of "this goes from purple to blue."
+
+**The test:** cover the gradient with your thumb. If the design falls
+apart without it, the gradient is doing too much. If nothing changes,
+the gradient is decoration, and decoration that does nothing is noise.
+
+**Where gradients earn their place:**
+- Surfaces that need subtle depth (a card that recedes slightly toward
+  the bottom)
+- Loading and transition states (shimmer, crossfade)
+- Scroll indicators (fade at the edge of a container)
+- Image treatment (tonal overlay to match palette)
+
+**Where they never belong:**
+- Buttons
+- Text
+- Headers or nav bars
+- Anywhere that a solid color does the job
+
+Study how Stripe uses gradients: barely perceptible, always functional,
+never the first thing you see. The gradient exists to make the solid
+color feel less flat. That is the whole job.
+
+### The Gumroad Effect: personality over polish
+
+Gumroad's UI breaks every "SaaS design" rule on purpose. Study it when
+a screen needs identity, not just correctness.
+
+**What they do differently:**
+
+- **Custom type, not system fonts.** ABC Favorit, not Inter. The font
+  IS the brand. Most SaaS sites are interchangeable because they all
+  use the same 3 fonts. Gumroad isn't.
+- **Buttons with physical weight.** Each button has 3 stacked layers
+  (yellow offset, red offset, black base) that animate on hover with
+  translate and hard shadow. Feels like pressing a real button. Compare
+  to flat rectangles everywhere else.
+- **Bold, limited palette.** Black, white, pink (#FF90E8), yellow,
+  orange, red. No gradients, no glass morphism. The pink is the
+  signature. Restraint in palette, boldness in application.
+- **Type as the visual element.** "$2,193,086" in 12rem font. "Go from
+  0 to $1" in 8xl. Typography does the heavy lifting, not illustrations
+  or stock photos.
+- **Asymmetric bento cards.** Feature cards aren't uniform grids.
+  Different sizes, images overflowing boundaries, text positioned
+  absolutely. Feels organic, not like a Canva template.
+- **Micro-interactions that mean something.** Hover states use
+  `hover:-translate-x-2 hover:-translate-y-2 hover:shadow-[4px_4px_0_0_#000]`.
+  Every interactive element moves slightly and gains a hard shadow. The
+  marquee of category tags scrolls continuously. Parallax coins in the
+  hero. Nothing is idle decoration.
+- **Social proof that feels real.** Real names, real photos, real quotes
+  with real numbers ("$10k+ per month", "6-figure salary"). Not
+  "Trusted by 10,000+ companies."
+- **Open source as trust signal.** GitHub link (9.6K stars) in the hero
+  nav. Says "we have nothing to hide."
+
+**The core principle:** Gumroad's UI looks like what would happen if a
+designer who actually sells stuff on the internet designed the site.
+It's not trying to look like Stripe or Vercel. It's trying to look like
+Gumroad, slightly rough, very human, unmistakably itself.
+
+Most SaaS sites are interchangeable. Gumroad isn't. It has an identity.
+That's why it's good. When building UI, ask: would someone know this is
+ours without seeing the logo? If not, it needs more personality, not
+more polish.
+
+**Apply this by:**
+- Picking one distinctive font and committing to it
+- Making hover states tactile, not just color changes
+- Using type at scale as the primary visual element
+- Letting cards and layouts be asymmetric, not grid-perfect
+- Showing real numbers and real names, not vague claims
+- Choosing a signature color and using it everywhere
+
+## Modular Route-Based File Layout (Backend Services)
+
+### Principle
+One route → one file. Shared code only when ≥2 routes use it. Keep it in the route file until proven shared.
+
+### Structure for Bun HTTP APIs (`apps/be/`)
+```
+src/
+├── index.ts           # Server entry, route dispatch
+├── config.ts          # Env, secrets, constants
+├── schemas.ts         # Zod input validation per route
+├── auth.ts            # Shared auth: hash, JWT, getCurrentUser
+├── utils.ts           # Response helpers, CORS
+└── routes/
+    ├── auth.ts        # POST /auth/signup, /auth/signin, GET /auth/me
+    ├── rooms.ts       # POST /rooms, GET /rooms, GET /rooms/:id
+    └── health.ts      # GET /health
+```
+
+### Structure for WebSocket Gateway (`apps/ws-gateway/`)
+```
+src/
+├── index.ts           # Server entry, WS connection handler
+├── utils.ts           # Shared state (clients, rooms), broadcast, helpers
+└── handlers/
+    ├── auth.ts        # AUTH → AUTH_OK
+    ├── rooms.ts       # CREATE_ROOM, JOIN_ROOM
+    ├── players.ts     # PLAYER_READY, START_GAME, LEAVE_ROOM
+    ├── game.ts        # GAME_ACTION, PING
+    └── dispatcher.ts  # Message routing, connection lifecycle
+```
+
+### Rules
+- **Route file owns the flow**: input validation, auth checks, DB calls, response
+- **Shared code lives in `utils/` or root**: only when genuinely used by ≥2 routes
+- **No premature abstraction**: duplicate until it hurts, then extract
+- **Types from `protocol` package**: never redefine message types locally
+- **Entry point imports routes, routes import shared**: no circular deps
+
+This pattern works for both REST (Bun) and WebSocket handlers.
+
+> **For Turborepo + Bun projects:** Full monorepo structure, package patterns, CI/CD, and deployment conventions are in [`nerdev-monorepo`](../nerdev-monorepo/SKILL.md). This skill covers the aesthetic/philosophy layer; that one covers the structural/operational layer.
+
+## 3. Docs are mine, yours is the audit
+
+AI-written docs are slop. They are vague, they hedge, they list features
+with no outcome stated. I write the docs. You make sure I actually do it,
+then you check my work.
+
+### Two layers, one page
+
+Every user-facing feature page ships two short versions, both on the same
+page so a reader can switch:
+
+- The plain version first. What this does, in outcomes. No jargon, no
+  internals. "See your solving streak and the topics you are weakest in
+  this month."
+- The technical version underneath, behind tabs or a details block, for the
+  person who will maintain it. Real names, real shapes, caching rules,
+  error paths.
+
+For the switch, markdown offers a few options: `<details>` blocks,
+`::: code-tabs` / `::: tabs` directives (GitBook, VitePress), or MDX `Tabs`.
+Pick what the platform renders. When in doubt, `<details>` works on GitHub
+and most other places.
+
+### The rule that never bends
+
+I write these docs. Not you. When a feature is done:
+
+1. You tell me the docs are needed and ask the questions that make writing
+   them easy: what outcome does this give someone? what annoyed you about
+   how it worked before? what should the maintainer know first?
+2. You wait. No drafting "just to help". If I try to shrug the writing off
+   to you, push back gently and wait.
+3. Then you audit what I wrote. Check: outcome first, no vague words, real
+   names and commands, nothing claimed that is not true at this commit.
+   Where it falls short, tell me exactly what to fix and why.
+
+Docs are how I keep ownership of the product. If I did not write it, I do
+not understand it, and that is the one outcome worse than messy docs.
+
+## 4. How to talk to me
+
+I know English well. Still, write so a 5th grader gets it. Plain words,
+short sentences, no padding. Long and fancy does not mean clear.
+
+- **Short and sweet.** If a sentence works without words, cut the words.
+  Clarity is brevity, not a longer explanation.
+- **No em dashes. Anywhere. Never.** Not in files, diffs, docs, comments,
+  or chat. Use commas or periods. One em dash means the deliverable fails
+  review.
+- **STE-clean on owned skills.** Owned skill files pass `npm run lint:ste`.
+  The bar is 2.5 violations per 100 words. Bullet lists and quoted speech
+  do not count.
+- **Small paragraphs.** Two or three lines beats a wall of text.
+- **List is the default.** Features, files, packages, steps: one per line,
+  `name: what it does`.
+
+  ```
+  me.ts: all API work for /me, stats included.
+  auth.ts: login, tokens, sessions.
+  ```
+
+- **Abstract, not imported.** No import trees, no function signatures. Say
+  what a thing does and how it fits. If the function name adds nothing,
+  leave it out.
+- **Outcomes over details.** Say what someone gets or what breaks. Not how
+  many lines moved.
+
+## Working with the agent
+
+Ask like a friend, not a lawyer. If something I said does not land, say
+"wait, I think I missed something" and re-say it in plainer words. Ask the
+questions that matter before building, one round at a time, and stop only
+when we both actually agree. Do not build on guesses.
+
+Build in the smallest step that is real: get the data shape right first,
+remove what is dead, then add. If a sentence of a plan would survive
+unchanged in another project, it does not describe this one. Cut it.

package/skills/ui/imagegen/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: imagegen
+description: Generates premium design images with image models: web section references, mobile app screens, brand kits, and image-first website builds. Use when the user wants design references, landing page images, app screen concepts, brand identity decks, or a website built from generated images. Replaces imagegen-frontend-web, imagegen-frontend-mobile, brandkit, and image-to-code-skill as one owned skill. Generates images only, except the image-to-code flow which implements what it generated. house-style is the law for taste. This file is the craft.
+---
+
+# Imagegen
+
+> **Skill family:** `house-style` = law. [`ui`](../ui/SKILL.md) = full UI process. [`impeccable`](../impeccable/SKILL.md) = commands. [`motion`](../motion/SKILL.md) = motion job. [`pick-ui-library`](../pick-ui-library/SKILL.md) = library picks. [`prototype`](../prototype/SKILL.md) = divergence exploration. This skill = premium design *image references* (web, mobile, brand, image-to-code). Load `house-style` + this skill for design references; the generated images feed into `ui`/`prototype`/`image-to-code` for implementation.
+
+One job, four modes. Pick the mode from the ask: web references, mobile
+screens, brand kit, image to code. Details in references/. house-style
+is the law for taste; this file is the craft of image generation.
+
+## The rules that never bend
+
+- One image per section. Never collapse a flow into one collage, never
+  crop a section out of a bigger image: generate it fresh.
+- Readable text. If the text feels small, the design is not finished.
+- One controlled palette per project. Accent logic holds across every
+  image.
+- One design bible before any multi-image set: palette, type mood,
+  spacing, radius, icon style, texture, navigation.
+- No purple-blue AI gradients, no generic startup looks, no rainbow.
+- No fake names, no filler copy, no meaningless marquees.
+- Images are references a coder can recreate, not mood art.
+- Mode decides framing: web images horizontal, mobile screens inside
+  phone mockups, brand work on boards.
+
+## Mode selection
+
+- Landing page, marketing site, product page: web references
+  (references/web.md).
+- App concept, onboarding, app screens: mobile (references/mobile.md).
+- Logo system, identity deck, brand board: brand kit
+  (references/brandkit.md).
+- Build a site from generated design: image to code
+  (references/image-to-code.md).
+
+## After every set
+
+Run the mode's checklist: count, continuity, palette, readability,
+framing, anti-slop. Fix what fails before delivering.
+
+## Origin
+
+Merged from four skills that were one job in four voices:
+imagegen-frontend-web, imagegen-frontend-mobile, brandkit, and
+image-to-code-skill. Their folders do not come back on sync. Their best
+content lives in the references.

package/skills/ui/imagegen/references/brandkit.md

@@ -0,0 +1,48 @@
+# Brand kit
+
+## The board
+
+Default: one overview image, 3x3 layout, 4:3 or 16:10, clean gutters,
+minimal text. Every board is a visual argument: what the brand
+represents, the metaphor, how the logo expresses it, how it scales, and
+why it is ownable.
+
+## The 3x3 panel system
+
+1. Logo cover: large mark, strong negative space.
+2. Logo construction: grid and geometry, why the mark exists.
+3. Digital application: browser, app header, terminal, app icon.
+4. Brand essence: one short tagline, large type.
+5. Color system: swatches and palette cards.
+6. Typography: large specimen, primary and secondary.
+7. Physical application: card, badge, packaging.
+8. Image direction: cinematic, product crop, material texture.
+9. System detail: UI chips, icon row, pattern.
+
+## Brand strategy first
+
+Infer: category, audience, function, emotional promise, trust level,
+visual world, metaphor. Symbols are never random. Dev tool: cursor,
+frame, bolt. AI: spark, orbit, signal. Security: shield, eye, seal.
+Luxury: monogram, emboss. Productivity: path, check, calendar.
+
+## Logo concept (one method, max two)
+
+Monogram with meaning, product action, metaphor fusion, negative space,
+construction geometry. The mark must be simple, memorable, scalable,
+ownable.
+
+## Visual modes
+
+Dark developer, dark operator, dark nature, dark security, light
+editorial, luxury, voice, cultural. Match the mode to the brand.
+
+## Text rules
+
+Very little text: brand name, one tagline, one URL, 2-5 labels. No
+paragraphs, no lorem, no menus.
+
+## Anti-generic
+
+No floating icons, generic gradients, fake tiny UI, messy collages,
+cheap neon, template boards.

package/skills/ui/imagegen/references/image-to-code.md

@@ -0,0 +1,56 @@
+# Image to code
+
+## The workflow
+
+1. Infer the section count.
+2. Generate the section reference images first.
+3. Add detail or extraction images where needed.
+4. Regenerate unclear sections as fresh standalone images.
+5. Deeply inspect every image.
+6. Extract: text, type, spacing, colors, layout, buttons, component
+   logic.
+7. Implement to match the generated design as closely as possible.
+8. Invent missing details only when the images leave it ambiguous.
+
+## Anti-under-generation
+
+Never reduce the image count for convenience. One clear image per
+section beats one compressed board. An extra detail image beats
+guessing.
+
+## The do-not-crop rule
+
+Never crop a section out of a larger image: it destroys spacing, type
+scale, and proportions. Generate fresh, keeping the design language.
+
+## Deep analysis
+
+Treat the images as the specification: exact visible text, type scale
+relationships, spacing logic, button shapes, palette, shadow mood.
+Faithful logic, not pixel OCR.
+
+## Design-to-code discipline
+
+Copy-oriented: visually faithful, not inspired by. No drift into
+default templates, generic rows, compressed spacing, flattened type, or
+reintroduced nested boxes.
+
+## Missing detail order
+
+1. Preserve the visible design language.
+2. Preserve the layout logic.
+3. Preserve the component family.
+4. Preserve the mood.
+5. Generate an extra image.
+6. Regenerate fresh.
+7. Then pick the most implementation-friendly faithful version.
+
+## Hero readability
+
+One focal point, headline 1-3 lines, no pills or fake stats, clean on
+a small laptop.
+
+## Section packs
+
+4, 8, or 12: hero, trust bar, features, showcase, benefits,
+testimonials, pricing, CTA.

package/skills/ui/imagegen/references/mobile.md

@@ -0,0 +1,58 @@
+# Mobile screens
+
+## Platform mode first
+
+Pick one: iOS-native, Android-native, or cross-platform neutral. Never
+mix patterns from different platforms.
+
+## The count rule
+
+One screen per image. 1 screen, 1 image. 5 screens, 5 images. Flows:
+onboarding, auth with all states, meaningful app sets. Better several
+clean screens than one compressed board.
+
+## No cropping
+
+Never crop a screen out of an earlier image. Generate fresh with the
+same design language.
+
+## Framing
+
+Default: UI inside a phone mockup with a visible frame. One device
+style per set, consistent scale, even margins, the phone never touches
+the canvas edge. The mockup supports the screen; the content stays the
+hero.
+
+## First screen
+
+One focal point, headline 1-3 lines, no stats or pills, CTA visible.
+Respect safe areas, status bar, home indicator, and gesture space.
+
+## Navigation
+
+Familiar patterns: tab bar, stack, sheets, segmented controls. Do not
+overload the bottom nav.
+
+## Textured surfaces
+
+Soft film grain, paper texture, frosted feel, tonal fog. Texture
+supports the mood and never competes with the text.
+
+## Iconography
+
+A clean custom-feeling system with consistent stroke logic. No Lucide
+defaults, no mixed weights.
+
+## Category biases
+
+- Fintech: trust, calm numbers, no chart spam.
+- Health: calm, airy.
+- Productivity: clarity and discipline.
+- Social: rhythm and media moments.
+- Commerce: strong product imagery, clean checkout.
+- Wellness: soft materials, soft fades.
+
+## Regenerate when
+
+Text too small, crowded, fake navigation, looks like a website, nested
+cards, muddy palette, sloppy framing, lost consistency.

package/skills/ui/imagegen/references/web.md

@@ -0,0 +1,63 @@
+# Web references
+
+## The count rule
+
+One separate horizontal image per section. Hero: 1. Landing page: 6.
+Full marketing site: 8. Product page or portfolio: 6. Ambiguous:
+default high. Announce the count first, then deliver each one labeled
+"Section X of N".
+
+## Formats
+
+Horizontal: 16:9, 16:10, or 21:9. Hero usually 16:9 or 21:9. Content
+sections 16:10.
+
+## Hero scale (pick one, decisively)
+
+- Giant statement: massive type fills the first viewport.
+- Mid editorial: balanced type and image.
+- Mini minimalist: tiny logo, short statement, thin CTA, mostly
+  negative space. Mini means confidence, not weakness.
+
+## Composition anchors
+
+Pick one per section, at least 3 different anchors across the site,
+never the same twice in a row. Left-text-right-image is the overused AI
+default: allowed only when it earns it. Before the final layout ask:
+"Am I drafting the default out of habit?"
+
+## Background modes
+
+Pick one per section and vary: solid plus asset, texture, full-bleed
+image with tonal overlay, editorial side image, image as the visual,
+flat block with detail crop, tonal gradient, duotone, radial vignette,
+noise gradient. The same mode 3 sections in a row is a reject.
+
+## CTAs
+
+Pick per section from: pill, outline, underlined link with arrow,
+full-width banner, oversized headline with tiny hint. Vary at least
+once. One unmistakable primary action per viewport.
+
+## Palette
+
+One primary, one secondary, one accent used sparingly, plus neutrals.
+Section mood shifts reuse the same palette. Full-bleed images match the
+palette tonally. Gradients allowed only as low-chroma tonal grades.
+
+## Second-read moment
+
+Exactly one per page, deliberate: an oversized numeral, a material
+switch, a side-rail editorial note. It aids recall, it does not show
+off.
+
+## Narrative spine
+
+Pick one and thread it through every section: artifact, journey, tool,
+living system, stage, archive.
+
+## Continuity
+
+The same palette, type family and scale, CTA family, radius language,
+and image treatment across all sections. Variation only in anchor,
+background mode, size, and placement.