@ericrisco/rsc 3.1.3 → 3.3.0

package/skills/design/references/brand-grounding.md

@@ -1,197 +0,0 @@
-# Brand Grounding — Checklist, Question Script & Persistence (visual)
-
-The brand study is the source of truth every design decision is grounded in. This file holds the **completeness checklist** (the visual/design dimensions a brand study must cover before you paint a single pixel), the **question script** (how to interview the user, batched), and the **persistence format** (how to write it into `02-DOCS` and link it from `CLAUDE.md`). The runtime mechanism that invokes this — the hard STOP on an incomplete study — lives in `SKILL.md` under "Brand grounding (read this first)".
-
-This skill **co-owns the brand study with the `marketing` skill**. Marketing owns the *words* dimensions (positioning, audience, value prop, voice & tone, proof, offers, channels, SEO/GEO keywords — see `../../marketing/references/brand-grounding.md`). Design owns the *visual* dimensions below. They write into the **same** `02-DOCS/wiki/brand/` study and the **same** `## Brand & voice` section of root `CLAUDE.md` — never a parallel copy. If marketing already created the study, extend it with the visual articles; do not duplicate the words articles.
-
-## Where the brand study lives
-
-Following the `harness` Karpathy-wiki convention (compiled articles in `wiki/`, immutable raw inputs in `raw/`):
-
-```text
-02-DOCS/
-├── raw/brand/             ← immutable: pasted inputs (screenshots, palettes, competitor lists, mood refs)
-│   ├── inspiration-linear.png
-│   ├── existing-palette.txt
-│   └── …
-└── wiki/brand/            ← compiled brand study, one article per dimension
-    ├── index.md             ← positioning one-liner + links to every dimension article
-    ├── visual-identity.md   ← color (OKLCH), type pairing & scale, logo, radius/shadow/motion personality  [DESIGN]
-    ├── imagery.md           ← photography vs illustration mood, iconography, texture/grain  [DESIGN]
-    ├── layout.md            ← density, composition, dark-mode stance, reference/inspiration sites  [DESIGN]
-    ├── constraints.md       ← accessibility level, performance budget, existing design system/tokens  [DESIGN]
-    ├── audience.md          ← ICP, pains, desires  [MARKETING]
-    ├── value-proposition.md ← value prop, differentiation  [MARKETING]
-    ├── voice.md             ← tone, do/don't word lists, voice samples  [MARKETING]
-    ├── proof.md             ← credibility, metrics, customers  [MARKETING]
-    ├── offers.md            ← offers + primary/secondary CTA  [MARKETING]
-    ├── channels.md          ← active channels  [MARKETING]
-    └── seo.md               ← target keywords  [MARKETING]
-```
-
-Small projects may collapse the visual dimensions into one `visual-identity.md` with each dimension as a `##` heading — but every dimension below must still be present and filled.
-
-## Completeness checklist (visual dimensions)
-
-The visual side of the study is **COMPLETE** only when every dimension below is filled with real, specific content. Any empty, placeholder, or "TBD" dimension = **INCOMPLETE** = hard STOP, interview the user. (The words dimensions are checked by `marketing/references/brand-grounding.md`; design needs the voice/positioning articles present so copy and design agree, but design only *interviews* for the visual gaps.)
-
-- [ ] **V1. Color system** — brand hue(s) and neutrals expressed (or convertible) to OKLCH; a target ramp (50→900); the accent's role; the 60-30-10 intent. Capture any existing hex/brand colors so they can be converted to OKLCH tokens (OKLCH is the source of truth; sRGB hex is an approximation — see `visual-system.md`).
-- [ ] **V2. Typography** — display face + text face (and mono if code is shown), or a single superfamily with weight contrast; the modular scale ratio (e.g. 1.25); any licensed/owned fonts the brand must use. Never three+ families.
-- [ ] **V3. Logo & wordmark** — does one exist? light/dark variants, clear-space, min size, and whether a favicon/app icon is needed. If absent, note it as a gap (`[[NEEDS ASSET]]`) — never invent a logo silently.
-- [ ] **V4. Imagery & illustration mood** — photography vs 3D vs illustration vs abstract; realistic vs stylized; iconography style (line vs filled, corner radius); texture/grain/noise stance. This sets whether the hero shows a product screenshot, a render, or an editorial image.
-- [ ] **V5. Density & personality** — how the surface should *feel*: airy/editorial vs dense/utilitarian; the radius personality (sharp 0–4px vs soft 12px+); shadow personality (flat vs layered elevation); motion personality (still/quiet vs expressive). These become token values.
-- [ ] **V6. Reference / inspiration sites** — 2–5 sites the user loves and *why* (e.g. "Linear for restraint", "Stripe for gradients done right"). These anchor the research-first protocol's archetypes; without them you research blind.
-- [ ] **V7. Layout preferences** — composition leanings (centered hero vs asymmetric/bento vs editorial), max-width feel, any required sections or a sitemap, mobile-first vs desktop-first emphasis.
-- [ ] **V8. Dark-mode stance** — light-only, dark-only, or both with a token-swap; if both, which is the default. (Dark mode via semantic token swap, not per-component overrides — see `visual-system.md`.)
-- [ ] **V9. Accessibility & performance constraints** — target conformance (WCAG 2.2 AA is the floor here; AAA if mandated); Core Web Vitals budget (LCP/INP/CLS); locales/RTL; reduced-motion seriousness; any device/bandwidth constraints.
-- [ ] **V10. Existing design system / tokens** — is there a Tailwind `@theme`, a `tokens.json`, a Figma library, or component kit to extend? Reusing the system beats inventing a parallel one.
-- [ ] **V11. Voice & positioning present (cross-check)** — the marketing-owned `voice.md` and `value-proposition.md` articles exist and are filled, so copy and design agree. If absent, hand off to the `marketing` sibling skill (or interview for them too) — a premium surface with off-voice copy is not premium.
-
-## Question script (ask in batches, never all at once)
-
-Ask **one batch at a time**. Send the batch, wait for the answer, persist what you learned, then send the next batch. Skip questions a located-but-incomplete study already answers — only fill the gaps. Stop interviewing the moment every dimension is complete.
-
-### Batch 1 — references & feel
-
-```text
-1. Show me 2–5 sites or apps whose look you love — and for each, what specifically (the
-   restraint, the type, the color, the motion)? Paste links or screenshots.
-2. In three words, how should this feel? (e.g. calm/editorial, dense/technical,
-   playful/vivid, refined/luxury)
-3. Airy or dense? Should it breathe with whitespace, or pack information tightly?
-4. Light mode, dark mode, or both? If both, which is the default?
-```
-
-### Batch 2 — color & type
-
-```text
-5. Do you have brand colors already? Paste any hex/RGB values, a palette, or a brand guide —
-   I'll convert them to an OKLCH token ramp (I'll save the raw input under 02-DOCS/raw/brand/).
-6. If not: pick a brand hue direction (cool/blue, warm/orange, green, violet, near-neutral)
-   and how saturated it should read (muted vs vivid).
-7. Any required or owned fonts? If not, do you lean geometric-sans, humanist-sans, serif/
-   editorial, or mono-forward (dev tool)?
-8. How loud should the type be — understated, or oversized expressive headlines?
-```
-
-### Batch 3 — assets, imagery & layout
-
-```text
-9. Is there a logo/wordmark? Send light + dark versions if you have them. Need a favicon/app icon?
-10. What imagery direction — product screenshots, photography, 3D renders, illustration, or
-    abstract? Realistic or stylized? Any reference for the icon style?
-11. Radius/shadow/motion personality: sharp & flat, or soft & elevated? Still & quiet, or
-    expressive motion? (I'll bake these into tokens.)
-12. Any must-have sections or a required sitemap? Centered hero or asymmetric/bento?
-```
-
-### Batch 4 — constraints & system
-
-```text
-13. Accessibility target — is WCAG 2.2 AA enough, or is AAA / a specific standard mandated?
-    Any RTL/locale needs?
-14. Performance budget or device constraints I should design within? (slow networks, low-end
-    devices, a hard LCP target?)
-15. Is there an existing design system, Tailwind @theme, tokens.json, or Figma library to
-    extend rather than replace?
-```
-
-If the user can't answer a question, that dimension stays incomplete — note the gap, keep the STOP in place for that dimension, and offer to propose a researched default they can confirm, rather than silently defaulting to your generic prior. **How to actually propose one: `starting-point.md`.** It is the difference between offering something and improvising something: what the project already owns is checked first, the value comes from a reference you opened and measured, and it is written marked `propuesto`. A proposed-and-unconfirmed dimension does **not** count as complete against the checklist above — the STOP stays up until the user confirms it.
-
-## Persistence format
-
-### Visual-identity wiki article template
-
-Each `02-DOCS/wiki/brand/*.md` article follows the harness wiki format. It is an OKF v0.1 article: open it with YAML frontmatter carrying a non-empty `type:` (`brand-study`), then the H1 and body:
-
-```markdown
----
-type: brand-study
-title: Brand — Visual Identity
-description: The visual personality — OKLCH color system, type pairing & scale, and radius/shadow/motion personality.
-tags: [brand, visual-identity, design]
-timestamp: YYYY-MM-DDTHH:MM:SSZ
-topic: brand
-status: stable
----
-
-# Brand — Visual Identity
-
-> Sources: {user interview, YYYY-MM-DD}
-> Raw: [existing-palette](../../raw/brand/existing-palette.txt); [inspiration-linear](../../raw/brand/inspiration-linear.png)
-
-## Overview
-
-One paragraph: the visual personality and the ONE memorable detail.
-
-## Color (OKLCH source of truth)
-
-| Token | OKLCH | Role |
-| --- | --- | --- |
-| brand-500 | oklch(0.62 0.19 256) | primary accent (10% allocation) |
-| bg | oklch(0.99 0 0) | background (light) |
-| fg | oklch(0.21 0.01 256) | foreground |
-
-(Any sRGB hex the user gave is recorded as an approximation, not the source — see `visual-system.md`.)
-
-## Typography
-
-- Display: Geist Semibold · Text: Inter Regular · Mono: Geist Mono (code)
-- Scale ratio: 1.25 (major third), 16px base
-
-## Personality
-
-- Radius: soft (0.875rem cards) · Shadow: layered transparent elevation · Motion: quiet, entry reveals only
-
-## See Also
-
-- [Layout](layout.md)
-- [Constraints](constraints.md)
-```
-
-### Raw inputs
-
-Paste each user-provided input (palette text, competitor list, screenshots saved as files) under `02-DOCS/raw/brand/` with a one-line provenance header on text files:
-
-```markdown
-> Source: user-pasted, YYYY-MM-DD, origin: "current brand guide, page 3 palette"
-
-<the pasted values, unedited>
-```
-
-Binary inputs (screenshots, logo files) go in verbatim and are linked from the article's `> Raw:` line; never compiled or edited.
-
-### CLAUDE.md link
-
-Add (or **extend**, never duplicate) the shared `## Brand & voice` section in the root `CLAUDE.md`. Additive only — never delete existing sections. Create `CLAUDE.md` if absent. If `marketing` already created this section, append the visual links to it rather than writing a second section.
-
-```markdown
-## Brand & voice
-
-Design and marketing/landing copy are grounded in the brand study under
-`02-DOCS/wiki/brand/`. Read it before any user-facing design or copy:
-
-- [Positioning](02-DOCS/wiki/brand/index.md)
-- [Visual identity (color, type, personality)](02-DOCS/wiki/brand/visual-identity.md)
-- [Imagery & illustration](02-DOCS/wiki/brand/imagery.md)
-- [Layout & references](02-DOCS/wiki/brand/layout.md)
-- [Accessibility & performance constraints](02-DOCS/wiki/brand/constraints.md)
-- [Audience](02-DOCS/wiki/brand/audience.md)
-- [Value proposition](02-DOCS/wiki/brand/value-proposition.md)
-- [Voice & tone](02-DOCS/wiki/brand/voice.md)
-
-Raw inputs (palettes, screenshots, voice samples): `02-DOCS/raw/brand/`.
-The `design` skill owns the visual articles; `marketing` owns the words
-articles. Either stops to interview the user if its dimensions are missing.
-```
-
-Also update `02-DOCS/wiki/index.md` (add the new brand articles) and append a one-line entry to `02-DOCS/wiki/log.md` per the harness wiki protocol.
-
-## See Also
-
-- `../SKILL.md` — the runtime grounding mechanism (hard STOP) that uses this checklist.
-- `visual-system.md` — turns the captured color/type/personality into Tailwind v4 `@theme` tokens.
-- `research-method.md` — uses the reference sites (V6) as archetypes for the research loop.
-- `trends-2026.md` — researched defaults to offer when a visual dimension has no user direction.
-- `../../marketing/references/brand-grounding.md` — the co-owned words dimensions (incl. SEO/GEO) of the same study.
-- `../../harness/SKILL.md` — the canonical `02-DOCS` wiki protocol and article templates.

package/skills/design/references/copywriting-frameworks.md

@@ -1,138 +0,0 @@
-# Conversion Copywriting Frameworks
-
-The marketing-copy engine. Copy carries the value prop — the prettiest hero fails if the words are vague. Write benefit-led, specific, and human. The `marketing` skill is the canonical owner of the WORDS (voice, full landing copy, launch, channel adaptation) and grounds them in the same `02-DOCS/wiki/brand/` study; this file is the design-side quick reference that makes on-page copy convert and keeps it in sync with the design. For anything beyond the hero/section copy, hand off to `marketing`.
-
-## The 5s value-prop test
-
-A stranger reads the hero and, within 5 seconds, can answer: **what is it, who is it for, why is it better?** If any answer is missing, the copy fails — rewrite before you touch the layout.
-
-Build the value prop from a value-proposition canvas: map the customer's jobs/pains/gains, then your pain-relievers/gain-creators, then compress the strongest match into a headline.
-
-```text
-VALUE-PROP CANVAS — Driftway (preview-environment CLI)
-Customer jobs ...... ship a branch for review without breaking staging
-Customer pains ..... staging is a shared queue; manual env setup eats an afternoon
-Customer gains ..... reviewers click a link and see the real change
-Pain relievers ..... one CLI command spins an isolated env; auto-teardown
-Gain creators ...... every PR gets a live preview URL automatically
-Headline ........... "Preview every branch — no staging queue"
-Subhead ............ "One command gives every pull request a live URL. For platform teams who are done babysitting staging."
-```
-
-## Frameworks with picker
-
-Pick the framework by traffic temperature and funnel position.
-
-- **PAS (Problem-Agitate-Solution)** — pain-aware cold traffic that already feels the problem.
-- **AIDA (Attention-Interest-Desire-Action)** — broad / top-of-funnel where you must earn attention first.
-- **FAB (Feature-Advantage-Benefit)** — feature sections; translate capability into outcome.
-- **BAB (Before-After-Bridge)** — show the transformation; strong for case studies.
-- **JTBD (Jobs To Be Done)** — frame the product as the tool that gets a specific job done.
-
-```text
-PAS rewrite
-Bad  — "Our platform streamlines environment management."
-Good — "Staging is a queue. Every merge waits behind someone else's broken branch.
-        Driftway gives each PR its own environment — no queue, no waiting."
-```
-
-```text
-AIDA rewrite
-Bad  — "Sign up for our developer tool today."
-Good — "See your branch live in 30 seconds (Attention). It runs as one CLI step in
-        your existing pipeline (Interest). Reviewers click a real URL, not a screenshot
-        (Desire). Start free — no credit card (Action)."
-```
-
-```text
-FAB rewrite
-Bad  — "Includes automatic environment teardown."
-Good — "Environments tear down automatically when the PR merges (Feature → Advantage),
-        so you never pay for idle infra or clean up by hand (Benefit)."
-```
-
-```text
-BAB rewrite
-Bad  — "Improve your review workflow."
-Good — "Before: reviewers guess from a diff (Before). After: they click a live URL and
-        test the real thing (After). Driftway builds that URL on every push (Bridge)."
-```
-
-```text
-JTBD rewrite
-Bad  — "A powerful preview platform for modern teams."
-Good — "When a teammate opens a PR, you want to test the actual change in seconds —
-        Driftway gives that PR a live environment automatically."
-```
-
-## Headline formulas
-
-| Formula | Pattern | Example |
-| --- | --- | --- |
-| Outcome + timeframe | `<Outcome> in <time>` | "Preview every branch in 30 seconds" |
-| X without Y | `<Gain> without <pain>` | "Live previews without a staging queue" |
-| JTBD | `When <trigger>, <product> <gets job done>` | "When you open a PR, get a live URL automatically" |
-| Specificity | Replace adjectives with numbers | "Cut review setup from 20 min to 30 sec" |
-
-The subhead's job: state **who** it's for, **how** it works in one clause, and **proof** if you have it. Specificity beats cleverness — a clear claim outconverts a clever pun every time.
-
-## Benefit-led specificity
-
-Climb the ladder feature → benefit → proof. Stop at the rung the visitor cares about (the benefit), and back it with the proof rung.
-
-```text
-Feature ... "Isolated per-branch environments."
-Benefit ... "Reviewers test the real change, not a screenshot."
-Proof ..... "Northwind cut review setup from 20 min to 30 sec across 40 engineers."
-```
-
-Numbers and receipts outperform adjectives. "Fast" is a claim; "30 seconds" is evidence.
-
-## Microcopy & CTA copy
-
-Buttons use value verbs; forms label clearly; states stay human.
-
-| Context | Bad | Good |
-| --- | --- | --- |
-| Primary CTA | "Submit" | "Start free" |
-| Secondary CTA | "Learn more" | "See a 2-min demo" |
-| Form label | "Email" placeholder only | "Work email" with persistent label |
-| Empty state | "No data" | "No previews yet — push a branch to create one" |
-| Loading | "Loading..." | "Spinning up your environment…" |
-| Error | "Something went wrong" | "Couldn't reach the API. Retry, or check status.acme.example." |
-
-## Voice/tone system
-
-Define a reusable VOICE block once and apply it everywhere. If a brand study exists under `02-DOCS/wiki/brand/voice.md` (owned by `marketing`), consume its profile verbatim; otherwise fill this and persist it back to the brand study:
-
-```text
-VOICE
-Persona ...... a senior engineer who respects your time
-Tone sliders . formal ⟵───●──── casual | serious ●──────── playful | dense ───●───── airy
-Do ........... lead with the outcome; use concrete numbers; short sentences; active voice
-Don't ........ hype words; bait questions; em-dash-stacked run-ons; forced lowercase
-Reading level  8th–10th grade; one idea per sentence
-```
-
-## The ban-list
-
-State once, enforce everywhere. These signal AI-template copy and erode trust:
-
-`revolutionary` · `game-changer` · `cutting-edge` · "In today's landscape" · `unlock` · `seamless` · `elevate` · `supercharge` · bait questions ("Tired of slow deploys?") · "not X, just Y" · forced lowercase as a style · "Excited to share".
-
-The `marketing` skill is the canonical owner of voice and distribution; this ban-list is the on-page enforcement of its rules.
-
-## SEO-aware copy
-
-A structural constraint, not a keyword strategy — defer depth (keyword research, GEO, technical SEO) to the `marketing` sibling skill, which carries SEO/GEO.
-
-- Title 50–60 characters; meta description 120–160.
-- Put the primary keyword in the `<h1>` naturally, not stuffed.
-- Use scannable `<h2>`/`<h3>` subheads that double as answers to likely queries.
-- Front-load the benefit in the first 160 characters so search snippets read well.
-
-## See Also
-
-- `landing-anatomy-and-cro.md` — where each piece of copy lands on the page.
-- `brand-grounding.md` — where the voice/positioning that drives this copy is captured and persisted.
-- `../../marketing/SKILL.md` — canonical owner of voice, full landing copy, launch, channel adaptation, and SEO/GEO + keyword research.

package/skills/design/references/design-systems.md

@@ -1,49 +0,0 @@
-# When the brief is a design system, not an aesthetic
-
-This skill's default is Tailwind v4 + Next.js, and for most briefs that is right. But some
-briefs correspond to a **maintained, official design system**, and there the correct answer is
-to install it. Recreating its CSS by hand produces something that looks like it, fails its
-accessibility work, and drifts on its next release.
-
-The list is deliberately short: only the cases where using the official package is
-**obligatory or strongly expected**, and where the default instinct would be to hand-roll it.
-Free choices (Bootstrap, Material for a non-Google product, Radix Themes, shadcn/ui) are not
-here — they are ordinary picks, and shadcn/ui in particular is already this skill's territory,
-where the rule is simply never to ship it in its default state.
-
-| The brief reads as | Install | Why it is not a choice |
-| --- | --- | --- |
-| A UK public-sector service | `govuk-frontend` | Expected by the Service Standard; deviating is a finding at assessment |
-| A US federal or trust-first public service | `uswds` | Same, under the US Web Design System |
-| A Shopify admin surface or embedded app | `@shopify/polaris` (or Polaris web components) | Required for admin UI to be accepted |
-| IBM-flavoured enterprise or dense analytics | `@carbon/react` + `@carbon/styles` | Mature data-density patterns you will otherwise reinvent badly |
-| An Atlassian / Jira-adjacent product surface | `@atlaskit/*` + `@atlaskit/tokens` | Official DS; token-driven theming |
-| A GitHub-style devtool or community page | `@primer/css`, or `@primer/react-brand` for marketing | Official Primer; the Brand variant is the marketing half |
-| A Microsoft / Fluent-flavoured product | `@fluentui/react-components` | Official Fluent, Microsoft tokens, accessibility already done |
-
-## The three rules that come with them
-
-1. **Do not recreate it.** If the brief names one of these, install the package. Importing its
-   tokens and then overriding ninety percent of them is the same mistake with extra steps.
-2. **One system per project.** No Fluent components inside a Carbon tree, no shadcn/ui
-   dropped into a Material app. Mixing two systems produces a third, worse one.
-3. **Name what is an approximation.** When the brief is an *aesthetic* rather than a system —
-   glassmorphism, bento tiles, brutalism, editorial, aurora gradients, kinetic type — there is
-   no official package, and saying so is part of the work. Apple's Liquid Glass is documented
-   for Apple platforms only: there is no official web implementation, so a web version is a
-   `backdrop-filter` approximation and must be labelled as one, in the code and to the user.
-
-## What still applies
-
-Everything in `../SKILL.md` that is not styling: the brand gate, the accessibility floor,
-the Core Web Vitals budget, the 5-second value-prop test, and the tell registry in
-`../scripts/verify.sh`. An official design system settles which components you use. It does
-not settle whether the page says anything.
-
-## Where to browse for component ideas
-
-When a surface needs an idea rather than a primitive, a gallery of shipped products
-names where to go — Aceternity for marketing effects, 21st.dev for breadth, React Bits for tunable
-animation — and what each is good for. Take the technique and rebuild it in this project's tokens;
-check the brand study for what it refuses first, because a component that contradicts a stated ban
-makes the page look less designed, not more.

package/skills/design/references/inspiration-sources.md

@@ -1,96 +0,0 @@
-# Reference — where to go looking for a bar
-
-> Last verified: **2026-08-24**. Every URL below was requested on that date and answered.
-> Four sites block automated requests (403/429) but are alive in a browser — marked *(bot-blocked)*.
-> A source with no date does not exist. Re-check before quoting one as current.
-
-**Go and look.** Your built-in aesthetic prior is the median of every template ever scraped, so the
-fastest way past it is to open real work and name what it does. This file is where to open.
-
-Two rules that make the browsing worth anything:
-
-- **Come back with a specific page, not a gallery.** `../../design-loop/SKILL.md` needs a bar you can
-  open — one URL, one screenshot. "Something like Awwwards" is not a bar; a named site from it is.
-- **Extract principles, not pixels.** "Headline is 8× the body, one accent at 3% coverage" travels to
-  your project. Cloning a competitor's exact grid is theatre, and `research-method.md` says so.
-
-## A whole page to beat
-
-The default bucket. Use it when the goal is a site or landing and you need something to converge on.
-
-| Source | Go here for |
-|---|---|
-| [Awwwards](https://www.awwwards.com) | The award tier. Ambitious, often over-built — take the craft, leave the load time. |
-| [Recent](https://recent.design) | Formerly **Godly**; `godly.website` now 301s here. Curated modern web, strong signal-to-noise. |
-| [SiteInspire](https://www.siteinspire.com) *(bot-blocked)* | Long-running, filterable by style, type and subject. Calmer taste than Awwwards. |
-| [Land-book](https://land-book.com) *(bot-blocked)* | Landing pages at volume, filterable by industry and style. |
-| [Httpster](https://httpster.net) | Opinionated and current, less polished-agency than the rest. |
-| [Minimal Gallery](https://minimal.gallery) | When the brief is restraint and you need proof it can still sell. |
-| [Curated Design](https://curated.design) | Aggregated across galleries — a fast first sweep. |
-| [Nicely Done](https://nicelydone.club) | Real product sites and app UI rather than portfolios. |
-| [Lapa Ninja](https://lapa.ninja) *(bot-blocked)* | Large landing archive, free, categorised. |
-| [One Page Love](https://onepagelove.com) | Single-page sites specifically — the constraint is the point. |
-
-## SaaS and conversion surfaces
-
-| Source | Go here for |
-|---|---|
-| [SaaS Landing Page](https://saaslandingpage.com) | Real SaaS landings, browsable **by section** (hero, pricing, testimonials, footer) — the most useful axis when you are building one section at a time. |
-| [Landingfolio](https://www.landingfolio.com) | Landings and page sections, heavy on conversion patterns. |
-
-## Real product, real flows — not portfolios
-
-The most under-used bucket. Portfolio galleries show the hero; these show what happens after the click.
-
-| Source | Go here for |
-|---|---|
-| [Mobbin](https://mobbin.com) | Screens and full flows from shipped apps, mobile and web. The reference for "how does a real onboarding actually go". |
-| [Page Flows](https://pageflows.com) | Recorded user flows end to end — signup, checkout, cancellation. Video, so you see the motion too. |
-| [Screensdesign](https://screensdesign.com) | Mobile app screens with an emphasis on what is currently shipping. |
-| [Refero](https://refero.design) | UI/UX inspiration organised for browsing by pattern. |
-
-## One section, one pattern
-
-Use when the piece is small and named: `design-loop` splits a goal into three or four pieces, and
-these are for when a piece is "the footer" or "the empty state".
-
-| Source | Go here for |
-|---|---|
-| [Footer.design](https://www.footer.design) | Footers only. Narrow on purpose, and the narrowness is why it is good. |
-| [Collect UI](https://collectui.com) | Daily-UI-style collections by component and pattern. |
-| [UI Garage](https://uigarage.net) | Patterns tagged by element and by industry. |
-| [UI Movement](https://uimovement.com) | Motion and interaction specifically — pair with the frequency gate in `../../motion-craft/SKILL.md` before copying anything. |
-| [Dark.design](https://dark.design) · [Dark Mode Design](https://darkmodedesign.com) | Dark interfaces done properly, which is a different problem from inverting a light one. |
-| [Scrnshts](https://scrnshts.club) | App Store screenshot design — a real discipline of its own. |
-
-## Design systems as the canonical answer
-
-Not inspiration: **specification**. When the question is "what is the correct behaviour for this
-component", these outrank any gallery.
-
-| Source | Go here for |
-|---|---|
-| [Material 3](https://m3.material.io) | Google's system. Exhaustive on states, motion and tokens. |
-| [Apple HIG](https://developer.apple.com/design/human-interface-guidelines) | The reference for platform behaviour and for what *not* to invent on Apple platforms. |
-| [Shopify Polaris](https://polaris.shopify.com) | Dense, commerce-grade product UI with unusually good content guidance. |
-| [IBM Carbon](https://carbondesignsystem.com) | Enterprise density and data-heavy patterns. |
-| [GitHub Primer](https://primer.style) | Developer-tool UI, which is the closest analogue for most rsc projects. |
-| [The Component Gallery](https://component.gallery) *(bot-blocked)* | The same component compared **across** design systems — the fastest way to see the range of correct answers. |
-| [Adele](https://adele.uxpin.com) | Index of public design systems and their pattern libraries. |
-| [Designsystems.com](https://www.designsystems.com) | Essays on building and maintaining a system, not a system itself. |
-
-## Niche, but the right answer when it fits
-
-| Source | Go here for |
-|---|---|
-| [Interface In Game](https://interfaceingame.com) | Game UI. Useful well beyond games for diegetic and high-density HUD ideas. |
-| [Mobile.design](https://mobile.design) | Mobile-first patterns collected on their own terms. |
-
-## Housekeeping
-
-- **[Bestfolios](https://www.bestfolios.com) returned 502 on 2026-08-24** and is excluded until it
-  comes back. Do not cite it.
-- **Component ideas**, as opposed to whole pages, live in
-  Component galleries — Aceternity, 21st.dev, React Bits.
-- **Identity outranks all of this.** Check `02-DOCS/wiki/brand/` for what the project refuses before
-  bringing an idea back. A gallery cannot know what your brand vetoed.