Bramblecast

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

Open Sans has the plain, system-font feel of an engineering checklist and a true 800 for the hero, so the page reads as organised rather than salesy.

• Open SansHeadings: hero 60px 800 at -0.025em, feature titles 18px 700
• Open SansBody: intro 20px/1.5 400, descriptions 16px/1.5

Patterns

• centred hero with two-button CTA pair (solid + outline)
• icon-over-title feature grid, three columns
• single-page tooling manifest
• stacked single-column feature list on mobile
• health-check endpoint surfaced as a status line
• generous whitespace, no navigation chrome

States it is designed for

• 404 page with a link back home
• Runtime error boundary with a 'Try again' action
• Health endpoint degraded (dependency check failed) returns 503 and the status strip turns amber
• Long feature titles wrap to two lines without breaking grid alignment
• JavaScript disabled: page remains fully readable (server-rendered)

Who it is for

• engineering teams starting a long-lived product
• tech leads standardising a stack
• agencies delivering maintainable client apps

Layout

1. No header navigation; page opens straight into the hero
2. Hero: centred 60px heavy headline over two lines, 20px muted intro paragraph capped at ~36rem, button pair (solid primary, outline secondary)
3. Feature grid: 3 columns x 7 rows of centred items: small line icon in the accent colour, bold 18px title, one-line muted description
4. Optional status strip: build version, commit, health endpoint result
5. Minimal footer: repository link, licence line placeholder
6. Tablet: 2 columns; mobile (<640px): single column, headline 40px, buttons side by side at full tap size

Palette

Clean, neutral, engineering-first. The page reads like a well-organised checklist rather than a sales pitch.

• page background#ffffff
• headline / title text#000000
• muted body text#6a7282
• icon accent#1447e6
• primary button fill#0070f2
• outline button border / text#0070f2
• focus ring#3a96ff
• hairline divider (decorative)#e5e7eb
• status ok#15803d

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

Open Sans 800, 60px/1.0 hero with -0.025em tracking; feature titles Open Sans 700 18px

Body

Open Sans 400, 20px intro (observed weight 300; raised to 400 because light weights are only allowed at 24px+), 16px descriptions at line-height 1.5

System-font feel; Open Sans stands in for it. No uppercase labels.

Spacing and imagery

Airy: hero padding 96px top; grid gap 48px vertical, 32px horizontal; container max 1024px centred. Radius 12px on buttons; no cards or borders around grid items. No shadows.

Only 20px outline icons in a single accent blue; no photos or illustrations.

Components

• Hero with headline, intro and CTA pair
• FeatureItem (icon, title, description)
• FeatureGrid driven by a typed data file
• Button with variants (solid, outline) built on a class-variance utility
• Health endpoint `/api/health` returning JSON
• Custom 404 and error boundary pages
• Component workshop stories for each primitive

Interactions

• Buttons darken 8% on hover and show a 2px focus ring offset by 2px
• Feature icons do not animate; optional fade-up on first paint disabled under reduced motion
• Outline button fills with a 6% tint on hover
• Anchor from 'Get started' scrolls to a setup steps section

Data

• Feature{id, title, description (<= 90 chars), icon (lucide name), docsHref?}
• HealthStatus{status (ok|degraded|down), version, commit, checkedAt, checks[{name, ok}]}

Guardrails

Experience

• Keep the hero to one headline, one paragraph and two buttons
• Every feature item follows the same icon-title-description rhythm; no mixed card styles
• Order features by developer workflow: build, quality, testing, delivery, operations
• Descriptions stay to one sentence under 90 characters
• The secondary button must look secondary (outline) and never compete with the primary

Accessibility

• Primary button uses #0070f2 so the white label reaches 4.57:1 (the observed lighter blue failed)
• Muted text #6a7282 reaches 4.84:1 on white; do not lighten it further
• Feature titles are h3 under a visually hidden h2 'Included tooling' to keep a valid outline
• Icons are decorative (aria-hidden); meaning lives in the title text
• Intro text uses weight 400, not 300

Security

• Ship strict security headers (CSP with nonces, frame-ancestors none, referrer-policy strict-origin-when-cross-origin)
• Validate environment variables at boot with zod and fail fast; never expose server secrets with a public prefix
• Health endpoint returns no stack traces, hostnames or secrets
• Automated dependency updates run through CI with tests before merge
• Lock file committed and install uses a frozen lockfile in CI

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 **Bramblecast**, a production-grade web app boilerplate for teams who expect their codebase to live for years. The repository comes with strict typing, linting and formatting, unit and end-to-end tests, a component workshop, conventional commits, dependency automation, observability hooks and health checks. Its single public screen is a tidy showcase that lists every included capability, so a new teammate can see what is wired up at a glance.

### Stack
Next.js (App Router) + React + TypeScript in strict mode with extra type-safety resets, Tailwind CSS, Radix primitives via shadcn/ui, a class-variance utility for component variants, lucide-react icons and zod for environment validation. Include a unit test runner with a DOM testing library, an end-to-end browser test runner, a component workshop, a bundle analyser, a git hook that enforces conventional commits, semantic release for changelogs and a vendor-neutral tracing setup. Refer to these by role in docs, not by marketing names.

### Pages & layout
1. **Showcase (`/`)**: no top nav. Centred hero: a heavy two-line headline (for example "A sturdy base for serious web apps"), a muted one-paragraph intro and a button pair: solid "Get started" (scrolls to setup steps) and outline "Deploy a copy". Below, a three-column grid of 21 feature items, each a centred small line icon, bold title and one-sentence description. Then a numbered "Setup in four steps" list and a minimal footer.
2. **`/api/health`**: JSON status for load balancers and uptime checks.
3. **404 and error pages**: same typography, one sentence and a home link.
4. **Responsive**: two columns from 640px to 1024px, one column below; the hero headline scales from 60px to 40px.

### Design system
- Colors: `--bg: #ffffff`, `--fg: #000000`, `--muted: #6a7282`, `--icon: #1447e6`, `--primary: #0070f2` (fill and outline), `--focus: #3a96ff`, `--divider: #e5e7eb` (decorative), `--ok: #15803d`.
- Fonts: Open Sans (standing in for the observed system stack). Hero 800 at 60px/1.0 with -0.025em tracking; titles 700 at 18px; intro 400 at 20px/1.5; descriptions 400 at 16px/1.5.
- Spacing: 4px base; section padding 96px; grid gap 48px x 32px; container max-width 1024px.
- Radius: 12px buttons; no card containers.
- Shadows: none.
- Motion: 150ms colour transitions; optional 300ms fade-up on grid items, disabled under `prefers-reduced-motion`.

### Components & interactions
`Button` (variants: solid, outline; sizes: md, lg) with hover darken, active press and visible focus ring. `FeatureItem` and `FeatureGrid` rendered from a typed `features.ts` array. `SetupSteps` ordered list with copyable commands (copy button announces "Copied"). `StatusStrip` in the footer reading `/api/health` at build time. Every primitive has a workshop story and a unit test; the showcase has an end-to-end smoke test and an accessibility scan.

### Data & state
`Feature { id, title, description, icon, docsHref? }` stored as a constant. `HealthStatus { status: 'ok' | 'degraded' | 'down', version, commit, checkedAt, checks: { name, ok }[] }`. `env.ts` parses `process.env` with zod at startup and exports typed values; the build fails on a missing variable. No client state beyond the copy button.

### Accessibility
One h1, a visually hidden h2 "Included tooling", h3 per feature. Icons `aria-hidden`. Buttons at least 44px tall. Focus rings 2px `--focus` with 2px offset. Body text never below 16px and never weight 300. Run an automated accessibility check in the end-to-end suite and fail CI on violations.
Verified contrast: headline on white: #000000 on #ffffff = 21.0:1; muted description on white: #6a7282 on #ffffff = 4.84:1; primary button label: #ffffff on #0070f2 = 4.57:1; outline button text on white: #0070f2 on #ffffff = 4.57:1; feature icon on white: #1447e6 on #ffffff = 6.83:1; focus ring on white: #3a96ff on #ffffff = 3.01:1; status ok text on white: #15803d on #ffffff = 5.02:1.

### Security
Set a nonce-based Content Security Policy, `X-Content-Type-Options: nosniff`, `Referrer-Policy: strict-origin-when-cross-origin` and `frame-ancestors 'none'` in middleware. Only variables explicitly marked public reach the client. The health route reveals status and version only, with no hostnames or traces, and is rate-limited. CI installs from a frozen lockfile and runs tests before any automated dependency update merges.

### Performance & SEO
Statically render the showcase; ship zero client JavaScript except the copy button island. Self-host Open Sans with `font-display: swap`. Add title, meta description, canonical and an original OG image. Keep the bundle analyser in CI with a budget (first-load JS under 90 KB). Target Lighthouse 100 on the showcase.

### Guardrails
- Use original copy; do not reuse any existing boilerplate's headline or feature blurbs.
- No third-party logos in the grid; generic line icons only.
- Name tools by role in UI copy ("End-to-end tests", "Component workshop").
- Acceptance criteria:
  - [ ] Showcase renders with no client errors and passes the accessibility scan
  - [ ] `/api/health` returns 200 with version and commit, 503 when a check fails
  - [ ] Missing env var fails the build with a readable message
  - [ ] Lint, type-check, unit and end-to-end suites pass in CI
  - [ ] Layout holds at 360px, 768px and 1280px

Open the builderAll templatesThis palette on its own