Rallyfold

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, 22px step title, -0.01em
• InterBody: Inter 400, 16px, line-height 1.5

Patterns

• split modal: form left, visual right
• segmented progress dashes
• multi-email textarea with submit arrow
• floating preview card over abstract image
• Back pill plus wide Skip button
• dimmed app shell behind modal

States it is designed for

• empty: Skip label, arrow disabled
• typing: chips appear; arrow enabled when ≥1 valid email
• invalid email: chip error with reason
• sending: arrow spinner
• sent: preview card lists invitees as 'Pending'
• duplicate or already-member: inline note
• invite limit reached: message with upgrade link
• network error: inline error with Retry

Who it is for

• new workspace creators on a no-code app builder
• small-team leads during first-run setup

Layout

1. dimmed app shell: left sidebar card (workspace switcher, Home, Projects, Store, Recent list, upgrade promo card), Invite button top-right
2. centred modal ~570x400px with 6px white frame, two equal columns
3. left column: progress dashes, title, subtitle, email textarea with round arrow button, bottom row with Back pill and wide dark Skip/Continue button
4. right column: blurred abstract photo with a floating share-panel preview card (invite field, 'Who has access' list with owner row)
5. below 720px the right column hides and the modal becomes full-screen

Palette

Calm, premium and minimal; a soft photographic panel makes a form step feel inviting.

• bg#ffffff
• field#efefef
• text#171717
• muted#5f5f5f
• button#1a1a1a
• pill#ececec
• progress-off#8a8a8a
• avatar#dfe7fb
• avatar-text#2e4aa8
• scrim#3a3a3a

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, 22px step title, -0.01em

Body

Inter 400, 16px, line-height 1.5

Buttons 15px 500. Preview card text 15px; its labels 13px 600.

Spacing and imagery

Density: Relaxed. Grid: 8px base; modal padding 20px; column gap 24px. Container: modal 720px max, columns 1fr 1fr. Radius: 18px modal, 12px textarea and preview card, full pills for buttons. Shadows: Modal large soft shadow; preview card 0 6px 20px rgba(0,0,0,0.15).

An abstract, motion-blurred neutral photo (commission or generate your own) behind a crisp UI preview card.

Components

• SetupModal
• StepProgress (dashes)
• EmailChipsInput (textarea that tokenises)
• ArrowSubmitButton
• SharePreviewCard
• BackPill
• PrimaryWideButton (Skip / Continue)
• AppSidebar (dimmed)

Interactions

• Typing commas, spaces or Enter turns emails into removable chips; invalid ones turn red with a message
• Arrow button sends invites and appends invitees to the preview card list
• Primary button label switches from 'Skip' to 'Continue' once at least one invite is sent
• Back returns to the previous step preserving input
• Esc does not close the setup modal; a close link asks for confirmation

Data

• Workspace{id, name, owner_id, plan (free|pro)}
• Invitation{id, workspace_id, email, role (member|admin), status (pending|accepted|expired), invited_by, created_at}
• SetupProgress{workspace_id, step (name|use-case|invite|done)}

Guardrails

Experience

• Skip must always be available; inviting is optional
• Show invitees in the preview immediately so the result is visible
• Accept commas, spaces and newlines as separators
• Keep the step to one input
• Preserve entered emails if the user goes Back and returns

Accessibility

• Progress dashes have an accessible label 'Step 3 of 4'
• Chips are buttons with 'Remove name@example.com' labels
• Errors are linked with aria-describedby and announced
• Right-hand photo panel is aria-hidden; the preview is decorative
• Modal traps focus and has an accessible title

Security

• Validate emails with zod client- and server-side; cap 20 per request
• Rate-limit invites per workspace per hour
• Invitation tokens are single-use, random, expire in 7 days
• RLS: only workspace owners/admins insert invitations; invitees can read only their own by token via an Edge Function

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 **Rallyfold**, the 'bring your team' step of a new-workspace setup modal. The creator types teammates' emails, sends invites and sees them appear in a preview of the share panel; they can also skip. Build the dimmed app shell, the four-step modal with this step fully working and stub content for the others.

### Stack
React 18 + TypeScript + Vite, Tailwind CSS, shadcn/ui on Radix primitives and lucide-react icons. TanStack Query for server state, react-hook-form + zod for every form, date-fns for relative times. Supabase for Auth, Postgres with row-level security and Edge Functions for anything that needs a secret. Send invite emails through a transactional email service from an Edge Function.

### Pages & layout
1. **Dimmed shell**: floating left sidebar card with workspace switcher, Home, Projects, Store, a Recent section and a promo card with Upgrade; Invite button top-right.
2. **Setup modal**: white 18px-radius frame; left column with four progress dashes (third active), title 'Bring your team in', one-line subtitle, grey textarea with a round arrow button bottom-right; bottom row with 'Back' pill and full-width dark 'Skip' button.
3. **Right column**: abstract blurred photo filling the column with a floating preview card: an invite field, 'Who has access' label and the owner row (avatar initial, name '(you)', email, role).
Responsive: hide the right column under 720px; modal goes full-screen.

### Design system
- Colors: `--bg: #ffffff` (modal surface), `--field: #efefef` (textarea fill), `--text: #171717` (primary text), `--muted: #5f5f5f` (subtitle and placeholder), `--button: #1a1a1a` (primary dark button), `--pill: #ececec` (Back pill fill), `--progress-off: #8a8a8a` (inactive progress dash), `--avatar: #dfe7fb` (owner avatar fill), `--avatar-text: #2e4aa8` (owner initial), `--scrim: #3a3a3a` (backdrop at 60%).
- Fonts: Inter 600, 22px step title, -0.01em for headings; Inter 400, 16px, line-height 1.5 for body. Buttons 15px 500. Preview card text 15px; its labels 13px 600.
- Spacing: Relaxed. 8px base; modal padding 20px; column gap 24px. Container: modal 720px max, columns 1fr 1fr.
- Radius: 18px modal, 12px textarea and preview card, full pills for buttons.
- Shadows: Modal large soft shadow; preview card 0 6px 20px rgba(0,0,0,0.15).
- Motion: Progress dash for the current step animates width over 200ms; step transitions slide 16px and fade; arrow button nudges on hover.

### Components & interactions
EmailChipsInput tokenises input into chips inside the grey field and exposes the arrow submit. SharePreviewCard renders the real invitee list so the preview doubles as confirmation.

- Typing commas, spaces or Enter turns emails into removable chips; invalid ones turn red with a message
- Arrow button sends invites and appends invitees to the preview card list
- Primary button label switches from 'Skip' to 'Continue' once at least one invite is sent
- Back returns to the previous step preserving input
- Esc does not close the setup modal; a close link asks for confirmation

### Data & state
Seed the owner as an invented person with an example.com email. Invites are created via a mutation; the preview list reads from the same TanStack Query cache. Setup step is stored server-side so reloads resume.

Entities: `Workspace{id, name, owner_id, plan (free|pro)}`; `Invitation{id, workspace_id, email, role (member|admin), status (pending|accepted|expired), invited_by, created_at}`; `SetupProgress{workspace_id, step (name|use-case|invite|done)}`.

States to build and show in a dev-only state switcher:
- empty: Skip label, arrow disabled
- typing: chips appear; arrow enabled when ≥1 valid email
- invalid email: chip error with reason
- sending: arrow spinner
- sent: preview card lists invitees as 'Pending'
- duplicate or already-member: inline note
- invite limit reached: message with upgrade link
- network error: inline error with Retry

### Accessibility
- Progress dashes have an accessible label 'Step 3 of 4'
- Chips are buttons with 'Remove name@example.com' labels
- Errors are linked with aria-describedby and announced
- Right-hand photo panel is aria-hidden; the preview is decorative
- Modal traps focus and has an accessible title
Verified contrast: body text: #171717 on #ffffff = 17.93:1; subtitle / placeholder: #5f5f5f on #efefef = 5.55:1; dark button label: #ffffff on #1a1a1a = 17.4:1; Back pill label: #171717 on #ececec = 15.18:1; inactive progress dash: #8a8a8a on #ffffff = 3.45:1; avatar initial: #2e4aa8 on #dfe7fb = 6.37:1; focus ring: #1a1a1a on #ffffff = 17.4:1.

### Security
- Validate emails with zod client- and server-side; cap 20 per request
- Rate-limit invites per workspace per hour
- Invitation tokens are single-use, random, expire in 7 days
- RLS: only workspace owners/admins insert invitations; invitees can read only their own by token via an Edge Function
RLS detail: `invitations` insert/select/delete for owner and admin members of the workspace; `setup_progress` select/update for the workspace owner only.

### Performance & SEO
Serve the photo as AVIF/WebP at 2 sizes with a blurred placeholder; hide it (not just visually) on small screens so it isn't downloaded.

### Guardrails
- Skip must always be available; inviting is optional
- Show invitees in the preview immediately so the result is visible
- Accept commas, spaces and newlines as separators
- Keep the step to one input
- Preserve entered emails if the user goes Back and returns
- Write fresh, generic copy and invented sample data; no real brands, logos, product names or people.
- Keep components small and typed (no `any`); surface every error visibly with a way to recover.

Acceptance criteria:
- Valid emails become chips and invalid ones explain why
- Sending creates pending invitations and they appear in the preview
- Skip/Continue label reflects whether invites were sent
- Setup resumes on the same step after reload
- Only owners/admins can invite

Open the builderAll templatesThis palette on its own