Cursor rules for a Next.js + Tailwind landing page

---
description: Conventions for building and editing the Next.js + Tailwind CSS marketing landing page (App Router, TypeScript)
globs: app/**/*.tsx, app/**/*.ts, components/**/*.tsx, app/globals.css, tailwind.config.*
alwaysApply: false
---

# Next.js + Tailwind landing page rules

You are working on a single marketing landing page built with Next.js (App Router), TypeScript and Tailwind CSS.
The goal is a fast, accessible, mobile-first page that converts visitors into sign-ups. Keep it simple.

## Project facts (edit these)
- Product: [PRODUCT NAME] — [ONE-SENTENCE VALUE PROPOSITION]
- Primary call to action: [e.g. "Join the waitlist"] -> [form endpoint or URL]
- Brand colors: [primary hex], [accent hex], [background hex]
- Font: [font name, loaded with next/font]
- Package manager: [npm | pnpm | yarn | bun]
- Before you change versions or config, read package.json and the existing Tailwind setup to see which Next.js and Tailwind versions this project uses, and follow the conventions of those versions.

## Structure
- The page lives in `app/page.tsx`. Each section is its own component in `components/sections/` (Hero, Features, HowItWorks, Pricing or Social proof, FAQ, FinalCTA, Footer).
- Shared UI pieces (Button, Container, Section heading) live in `components/ui/`.
- Put all page copy in one file, `content/site.ts`, as typed constants. Components import copy from there, so text can be edited without touching layout.
- Use Server Components by default. Add `"use client"` only to components that need state, effects or browser APIs (for example a mobile menu or an FAQ accordion), and keep those components small.
- Do not add new dependencies without asking first. Prefer plain Tailwind and native HTML elements (for example `<details>` for an FAQ).

## Styling
- Use Tailwind utility classes only. Do not create CSS modules or inline `style` attributes unless a value cannot be expressed in Tailwind.
- Mobile first: write base classes for small screens, then add `sm:`, `md:` and `lg:` overrides.
- Use one consistent spacing scale for sections (for example `py-16 md:py-24`) and one container width (for example `max-w-6xl mx-auto px-4`).
- Keep colors in the Tailwind theme (or CSS variables) instead of repeating raw hex values in components.
- When classes conflict or get long, extract a component instead of building long conditional class strings.

## Performance
- Use `next/image` for every image, with explicit `width` and `height` (or `fill` plus a sized parent) and a meaningful `alt`. Mark only the hero image as `priority`.
- Load fonts with `next/font`. Do not link to external font stylesheets.
- No client-side data fetching for static content. The landing page should render fully on the server.
- Avoid heavy animation libraries. Prefer CSS transitions, and respect `prefers-reduced-motion` (use the `motion-safe:` and `motion-reduce:` variants).

## Accessibility
- One `<h1>` per page (in the Hero). Section headings use `<h2>`, in order.
- Use semantic landmarks: `<header>`, `<main>`, `<section aria-labelledby=...>`, `<footer>`.
- Every interactive element must be reachable by keyboard and have a visible focus style (`focus-visible:` classes).
- Text contrast must meet WCAG AA against its background. Do not put light gray text on white.
- Buttons that navigate are links (`<a>` / `next/link`); buttons that act are `<button type="button">`.
- Form inputs need a `<label>` (it can be visually hidden with `sr-only`).

## SEO
- Set the title, description and Open Graph data with the Metadata API (`export const metadata` in `app/layout.tsx` or `app/page.tsx`).
- Provide an Open Graph image and a favicon.
- Keep important text as real HTML text, not inside images.

## Forms and links
- The call-to-action form must show a loading state, a success message and an error message.
- Validate the email on the client for a fast hint, and again on the server if this project has a server route.
- Never commit API keys. Read secrets from environment variables, and never expose secret keys to the client (only variables prefixed with `NEXT_PUBLIC_` reach the browser, so never put secrets in those).
- External links open in a new tab only when there is a good reason, and then use `rel="noopener noreferrer"`.

## How to work
- Before editing, read the files you will change and the component they render inside.
- Make the smallest change that solves the request. Do not rewrite sections that were not mentioned.
- After a change, run the type check and the linter (`[npm run lint]`, `[npx tsc --noEmit]`) and `[npm run build]` before saying you are done. Report any errors you could not fix.
- When you are unsure about copy, leave a clear `TODO:` comment instead of inventing product claims, numbers, testimonials or customer logos.