Mendwick

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 700, 24px, tracking -0.01em for card titles
• InterBody: Inter 400, 16px/1.5; prompt rows 15px; step list 14px 500; caption 14px muted

Patterns

• two-card wizard layout (context rail + work card)
• segmented step progress bar
• step checklist with completed ticks
• pro-tip callout
• grouped list under pill labels
• inline edit per row
• signal-strength indicator
• back / complete footer

States it is designed for

• generating (skeleton rows with 'Writing your questions' status)
• generation partially failed (group shows retry)
• empty group hidden
• row in edit mode
• edit validation (empty or over 200 chars)
• unsaved edits on Back (confirm dialog)
• completing
• complete failed with retry
• all done (toast on dashboard)

Who it is for

• marketing managers
• brand and PR teams
• growth-minded founders

Layout

1. Top bar: wordmark left, sign-out text button with icon right
2. Left rail card (~300px): 7-segment progress bar, 'Step 7 of 7', step title with icon, short explanation, arrow bullet list, amber pro-tip callout, vertical step list with green check icons and the current step highlighted
3. Main card (~420px, centred): square icon tile, title, subtitle, groups each headed by a solid blue pill label followed by bordered prompt rows (text, 3-bar strength meter, pencil button)
4. Footer inside main card: item count caption, divider, ghost Back left, solid blue Complete right
5. Below 960px: rail collapses to a compact header with progress bar and a 'Steps' disclosure; main card goes full width

Palette

Organised, reassuring, productive. Blue marks action and grouping; green confirms progress.

• canvas#f7f9fa
• surface#ffffff
• text#111827
• muted#4b5563
• border#e3e8ef
• primary#2563eb
• on-primary#ffffff
• progress-track#d6deec
• success#15803d
• tip-bg#fffbeb
• tip-text#b45309
• focus#1d4ed8

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 700, 24px, tracking -0.01em for card titles

Body

Inter 400, 16px/1.5; prompt rows 15px; step list 14px 500; caption 14px muted

Similar to the observed neo-grotesk. Group pills 14px 600 white on blue, sentence case.

Spacing and imagery

Medium density; 8px base; rail and card padding 24px; 24px gap between cards; radius 12px cards, 6px rows and pills, 8px buttons; faint 0 1px 2px shadow on cards.

Line icons only (chat bubble for step, arrows for bullets, lightning for tip, sparkle for current step). A square neutral tile at the top of the card shows the workspace mark.

Components

• segmented progress bar
• step checklist
• pro-tip callout
• group label pill
• editable prompt row
• 3-bar strength indicator
• inline edit textarea
• back and complete buttons
• count caption

Interactions

• Pencil turns the row into an auto-growing textarea with Save and Cancel; Enter saves, Shift+Enter newline, Escape cancels
• Strength bars have a tooltip explaining the score
• Completed steps in the rail are links back to that step
• Complete shows a spinner and then routes to the dashboard with a success toast
• Rows fade in group by group as generation finishes (skipped under reduced motion)

Data

• Workspace{id, name, setup_step, setup_completed_at}
• PromptGroup{id, workspace_id, label, position}
• Prompt{id, group_id, text, strength (1|2|3), edited bool, created_at}

Guardrails

Experience

• Show exactly where the user is (7 of 7) and that previous steps are done
• Let users edit any generated item before committing
• Explain the strength indicator in words on hover and focus
• Warn before Back discards unsaved edits
• Keep Complete as the single primary action
• Never regenerate over user edits without asking

Accessibility

• Progress bar is role=progressbar with a text equivalent 'Step 7 of 7'
• Step list is an ordered list with aria-current=step on the active item
• Strength meter exposes a text label (Low/Medium/High) not just bars
• Pill labels are headings (h3) for their groups
• Edit buttons have accessible names including the prompt text start
• Focus returns to the pencil button after save or cancel

Security

• RLS: prompts and groups readable/writable only by workspace members
• Validate edited prompt text length and strip HTML before saving
• Generation runs server-side; the model key lives only in the Edge Function environment
• Complete setup is idempotent and checks all prior steps server-side

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 **Mendwick**, the seventh and final step of a setup wizard for an AI-visibility tracker. The system has generated around eight customer-style questions grouped under three themes; the user checks them, edits wording where needed and completes setup. A context rail explains why these questions matter and shows the six finished steps.

### Stack
React 18 + TypeScript + Vite, Tailwind CSS, shadcn/ui (Button, Textarea, Tooltip, AlertDialog, Toast), lucide-react. TanStack Query for groups and prompts; zod for edits; Supabase Auth and Postgres; a Supabase Edge Function performs generation using a hosted model API.

### Pages & layout
1. **/setup/review** (this screen) on a pale canvas under a slim top bar (wordmark, 'Sign out').
2. Left rail card: 7-segment bar (all filled, last one lighter while current), 'Step 7 of 7', title 'Tracked questions' with a chat icon, two-sentence explanation, four arrow bullets, amber 'Tip' callout, ordered step list (Brand, Content, Competitors, Keywords, Topics, Audience, Questions) with green ticks and the current row highlighted.
3. Main card: workspace tile, title 'Check your questions', subtitle, three groups (e.g. 'Onboarding checklists', 'Team scheduling', 'Budget templates') each with two or three rows like 'Which tool helps a small agency plan client work?'. Footer caption '8 questions', divider, Back and 'Finish setup'.
4. Mobile: rail becomes a sticky mini header with the bar and a 'Steps' sheet trigger.

### Design system
- Colors: `--canvas: #f7f9fa`, `--surface: #ffffff`, `--text: #111827`, `--muted: #4b5563`, `--border: #e3e8ef`, `--primary: #2563eb`, `--on-primary: #ffffff`, `--progress-track: #d6deec`, `--success: #15803d`, `--tip-bg: #fffbeb`, `--tip-text: #b45309`, `--focus: #1d4ed8`.
- Fonts: Inter (similar to observed). Titles 24px/700; body 16px/1.5; rows 15px; step list 14px/500.
- Spacing: 8px base, 24px card padding, 12px between rows, 20px between groups.
- Radius: cards 12px, rows 6px, pills 6px, buttons 8px.
- Shadows: cards `0 1px 2px rgba(16,24,40,.06)`.
- Motion: 180ms ease for row edit transitions; staggered group reveal 60ms; off under reduced motion.

### Components & interactions
`WizardRail` (SegmentedProgress, StepList, TipCallout), `ReviewCard`, `GroupPill`, `PromptRow` (text, StrengthMeter, edit IconButton), `PromptEditor` (auto-grow Textarea, 200-char counter, Save/Cancel), `WizardFooter`. Hover on a row shows a light border darken; focus-visible shows a 2px blue ring. Back opens an AlertDialog when edits are unsaved.

### Data & state
`prompt_groups(id, workspace_id, label, position)`, `prompts(id, group_id, workspace_id, text, strength smallint check 1-3, edited, created_at)`, and `workspaces.setup_step`. Generation writes rows; the UI polls or subscribes until status is ready. Mock data: three groups, eight prompts, strengths mixed. Completing sets `setup_completed_at` via an RPC that verifies steps 1-6.

### Accessibility
Rail uses an ordered list with `aria-current="step"`. Strength meter renders visually as bars with `aria-label="Relevance: high"`. Group labels are real headings. Inline editor announces character count every 20 chars remaining. Tooltips open on focus as well as hover.
Verified contrast: body text on card: #111827 on #ffffff = 17.74:1; muted explanation on card: #4b5563 on #ffffff = 7.56:1; pill and button label on blue: #ffffff on #2563eb = 5.17:1; pro-tip text on tip background: #b45309 on #fffbeb = 4.84:1; success tick on card: #15803d on #ffffff = 5.02:1; progress segment on track: #2563eb on #d6deec = 3.82:1; focus ring on card: #1d4ed8 on #ffffff = 6.7:1; text on canvas: #111827 on #f7f9fa = 16.8:1.

### Security
RLS on `prompt_groups` and `prompts`: members of the workspace only for select/insert/update/delete. The Edge Function holds the model API key as a secret, validates the caller's membership, and rate-limits generation per workspace. zod plus a `char_length(text) <= 200` constraint. The complete RPC is idempotent.

### Performance & SEO
Stream groups as they are generated. Avoid refetching the whole list after one edit (update the cached row). Setup routes noindex.

### Guardrails
- Invent all brand, product and question text; no real companies
- Do not claim results or rankings in setup copy
- Do not auto-submit edits on blur without feedback
- Typed components, visible error states
- Acceptance criteria: (1) each prompt can be edited and saved with validation; (2) Back warns about unsaved edits; (3) Finish setup fails gracefully and retries; (4) RLS blocks cross-workspace access; (5) rail and card stack cleanly at 390px.

Open the builderAll templatesThis palette on its own