Vellow

A mock-up of the screen, drawn from its layout, palette and typefaces. A build follows the full prompt below.

Start from this screenRead the build prompt

Typefaces

The catalog's own faces. A screen composed into a template is drawn in that template's typefaces.

• Source Sans 3Headings: Source Sans 3 700, 30px heading
• Source Sans 3Body: Source Sans 3 400/600, 16px/1.5; email in panel 16px 700

Patterns

• centred confirmation card
• mascot above heading
• tinted success panel with check icon
• echoed identifier
• single neutral continue button
• full site header and multi-column footer kept

States it is designed for

• Verifying (spinner card while token is exchanged)
• Verified (default)
• Already verified (neutral panel, same Continue)
• Expired link with resend
• Invalid/tampered link
• Verified but signed out: Continue goes to log in with email prefilled
• Network error with retry

Who it is for

• New members who just clicked a verification link
• Existing members who changed their email address
• Users arriving on a different device from where they signed up

Layout

1. Public header (logo, search, nav, avatar) at top
2. Centred 380px card with mascot overlapping top edge, bold heading, muted one-line confirmation
3. Mint-tinted success panel: check icon, bold email address, 'is verified' line
4. Short line about unlocked features, then full-width neutral Continue button
5. Generous whitespace, then a full site footer with theme switch and four link columns
6. Mobile: card full width with 16px gutters; footer columns become accordions

Palette

relieved, friendly, done. One glance tells the user it worked.

• page#ffffff
• success panel#ecfdf5
• success panel border#a7f3d0
• primary text#111827
• muted text#5b6472
• success text/icon#047857
• neutral button fill#f3f4f6
• button/card border#8a919e
• focus ring#2563eb
• error#c81e1e

Every checked pair, measured again

As vibld’s tokens

The palette on the fifteen colour tokens vibld styles a project with, each text colour on the fill it is read on.

• background
• card
• muted
• primary
• secondary
• accent
• destructive

Type scale

Display

Source Sans 3 700, 30px heading

Body

Source Sans 3 400/600, 16px/1.5; email in panel 16px 700

Humanist sans similar to the observed UI; footer headings 18px 600.

Spacing and imagery

Centred card 380px, padding 24px, radius 12px, 1px border and faint shadow; success panel radius 8px, padding 16px; footer 4 columns at 1200px container.

Original round mascot above the card; single filled check-circle icon; no photos.

Components

• Public header
• Confirmation card with mascot
• Success panel with check and echoed email
• Neutral Continue button
• Expired/invalid link card variant
• Resend verification form
• Site footer with theme switch

Interactions

• Card fades up on load
• Continue routes to the user's intended destination (stored return URL) or home
• Expired variant offers resend; resend shows cooldown
• Theme switch in footer toggles light/dark/system

Data

• EmailVerification{user_id, email, token_hash, expires_at, used_at}
• Profile{id, email_verified_at, return_to}

Guardrails

Experience

• Echo the exact address that was verified
• Offer one primary way forward; no competing buttons
• Explain expired links without blame and offer resend in place
• Return users to where they were headed before verification
• Keep the site header and footer so the page feels part of the product

Accessibility

• Heading announces the outcome; move focus to it on load
• Success conveyed by icon + text, not green alone
• Mascot decorative (alt='')
• Continue button has 4.5:1 label and 2px focus ring
• Expired state uses role=alert once, not repeatedly

Security

• Verify tokens server-side via Supabase Auth; single use with expiry
• Do not include the email in URLs or analytics events
• Return URLs allow-listed to same-origin paths
• Rate-limit resend per user and IP

Build prompt

The baseline every prompt in the catalog assumes, then this design’s own ten sections, from goal to guardrails.

Copy the baseline and build prompt

### How to use these prompts
Paste an entry's build prompt into your coding agent as the first message. Each prompt names its own stack, tokens and acceptance criteria; the rules below apply to all of them and can be prepended once per project.

### Engineering baseline
- TypeScript strict mode, no `any`, small typed components, feature folders, and one source of truth for design tokens (CSS variables consumed by Tailwind).
- Validate every input with a shared zod schema on the client and again on the server or edge function. Never trust client-side checks alone.
- Show loading, empty and error states for every async view. Surface errors in plain language with a retry, and log details to the console in development only.
- Keep secrets out of the bundle. Only publishable keys (for example a Supabase anon key) belong in client code; service-role keys, API keys and webhooks live in server or edge-function environment variables.

### Data and auth baseline (full-stack entries)
- Enable Row Level Security on every table before inserting data. Default-deny, then add owner-scoped policies (`auth.uid() = user_id`) and explicit role checks for admin views.
- Store roles in a separate table checked by a security-definer function, never in a user-editable profile field.
- Upload files to private storage buckets with size and MIME limits, and serve them through signed URLs.
- Rate-limit public endpoints (forms, auth, AI calls) and add a honeypot field or captcha to anonymous forms.
- Take payments through a hosted checkout and verify webhooks by signature. Never handle raw card data.

### Accessibility and UX baseline
- Target WCAG 2.2 AA: 4.5:1 contrast for normal text and 3:1 for large text, input borders, focus rings and meaningful icons or chart lines. Every palette in this catalog lists its verified pairs; re-check with a contrast tool after any colour change.
- Keep body text at 16px or larger with 1.5 line height, nothing below 12px, no light weights under 24px, and uppercase only for short labels.
- Give every interactive element a visible focus ring, full keyboard support, semantic landmarks, labelled form fields, and alt text on meaningful images.
- Respect `prefers-reduced-motion` for every animation. Give drag-and-drop and carousels keyboard and button alternatives.
- Build mobile-first and test at 375px, 768px and 1280px.

### Content guardrails
- Use original copy, fictional sample data and placeholder or licensed imagery. Do not reuse another product's name, logo, screenshots or marketing text.
- Label demo testimonials and metrics as samples. Collect the minimum personal data the feature needs.

### SaaS screen baseline
- Design every screen for its full set of states: first-run empty, loading skeleton, partial data, error with retry, permission-denied, and success feedback. Each entry lists the states its screen needs.
- Keep destructive actions (delete, revoke, downgrade, remove member) behind a confirmation that names the object, and prefer undo over a second dialog where the action is reversible.
- Enforce authorisation on the server for every action a screen exposes. Hiding a button is not access control; check the role again in the API or RLS policy.
- Never show secrets (API keys, tokens) in full after creation. Show them once, then mask them, and offer rotate and revoke.
- Keep the app shell (navigation, workspace switcher, account menu) consistent across screens, and preserve filters, sort and scroll position when the user navigates back.

### Goal
Build **Vellow**'s email-verified page: what a member sees after clicking the link in a verification email. It must confirm success at a glance, show the exact address verified, and send the user onward with one button, while handling expired, reused and tampered links gracefully.

### Stack
React 18 + TypeScript + Vite, Tailwind CSS, shadcn/ui (Radix primitives) and lucide-react icons. TanStack Query for server state, react-hook-form + zod for forms, date-fns for dates. Supabase for Auth, Postgres and Row Level Security. The page exchanges the token with Supabase Auth on mount.

### Pages & layout
1. **Header**: logo + wordmark, search, text nav, avatar menu (or Log in when signed out).
2. **/verify?token=...**: spinner card while verifying, then the success card: mascot badge overlapping the top, 'Email verified' heading, muted 'Your address is confirmed', a mint panel with a check-circle icon, the email in bold and 'is now verified', a line 'You can now publish, comment and join organisations', and a full-width neutral 'Continue' button.
3. **Variants**: already verified (neutral panel, same button), expired (amber-free neutral card with 'This link has expired' and a Resend button with 60s cooldown), invalid (explains and links to settings).
4. **Footer**: theme switch left, four link columns (Product, Company, Resources, Social) with invented labels.
5. Mobile: card full width; footer columns collapse into disclosure groups.

### Design system
- Colors: `--bg: #ffffff` (page), `--success-bg: #ecfdf5` (success panel), `--success-border: #a7f3d0` (success panel border), `--fg: #111827` (primary text), `--muted: #5b6472` (muted text), `--success: #047857` (success text/icon), `--btn: #f3f4f6` (neutral button fill), `--border: #8a919e` (button/card border), `--ring: #2563eb` (focus ring), `--danger: #c81e1e` (error).
- Fonts: Source Sans 3 400/600/700; heading 30px/1.2 700; body 16px/1.5.
- Spacing: 4px base; card padding 24px; 16px between blocks; page top padding 80px.
- Radius: card 12px, panel and button 8px.
- Shadows: card `0 1px 3px rgb(17 24 39 / 0.08)`.
- Motion: 200ms fade-up; check icon scales from 0.8 to 1 over 180ms; disabled under reduced motion.

### Components & interactions
`PublicHeader`, `ResultCard` (mascot, title, subtitle, children), `SuccessPanel` (icon, emphasised identifier, caption), `NeutralButton`, `ResendButton` (cooldown), `StatusCard` variants (verifying, expired, invalid, error), `SiteFooter` with `ThemeSwitch` (Radix ToggleGroup: light/dark/system).

### Data & state
Supabase Auth owns tokens; `profiles(id, email_verified_at, return_to)` stores where to send the user after verification (set at sign-up, same-origin paths only). Mock mode: `?state=verified|already|expired|invalid|error` to preview each variant.

### Accessibility
On load, focus the result heading so screen readers hear the outcome. Success uses icon + text; the check icon also meets 3:1 on the mint panel. Buttons have visible 2px focus rings. Footer headings are real headings; theme switch is a labelled toggle group. Respect reduced motion.
Verified contrast: body text on page: #111827 on #ffffff = 17.74:1; muted text on page: #5b6472 on #ffffff = 5.98:1; success text on panel: #047857 on #ecfdf5 = 5.21:1; email text on panel: #111827 on #ecfdf5 = 16.84:1; button label on neutral fill: #111827 on #f3f4f6 = 16.12:1; button border: #8a919e on #ffffff = 3.17:1; focus ring: #2563eb on #ffffff = 5.17:1; check icon on panel: #047857 on #ecfdf5 = 5.21:1.

### Security
Token exchange server-side via Supabase Auth; tokens single use with expiry. Strip the token from the URL with `history.replaceState` after exchange. `return_to` must start with `/` and match an allow-list. RLS on `profiles`: owner-only select/update. Resend is rate-limited (3 per hour per user and IP). No email address in analytics or error logs.

### Performance & SEO
Tiny route: no extra libraries beyond the auth client; inline mascot SVG. `noindex` the verify route. Footer links prefetch on hover only.

### Guardrails
- Use an original mascot and wordmark.
- Write fresh copy and invented footer labels.
- Never show another user's email even if the token is for a different account; show a neutral error instead.

Acceptance criteria:
- [ ] Verified, already-verified, expired and invalid variants all render
- [ ] Token disappears from the URL after exchange
- [ ] Continue respects a safe return path
- [ ] Focus lands on the result heading
- [ ] Contrast pairs pass

Open the builderAll templatesThis palette on its own