{/* screenshot, demo component, or illustration */}
```
---
## Step 7 — Demo Sections
For any demo, invoke the `demo-animations` skill.
Every demo must:
1. Show a real user message → GAIA doing work → a meaningful result
2. Use real product components (`DemoCalendarView`, `DemoTodosView`, etc.) with realistic dummy data — never recreate them
3. Follow the phase state machine: `idle → user_sent → thinking → loading → tool_calls → responding → complete`
4. Use timing from `demoConstants.ts`: userMsg 500ms, thinking 900ms, toolCalls 4600ms, loop 14000ms
5. Loop automatically
Demo chrome (makes it look like a real product, not a mockup):
```tsx
{/* messages and result cards */}
```
Realistic dummy data rules:
- Task names that sound like real work ("Draft investor update email", not "Task 1")
- Tool calls that match GAIA's actual capabilities (Gmail, Calendar, Notion, Linear)
- Bot responses that read like GAIA actually wrote them, not placeholder text
---
## Step 8 — File Organization
```
apps/web/src/app/(landing)/[page-name]/page.tsx ← server component + metadata
apps/web/src/features/landing/components/[page-name]/ ← page-specific components
```
`page.tsx` always exports metadata:
```tsx
import { generatePageMetadata } from "@/lib/seo/metadata";
export const metadata = generatePageMetadata({
title: "[Title] — GAIA",
description: "[SEO description from copy]",
path: "/[page-name]",
});
export default function PageName() {
return ...;
}
```
Split into a separate component file when a section exceeds ~150 lines or is reusable elsewhere.
---
## Step 9 — Quality Gate
Do not mark done until every item passes.
**Copy**
- [ ] No placeholder text anywhere in the page
- [ ] Headline answers "what will I get?" not "what is this?"
- [ ] Every feature described as an outcome for the user, not a system capability
- [ ] Single primary CTA — GetStartedButton. Secondary actions are links, not buttons.
**Design**
- [ ] Hero has a wallpaper background, not a solid color
- [ ] FinalSection used at the very bottom of every page
- [ ] All section titles use LargeHeader or match its exact pattern
- [ ] Zero `border-` `ring-` `outline-` `shadow-` classes on any card
- [ ] All serif headings are `font-normal`, never `font-bold`
- [ ] Accent `#00bbff` used for chips, icon tint backgrounds, active states
**Animations**
- [ ] Hero uses SplitTextBlur
- [ ] Every section uses scroll-triggered `whileInView` entrance
- [ ] Easing is `[0.32, 0.72, 0, 1]` — not `ease-in-out`, not linear
- [ ] Demo loops automatically with a reset phase
- [ ] AnimatePresence wraps conditional content with `mode="wait"` and stable keys
**Technical**
- [ ] `"use client"` only on components that use browser APIs or hooks
- [ ] No `any` types
- [ ] All imports at the top of every file
- [ ] Mobile layout verified at 375px — hero text readable, no horizontal overflow, CTAs full-width
- [ ] `nx run-many -t lint type-check` passes clean
---
## What Separates Good Pages From Mediocre Ones
**Narrative arc matters more than aesthetics.** The page must tell a story: agitate the pain → introduce hope → prove it works → make acting easy. A list of features is not a story and will not convert.
**Specificity converts. Vagueness doesn't.**
- Bad: "Saves you time"
- Good: "Clears your Monday morning inbox in under 5 minutes"
Use the audience's exact language. Developer pages: "PRs", "deploys", "standups". Sales pages: "pipeline", "follow-ups", "quota".
**The demo is the proof.** If it looks fake, it destroys trust. Real component names, real-sounding tasks, actual tool names. Fake data is worse than no demo.
**Social proof placement.** One strong quote directly under the hero outperforms a full testimonials section at the bottom. Put proof where skepticism lives — near the CTA, not at the end.
**Mobile first.** Test at 375px before anything else. Most visitors are mobile.
