Northstar

A mock-up of the homepage, drawn from this design’s layout, palette and typefaces. A build follows the full prompt below.

Start from this templateRead the build prompt

Typefaces

Fira Sans Condensed gives the condensed grotesk headline, and the rounded Red Hat Mono keeps the monospace body calm and ocean-toned rather than hard-edged.

• Fira Sans CondensedHeadings: headings 40px 600 at -0.06em
• Red Hat MonoBody: body and UI copy

Who it is for

• Startup founders and team leads
• Small product and ops teams
• People managers running quarterly planning
• Teams replacing OKR spreadsheets

Layout

1. Floating translucent top bar: target-icon logo left, teal 'Try demo' pill and 'Sign in' right
2. Split hero on pale grey with dot texture: headline, monospace subcopy, CTAs left; browser-framed app mockup of the goals table right
3. Deep teal band with pill tab switcher (The cascade / Check-ins / Analytics) and pause button auto-cycling large product UI mockups
4. Centered closing CTA with glow
5. Minimal footer
6. App: workspace overview (30-day trend), cascade goals table with expandable objectives, goal detail with activity feed and check-in card, reporting dashboard, settings

Palette

Calm, technical, clear, trustworthy, ocean-toned. Feels like a precise instrument rather than a corporate suite.

• background#f4f6f7
• text#0a2833
• primary teal#0f6e92
• band teal#1a7aa0
• on track green#16a34a
• progressing amber#d47406
• off track red#dc2626
• muted text#4a616b
• input border#7b929e

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

Fira Sans Condensed 600, 40px with -0.06em tracking (very tight)

Body

Red Hat Mono 400 for body/UI copy

Condensed grotesk headlines paired with monospace body for a technical, dashboard-native feel

Spacing and imagery

Wide 1200px container, 32px gutters; app UI dense with 32–40px table rows; 11px radius cards, full pill buttons; soft ambient shadows on UI mockups

Product UI mockups in faux browser chrome as the main imagery, small circular avatars, colored progress bars and status dots; faint dot-grid texture.

Components

• Floating nav bar
• Browser-frame UI mock
• Auto-cycling tab showcase with pause
• Goals tree table with expand chevrons
• Progress bar with status color
• Owner avatar chip
• Quarter switcher
• Owner/Status filter dropdowns
• Check-in card with slider and note
• Activity feed
• Trend line chart
• Report cards

Interactions

• Tab showcase auto-advances with pause/play
• Expand/collapse objectives to reveal key results
• Check-in slider updates percentage live
• Filters by quarter, owner, status
• Progress recomputes from KR metrics
• Toast on check-in posted
• Hover row highlight
• Demo mode toggle

Data

• Objective{id, workspace_id, title, owner_id, cycle, status, progress}
• KeyResult{id, objective_id, title, owner_id, metric_type, start_value, target_value, current_value, unit}
• CheckIn{id, key_result_id, author_id, value, progress, note, created_at}
• Member{id, workspace_id, user_id, role}
• Workspace{id, name}

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 a template'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 templates)
- 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.

### Goal
Build **Northstar**, a lightweight OKR tracker for teams of 3–30. Leads set quarterly objectives, attach measurable key results, and owners post check-ins in seconds. A reporting view shows what's on track, at risk or off track. The job: keep goals visible and updated without a weekly status meeting.

### Stack
React 18 + TypeScript + Vite, Tailwind CSS, shadcn/ui (Radix), lucide-react. TanStack Query for data, TanStack Table for the goals tree, react-hook-form + zod for goal and check-in forms, Recharts for trend and report charts, Framer Motion for the landing tab showcase, dnd-kit for reordering objectives, date-fns for cycles. Supabase: Auth (Google OAuth + email), Postgres with RLS per workspace.

### Pages & layout
1. **Landing** – floating translucent top bar; split hero (tight condensed headline, monospace subcopy, teal pill CTA + text link) with a browser-framed mockup of the goals table; a deep teal band with pill tabs (Cascade / Check-ins / Analytics) that auto-rotate large UI mockups and a pause button; closing CTA; footer.
2. **Auth** – sign in/up/forgot.
3. **Overview** – progress summary cards, 30-day trend line, my key results.
4. **Goals** – cycle switcher (‹ Q2 2026 ›), owner and status filters, search, "+ New"; tree table: Name, Owner, Progress bar, Status dot.
5. **Goal detail** – KRs with metrics, activity feed, check-in card (slider 0–100 or metric value input, note, submit).
6. **Reports** – status distribution, progress by owner, at-risk list.
7. **Settings** – workspace, members, cycles.

### Design system
Ocean palette on cool grey. `--background: #f4f6f7`, `--foreground: #0a2833`, `--primary: #0f6e92`, `--primary-band: #1a7aa0`, `--card: #ffffff`, `--border: #dde3e6` (decorative), `--input-border: #7b929e`, `--muted-foreground: #4a616b`, statuses `--on-track: #16a34a`, `--at-risk: #d47406`, `--off-track: #dc2626`. Fonts: Fira Sans Condensed 600 for headings (tracking -0.04em), Red Hat Mono for body/UI. Scale 12/13/15/16/24/32/40 (body 16px; 13px only for table meta). Radius 11px cards, 999px buttons. Shadows `0 20px 60px rgb(10 40 51 / .12)` on hero mockups only. Motion 200ms ease; tab crossfade 400ms.

### Components & interactions
TopBar, BrowserFrame, TabShowcase (playing/paused), GoalsTreeTable (expanded/collapsed, hover, empty cycle), ProgressBar (color by status), StatusBadge, OwnerAvatar, CycleSwitcher, FilterMenu, CheckInCard (idle/submitting/success/error), ActivityItem, TrendChart, ReportCard. Check-ins recalculate KR progress and objective average; status derived from progress vs. time elapsed in cycle.

### Data & state
`workspaces`, `members(role: owner|admin|member)`, `objectives`, `key_results`, `check_ins`. Server state via TanStack Query; filter state in URL params. Demo mode seeds 4 objectives × 3 KRs with fictional owners and 6 weeks of check-ins.

### Accessibility
Status is never color-only: include text labels ("On track"). Progress bars use `role="progressbar"` with values. Tree table rows are expandable with `aria-expanded` and keyboard (Left/Right). The auto-rotating showcase has a visible pause, stops on focus/hover and under reduced motion. Monospace body at 16px/1.6 (15px allowed only inside dense tables), no text below 12px; teal on white is 5.7:1. Verified contrast: body text #0a2833 on #f4f6f7 = 14.2:1; muted text #4a616b on #f4f6f7 = 6.0:1; teal link text #0f6e92 on #ffffff = 5.7:1; white #ffffff on #0f6e92 = 5.7:1; white text #ffffff on #1a7aa0 = 4.8:1.

### Security
RLS: all tables scoped by `workspace_id` where the user is a member; only owner/admin can create/delete objectives; members may only insert check-ins for KRs they own. zod validation on forms and DB check constraints (target ≠ start, progress 0–100). Google OAuth redirect URLs whitelisted. Invite tokens single-use and expiring.

### Performance & SEO
Code-split landing vs app; serve UI mockups as responsive WebP with explicit sizes. Meta/OG on landing; `noindex` app. Lighthouse 90+.

### Guardrails
- Original copy; fictional teams and people only.
- No fake customer quotes.
- Keep check-in notes private to the workspace.
- Typed small components, no `any`, visible error states.
- Done when: a user signs in, creates an objective with 2 KRs, posts a check-in that updates progress and status, filters by owner, sees reports change, and a non-member cannot read the workspace.

Open the builderAll templatesThis palette on its own