Starfold

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.

• InterHeadings: Inter 600, 20px card title
• InterBody: Inter 400 16px inputs; 14px labels (500) and subline; 13px footer

Patterns

• asymmetric split: large pixel-dot illustration left, auth card right overlapping
• OAuth-first auth card (continue with a provider)
• "or" divider
• password field with show/hide eye
• dark full-width Continue button with arrow
• card footer band with sign-in link
• "Secured by" trust strip
• subtle dot-grid background texture

States it is designed for

• Default
• Inline validation (invalid email, weak password)
• Email already registered (offer sign in / reset)
• Submitting
• OAuth cancelled or failed banner
• Verification email sent screen
• Rate-limited ("Too many attempts, try again in 1 minute")
• Invite link prefilled email (read-only)

Who it is for

• Developers and ops teams evaluating an agent platform
• Technical founders
• Invited teammates creating accounts

Layout

1. Top-left logo + wordmark
2. Left 55%: pixel-dot rendering of the brand asterisk in greens fading to light edges on a dot-grid background
3. Right: card (~360-400px) overlapping the illustration: logo icon, H1, subline, OAuth button, divider, Email, Password with eye, Continue; footer band "Already have an account? Sign in"; trust strip
4. Tablet: illustration shrinks behind card at 30% opacity
5. Mobile: illustration hidden (or small header band); card full width

Palette

crisp, playful-technical, trustworthy, focused. A pixel-art mark that nods to computation, next to a no-nonsense form.

• page background#f6f6f5
• auth card#ffffff
• card footer band#f7f7f7
• headings and labels#1a1a1a
• subline, placeholders#5f5f5f
• Continue button#2b2a28
• Continue label#ffffff
• input outlines#8a8a8a
• pixel mark green#2f9e44
• pixel fade (decorative)#b7dfb5

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. Marked tokens are solved from the palette, because no swatch held that role at 4.5:1.

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

Type scale

Display

Inter 600, 20px card title

Body

Inter 400 16px inputs; 14px labels (500) and subline; 13px footer

Similar to the observed neutral grotesk; the wordmark uses a friendly rounded sans (e.g. Manrope 600).

Spacing and imagery

Compact card: 8px base; card padding 24px; 16px between fields; inputs 40px; radius 12px card, 8px inputs and buttons; card shadow 0 10px 30px rgba(0,0,0,.08).

A brand asterisk built from rounded square pixels in several greens with a fading halo; faint dot-grid texture across the page.

Components

• Logo + wordmark
• Pixel-dot illustration (canvas or SVG)
• Auth card
• OAuth button with provider glyph
• "or" divider
• Email input
• Password input with visibility toggle and strength hint
• Continue button with arrow
• Footer band with sign-in link
• Trust strip

Interactions

• Illustration pixels subtly twinkle on load (disabled under reduced motion)
• Password eye toggles visibility with aria-pressed
• Continue validates on submit, shows spinner, then routes to email verification
• OAuth opens provider consent; returns to onboarding
• Enter submits; errors focus the first invalid field

Data

• User{id, email, email_verified_at, created_at}
• Identity{user_id, provider (password|oauth), provider_id}
• Invite{id, org_id, email, token, expires_at}
• SignupAttempt{ip_hash, count, window_start}

Guardrails

Experience

• OAuth first, email second, divided clearly
• Keep the form to two fields; ask for name later in onboarding
• Show password rules only when relevant (on focus or error)
• Link to sign in in the footer band, not hidden
• Never let the illustration crowd the card on small screens

Accessibility

• Labels visible above inputs (not placeholder-only)
• Password toggle is a button with aria-label and aria-pressed
• Errors announced with aria-live and linked via aria-describedby
• Illustration aria-hidden
• Correct autocomplete attributes (email, new-password)

Security

• Use the hosted auth provider's password hashing; never log passwords
• Rate-limit sign-up per IP and email; add bot protection on repeated attempts
• Require email verification before workspace access
• Generic error for existing accounts in API responses (UI may suggest sign in)
• CSRF-safe OAuth state and PKCE

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 **Starfold**, the sign-up screen of an AI agent platform. The left side shows a large brand asterisk made of green rounded pixels on a faint dot grid; the right side has a compact card with one OAuth button, an "or" divider, email and password fields, and a dark Continue button. A footer band links to sign in, and a small trust strip notes that sign-in is handled by a hosted auth provider.

### Stack
Next.js (App Router) + TypeScript, Tailwind CSS, shadcn/ui (Form, Input, Button, Alert) on Radix, lucide-react, react-hook-form + zod. Supabase Auth for email/password and one OAuth provider with email verification.

### Pages & layout
1. **Header**: logo mark and invented wordmark top-left.
2. **Illustration** (left ~55%): an SVG or canvas asterisk of about 900 rounded squares in 3-4 greens, fading to pale green at the edges, over a dot-grid page texture.
3. **Auth card** (400px, overlapping the illustration's right edge): logo icon; "Create your account"; subline "Welcome! Fill in a few details to get started"; "Continue with a provider" button; "or" divider; Email address; Password with eye toggle; Continue with a small arrow.
4. **Card footer band**: "Already have an account? Sign in"; below it a thin trust strip.
5. **/sign-in** reuses the layout with the fields swapped; **/verify** confirms the email was sent.
6. Tablet: the illustration dims behind the card. Mobile: it becomes a short header band; the card goes full width.

### Design system
- Colors: `--bg: #f6f6f5` (page background), `--card: #ffffff` (auth card), `--footer: #f7f7f7` (card footer band), `--fg: #1a1a1a` (headings and labels), `--muted: #5f5f5f` (subline, placeholders), `--button: #2b2a28` (Continue button), `--on-button: #ffffff` (Continue label), `--input-border: #8a8a8a` (input outlines), `--brand: #2f9e44` (pixel mark green), `--brand-light: #b7dfb5` (pixel fade (decorative)).
- Fonts: Inter (similar to the observed grotesk): title 20px/600, inputs 16px, labels 14px/500, subline 14px, footer 13px; wordmark in Manrope 600.
- Spacing: 8px scale; 24px card padding; 16px field gap; 40px inputs.
- Radius: card 12px; inputs and buttons 8px; pixels 2px.
- Shadows: card `0 10px 30px rgba(0,0,0,.08)`.
- Motion: pixels twinkle once on load over 1.2s; none under reduced motion.

### Components & interactions
PixelMark (generated from a small grid map; aria-hidden), AuthCard, OAuthButton (generic provider glyph), OrDivider, EmailField, PasswordField (show/hide with aria-pressed; strength hint on focus), SubmitButton (spinner), FormAlert, FooterBand, TrustStrip. Enter submits; on error, focus the first invalid field. Invite links prefill a read-only email.

### Data & state
Supabase `auth.users` plus `profiles(id, created_at)`, `invites(id, org_id, email, token, expires_at)`. Handle states: default, inline validation, already registered, submitting, OAuth cancelled/failed, verification sent, rate-limited, invite prefill.

### Accessibility
Labels stay visible above inputs. Use `autocomplete="email"` and `new-password`. Errors are linked with aria-describedby and announced. The illustration is aria-hidden. Focus ring: 2px near-black with a 2px white offset. The page works at 200% zoom with no horizontal scroll.
Verified contrast: heading on card: #1a1a1a on #ffffff = 17.40:1; muted subline: #5f5f5f on #ffffff = 6.39:1; footer text on band: #5f5f5f on #f7f7f7 = 5.96:1; Continue label: #ffffff on #2b2a28 = 14.34:1; input border: #8a8a8a on #ffffff = 3.45:1; brand pixels on page: #2f9e44 on #f6f6f5 = 3.19:1; focus ring: #2b2a28 on #ffffff = 14.34:1.

### Security
Rely on the auth provider for hashing and sessions. Use PKCE and a state parameter for OAuth. Rate-limit sign-up by IP and email and add a bot challenge after repeated attempts. Require email verification before workspace access. API errors don't confirm that an account exists. Log no credentials.

### Performance & SEO
Render the pixel mark as one inline SVG path set (under 30 KB) or a canvas drawn after first paint. The sign-up page has a title and meta description and is indexable; the verification page is noindex.

### Guardrails
- Original pixel mark and wordmark; generic provider glyph; no third-party auth branding.
- Two fields only; ask for more details in onboarding.
- Acceptance criteria: (1) email sign-up sends verification; (2) OAuth completes and routes to onboarding; (3) every error state renders; (4) the layout holds from 320px to 1440px; (5) contrast and keyboard checks pass.

Open the builderAll templatesThis palette on its own