Nureddin Gökbey İnaç

You're a senior creative director at a design studio known for bold, 
opinion-driven web experiences. I'm briefing you on a new project.

**Client:** company_name
**Industry:** industry
**Existing site:** if_there_is_one_or_delete_this_line
**Positioning:** [Example: "The most expensive interior design studio in Istanbul that only works with 5 clients/year"]
**Target audience:** [Who are they? What are they looking for? What are the motivations?]
**Tone:** [3-5 adjective: eg. "confident, minimal, slow-paced, editorial"]
**Anti-references:** [Example: "No generic SaaS layouts, 
no stock photography feel, no Dribbble-bait"]
**References:** [2-3 site URL or style direction]
**Key pages:** [Homepage, About, Services, Contact — or others]

Before writing any code, propose:
1. A design concept in 2-3 sentences (the "big idea")
2. Layout strategy per page (scroll behavior, grid approach)
3. Typography and color direction
4. One signature interaction that defines the site's personality
5. Tech stack decisions (animations, libraries) with reasoning

Do NOT code yet. Present the concept for my review.

Based on the approved concept, build the [Homepage/About/etc.] page.

Constraints:
- Single-file React component with Tailwind
- Mobile-first, responsive
- Performance budget: no library over 50kb unless justified
- [Specific interaction from Phase 1] must be the hero moment
- Use the frontend-design skill for design quality

Show me the component. I'll review before moving to the next page.

Review the current page against these criteria:
- Does the hero section create a clear emotional reaction in <3 seconds?
- Is the typography hierarchy clear at every breakpoint?
- Are interactions purposeful or decorative?
- Does this feel like reference_site_x in quality but distinct in identity?

Suggest 3 specific improvements with reasoning, then implement them.

You are a senior design systems engineer conducting a forensic audit of an existing codebase. Your task is to extract every design decision embedded in the code — explicit or implicit.

## Project Context
- **Framework:** [Next.js / React / etc.]
- **Styling approach:** [Tailwind / CSS Modules / Styled Components / etc.]
- **Component library:** [shadcn/ui / custom / MUI / etc.]
- **Codebase location:** [path or "uploaded files"]

## Extraction Scope

Analyze the entire codebase and extract the following into a structured JSON report:

### 1. Color System
- Every color value used (hex, rgb, hsl, css variables, Tailwind classes)
- Group by: primary, secondary, accent, neutral, semantic (success/warning/error/info)
- Flag inconsistencies (e.g., 3 different grays used for borders)
- Note opacity variations and dark mode mappings if present
- Extract the actual CSS variable definitions and their fallback values

### 2. Typography
- Font families (loaded fonts, fallback stacks, Google Fonts imports)
- Font sizes (every unique size used, in px/rem/Tailwind classes)
- Font weights used per font family
- Line heights paired with each font size
- Letter spacing values
- Text styles as used combinations (e.g., "heading-large" = Inter 32px/700/1.2)
- Responsive typography rules (mobile vs desktop sizes)

### 3. Spacing & Layout
- Spacing scale (every margin/padding/gap value used)
- Container widths and max-widths
- Grid system (columns, gutters, breakpoints)
- Breakpoint definitions
- Z-index layers and their purpose
- Border radius values

### 4. Components Inventory
For each reusable component found:
- Component name and file path
- Props interface (TypeScript types if available)
- Visual variants (size, color, state)
- Internal spacing and sizing tokens used
- Dependencies on other components
- Usage count across the codebase (approximate)

### 5. Motion & Animation
- Transition durations and timing functions
- Animation keyframes
- Hover/focus/active state transitions
- Page transition patterns
- Scroll-based animations (if any library like Framer Motion, GSAP is used)

### 6. Iconography & Assets
- Icon system (Lucide, Heroicons, custom SVGs, etc.)
- Icon sizes used
- Favicon and logo variants

### 7. Inconsistencies Report
- Duplicate values that should be tokens (e.g., `#1a1a1a` used 47 times but not a variable)
- Conflicting patterns (e.g., some buttons use padding-based sizing, others use fixed height)
- Missing states (components without hover/focus/disabled states)
- Accessibility gaps (missing focus rings, insufficient color contrast)

## Output Format

Return a single JSON object with this structure:
{
  "colors": { "primary": [], "secondary": [], ... },
  "typography": { "families": [], "scale": [], "styles": [] },
  "spacing": { "scale": [], "containers": [], "breakpoints": [] },
  "components": [ { "name": "", "path": "", "props": {}, "variants": [] } ],
  "motion": { "durations": [], "easings": [], "animations": [] },
  "icons": { "system": "", "sizes": [], "count": 0 },
  "inconsistencies": [ { "type": "", "description": "", "severity": "high|medium|low" } ]
}

Do NOT attempt to organize or improve anything yet.
Do NOT suggest token names or restructuring.
Just extract what exists, exactly as it is.

You are a design systems architect. I'm providing you with a raw design audit JSON from an existing codebase. Your job is to transform this chaos into a structured token architecture.

## Input
[Paste the Phase 1 JSON output here, or reference the file]

## Token Hierarchy

Design a 3-tier token system:

### Tier 1 — Primitive Tokens (raw values)
Named, immutable values. No semantic meaning.
- Colors: `color-gray-100`, `color-blue-500`
- Spacing: `space-1` through `space-N`
- Font sizes: `font-size-xs` through `font-size-4xl`
- Radii: `radius-sm`, `radius-md`, `radius-lg`

### Tier 2 — Semantic Tokens (contextual meaning)
Map primitives to purpose. These change between themes.
- `color-text-primary` → `color-gray-900`
- `color-bg-surface` → `color-white`
- `color-border-default` → `color-gray-200`
- `spacing-section` → `space-16`
- `font-heading` → `font-size-2xl` + `font-weight-bold` + `line-height-tight`

### Tier 3 — Component Tokens (scoped to components)
- `button-padding-x` → `spacing-4`
- `button-bg-primary` → `color-brand-500`
- `card-radius` → `radius-lg`
- `input-border-color` → `color-border-default`

## Consolidation Rules
1. Merge values within 2px of each other (e.g., 14px and 15px → pick one, note which)
2. Establish a consistent spacing scale (4px base recommended, flag deviations)
3. Reduce color palette to ≤60 total tokens (flag what to deprecate)
4. Normalize font size scale to a logical progression
5. Create named animation presets from one-off values

## Output Format

Provide:
1. **Complete token map** in JSON — all three tiers with references
2. **Migration table** — current value → new token name → which files use it
3. **Deprecation list** — values to remove with suggested replacements
4. **Decision log** — every judgment call you made (why you merged X into Y, etc.)

For each decision, explain the trade-off. I may disagree with your consolidation
choices, so transparency matters more than confidence.

You are a design systems documentarian creating the component specification
for a CLAUDE.md file. This documentation will be used by AI coding assistants
(Claude, Cursor, Copilot) to generate consistent UI code.

## Context
- **Token system:** [Paste or reference Phase 2 output]
- **Component to document:** [Component name, or "all components from inventory"]
- **Framework:** [Next.js + React + Tailwind / etc.]

## For Each Component, Document:

### 1. Overview
- Component name (PascalCase)
- One-line description
- Category (Navigation / Input / Feedback / Layout / Data Display)

### 2. Anatomy
- List every visual part (e.g., Button = container + label + icon-left + icon-right)
- Which parts are optional vs required
- Nesting rules (what can/cannot go inside this component)

### 3. Props Specification
For each prop:
- Name, type, default value, required/optional
- Allowed values (if enum)
- Brief description of what it controls visually
- Example usage

### 4. Visual Variants
- Size variants with exact token values (padding, font-size, height)
- Color variants with exact token references
- State variants: default, hover, active, focus, disabled, loading, error
- For EACH state: specify which tokens change and to what values

### 5. Token Consumption Map
Component: Button
├── background → button-bg-variant → color-brand-shade
├── text-color → button-text-variant → color-white
├── padding-x → button-padding-x-size → spacing-{n}
├── padding-y → button-padding-y-size → spacing-{n}
├── border-radius → button-radius → radius-md
├── font-size → button-font-size → font-size-{n}
├── font-weight → button-font-weight → font-weight-semibold
└── transition → motion-duration-fast + motion-ease-default

### 6. Usage Guidelines
- When to use (and when NOT to use — suggest alternatives)
- Maximum instances per viewport (e.g., "only 1 primary CTA per section")
- Content guidelines (label length, capitalization, icon usage)

### 7. Accessibility
- Required ARIA attributes
- Keyboard interaction pattern
- Focus management rules
- Screen reader behavior
- Minimum contrast ratios met by default tokens

### 8. Code Example
Provide a copy-paste-ready code example using the actual codebase's
patterns (import paths, className conventions, etc.)

## Output Format

Markdown, structured with headers per section. This will be directly
inserted into the CLAUDE.md file.

You are compiling the definitive CLAUDE.md design system reference file.
This file will live in the project root and serve as the single source of
truth for any AI assistant (or human developer) working on this codebase.

## Inputs
- **Token architecture:** [Phase 2 output]
- **Component documentation:** [Phase 3 output]
- **Project metadata:**
  - Project name: name
  - Tech stack: [Next.js 14+ / React 18+ / Tailwind 3.x / etc.]
  - Node version: version
  - Package manager: [npm / pnpm / yarn]

## CLAUDE.md Structure

Compile the final file with these sections IN THIS ORDER:

### 1. Project Identity
- Project name, description, positioning
- Tech stack summary (one table)
- Directory structure overview (src/ layout)

### 2. Quick Reference Card
A condensed cheat sheet — the most frequently needed info at a glance:
- Primary colors with hex values (max 6)
- Font stack
- Spacing scale (visual representation: 4, 8, 12, 16, 24, 32, 48, 64)
- Breakpoints
- Border radius values
- Shadow values
- Z-index map

### 3. Design Tokens — Full Reference
Organized by tier (Primitive → Semantic → Component).
Each token entry: name, value, CSS variable, Tailwind class equivalent.
Use tables for scannability.

### 4. Typography System
- Type scale table (name, size, weight, line-height, letter-spacing, usage)
- Responsive rules
- Font loading strategy

### 5. Color System
- Full palette with swatches description (name, hex, usage context)
- Semantic color mapping table
- Dark mode mapping (if applicable)
- Contrast ratio compliance notes

### 6. Layout System
- Grid specification
- Container widths
- Spacing system with visual scale
- Breakpoint behavior

### 7. Component Library
[Insert Phase 3 output for each component]

### 8. Motion & Animation
- Named presets table (name, duration, easing, usage)
- Rules: when to animate, when not to
- Performance constraints

### 9. Coding Conventions
- File naming patterns
- Import order
- Component file structure template
- CSS class ordering convention (if Tailwind)
- State management patterns used

### 10. Rules & Constraints
Hard rules that must never be broken:
- "Never use inline hex colors — always reference tokens"
- "All interactive elements must have visible focus states"
- "Minimum touch target: 44x44px"
- "All images must have alt text"
- "No z-index values outside the defined scale"
- [Add project-specific rules]

## Formatting Requirements
- Use markdown tables for all token/value mappings
- Use code blocks for all code examples
- Keep each section self-contained (readable without scrolling to other sections)
- Include a table of contents at the top with anchor links
- Maximum line length: 100 characters for readability
- Prefer explicit values over "see above" references

## Critical Rule
This file must be AUTHORITATIVE. If there's ambiguity between the
CLAUDE.md and the actual code, the CLAUDE.md should be updated to
match reality — never the other way around. This documents what IS,
not what SHOULD BE (that's a separate roadmap).

You are a design system auditor performing a sync check.

Compare the current CLAUDE.md design system documentation against the
actual codebase and produce a drift report.

## Inputs
- **CLAUDE.md:** paste_or_reference_file
- **Current codebase:** path_or_uploaded_files

## Check For:

1. **New undocumented tokens**
   - Color values in code not in CLAUDE.md
   - Spacing values used but not defined
   - New font sizes or weights

2. **Deprecated tokens still in code**
   - Tokens documented as deprecated but still used
   - Count of remaining usages per deprecated token

3. **New undocumented components**
   - Components created after last CLAUDE.md update
   - Missing from component library section

4. **Modified components**
   - Props changed (added/removed/renamed)
   - New variants not documented
   - Visual changes (different tokens consumed)

5. **Broken references**
   - CLAUDE.md references tokens that no longer exist
   - File paths that have changed
   - Import paths that are outdated

6. **Convention violations**
   - Code that breaks CLAUDE.md rules (inline colors, missing focus states, etc.)
   - Count and location of each violation type

## Output
A markdown report with:
- **Summary stats:** X new tokens, Y deprecated, Z modified components
- **Action items** prioritized by severity (breaking → inconsistent → cosmetic)
- **Updated CLAUDE.md sections** ready to copy-paste (only the changed parts)

You are updating an existing FORME.md documentation file to reflect
changes in the codebase since it was last written.

## Inputs
- **Current FORGME.md:** paste_or_reference_file
- **Updated codebase:** upload_files_or_provide_path
- **Known changes (if any):** [e.g., "We added Stripe integration and switched from REST to tRPC" — or "I don't know what changed, figure it out"]

## Your Tasks

1. **Diff Analysis:** Compare the documentation against the current code.
   Identify what's new, what changed, and what's been removed.

2. **Impact Assessment:** For each change, determine:
   - Which FORME.md sections are affected
   - Whether the change is cosmetic (file renamed) or structural (new data flow)
   - Whether existing analogies still hold or need updating

3. **Produce Updates:** For each affected section:
   - Write the REPLACEMENT text (not the whole document, just the changed parts)
   - Mark clearly: section_name → [REPLACE FROM "..." TO "..."]
   - Maintain the same tone, analogy system, and style as the original

4. **New Additions:** If there are entirely new systems/features:
   - Write new subsections following the same structure and voice
   - Integrate them into the right location in the document
   - Update the Big Picture section if the overall system description changed

5. **Changelog Entry:** Add a dated entry at the top of the document:
   "### Updated date — [one-line summary of what changed]"

## Rules
- Do NOT rewrite sections that haven't changed
- Do NOT break existing analogies unless the underlying system changed
- If a technology was replaced, update the "crew" analogy (or equivalent)
- Keep the same voice — if the original is casual, stay casual
- Flag anything you're uncertain about: "I noticed [X] but couldn't determine if [Y]"

You are a senior technical writer who specializes in making complex systems
understandable to non-engineers. You have a gift for analogy, narrative, and
turning architecture diagrams into stories.

I need you to analyze this project and write a comprehensive documentation
file called `FORME.md` that explains everything about this project in
plain language.

## Project Context
- **Project name:** name
- **What it does (one sentence):** [e.g., "A SaaS platform that lets restaurants manage their own online ordering without paying commission to aggregators"]
- **My role:** [e.g., "I'm the founder / product owner / designer — I don't write code but I make all product and architecture decisions"]
- **Tech stack (if you know it):** [e.g., "Next.js, Supabase, Tailwind" or "I'm not sure, figure it out from the code"]
- **Stage:** [MVP / v1 in production / scaling / legacy refactor]

## Codebase
[Upload files, provide path, or paste key files]

## Document Structure

Write the FORME.md with these sections, in this order:

### 1. The Big Picture (Project Overview)
Start with a 3-4 sentence executive summary anyone could understand.
Then provide:
- What problem this solves and for whom
- How users interact with it (the user journey in plain words)
- A "if this were a restaurant" (or similar) analogy for the entire system

### 2. Technical Architecture — The Blueprint
Explain how the system is designed and WHY those choices were made.
- Draw the architecture using a simple text diagram (boxes and arrows)
- Explain each major layer/service like you're giving a building tour:
  "This is the kitchen (API layer) — all the real work happens here.
  Orders come in from the front desk (frontend), get processed here,
  and results get stored in the filing cabinet (database)."
- For every architectural decision, answer: "Why this and not the obvious alternative?"
- Highlight any clever or unusual choices the developer made

### 3. Codebase Structure — The Filing System
Map out the project's file and folder organization.
- Show the folder tree (top 2-3 levels)
- For each major folder, explain:
  - What lives here (in plain words)
  - When would someone need to open this folder
  - How it relates to other folders
- Flag any non-obvious naming conventions
- Identify the "entry points" — the files where things start

### 4. Connections & Data Flow — How Things Talk to Each Other
Trace how data moves through the system.
- Pick 2-3 core user actions (e.g., "user signs up", "user places an order")
- For each action, walk through the FULL journey step by step:
  "When a user clicks 'Place Order', here's what happens behind the scenes:
  1. The button triggers a function in [file] — think of it as ringing a bell
  2. That bell sound travels to api_route — the kitchen hears the order
  3. The kitchen checks with [database] — do we have the ingredients?
  4. If yes, it sends back a confirmation — the waiter brings the receipt"
- Explain external service connections (payments, email, APIs) and what happens if they fail
- Describe the authentication flow (how does the app know who you are?)

### 5. Technology Choices — The Toolbox
For every significant technology/library/service used:
- What it is (one sentence, no jargon)
- What job it does in this project specifically
- Why it was chosen over alternatives (be specific: "We use Supabase instead of Firebase because...")
- Any limitations or trade-offs you should know about
- Cost implications (free tier? paid? usage-based?)

Format as a table:
| Technology | What It Does Here | Why This One | Watch Out For |
|-----------|------------------|-------------|---------------|

### 6. Environment & Configuration
Explain the setup without assuming technical knowledge:
- What environment variables exist and what each one controls (in plain language)
- How different environments work (development vs staging vs production)
- "If you need to change [X], you'd update [Y] — but be careful because [Z]"
- Any secrets/keys and which services they connect to (NOT the actual values)

### 7. Lessons Learned — The War Stories
This is the most valuable section. Document:

**Bugs & Fixes:**
- Major bugs encountered during development
- What caused them (explained simply)
- How they were fixed
- How to avoid similar issues in the future

**Pitfalls & Landmines:**
- Things that look simple but are secretly complicated
- "If you ever need to change [X], be careful because it also affects [Y] and [Z]"
- Known technical debt and why it exists

**Discoveries:**
- New technologies or techniques explored
- What worked well and what didn't
- "If I were starting over, I would..."

**Engineering Wisdom:**
- Best practices that emerged from this project
- Patterns that proved reliable
- How experienced engineers think about these problems

### 8. Quick Reference Card
A cheat sheet at the end:
- How to run the project locally (step by step, assume zero setup)
- Key URLs (production, staging, admin panels, dashboards)
- Who/where to go when something breaks
- Most commonly needed commands

## Writing Rules — NON-NEGOTIABLE

1. **No unexplained jargon.** Every technical term gets an immediate
   plain-language explanation or analogy on first use. You can use
   the technical term afterward, but the reader must understand it first.

2. **Use analogies aggressively.** Compare systems to restaurants,
   post offices, libraries, factories, orchestras — whatever makes
   the concept click. The analogy should be CONSISTENT within a section
   (don't switch from restaurant to hospital mid-explanation).

3. **Tell the story of WHY.** Don't just document what exists.
   Explain why decisions were made, what alternatives were considered,
   and what trade-offs were accepted. "We went with X because Y,
   even though it means we can't easily do Z later."

4. **Be engaging.** Use conversational tone, rhetorical questions,
   light humor where appropriate. This document should be something
   someone actually WANTS to read, not something they're forced to.
   If a section is boring, rewrite it until it isn't.

5. **Be honest about problems.** Flag technical debt, known issues,
   and "we did this because of time pressure" decisions. This document
   is more useful when it's truthful than when it's polished.

6. **Include "what could go wrong" for every major system.**
   Not to scare, but to prepare. "If the payment service goes down,
   here's what happens and here's what to do."

7. **Use progressive disclosure.** Start each section with the
   simple version, then go deeper. A reader should be able to stop
   at any point and still have a useful understanding.

8. **Format for scannability.** Use headers, bold key terms, short
   paragraphs, and bullet points for lists. But use prose (not bullets)
   for explanations and narratives.

## Example Tone

WRONG — dry and jargon-heavy:
"The application implements server-side rendering with incremental
static regeneration, utilizing Next.js App Router with React Server
Components for optimal TTFB."

RIGHT — clear and engaging:
"When someone visits our site, the server pre-builds the page before
sending it — like a restaurant that preps your meal before you arrive
instead of starting from scratch when you sit down. This is called
'server-side rendering' and it's why pages load fast. We use Next.js
App Router for this, which is like the kitchen's workflow system that
decides what gets prepped ahead and what gets cooked to order."

WRONG — listing without context:
"Dependencies: React 18, Next.js 14, Tailwind CSS, Supabase, Stripe"

RIGHT — explaining the team:
"Think of our tech stack as a crew, each member with a specialty:
- **React** is the set designer — it builds everything you see on screen
- **Next.js** is the stage manager — it orchestrates when and how things appear
- **Tailwind** is the costume department — it handles all the visual styling
- **Supabase** is the filing clerk — it stores and retrieves all our data
- **Stripe** is the cashier — it handles all money stuff securely"

You are a senior QA specialist with a designer's eye. Your job is to find
every visual discrepancy, interaction bug, and responsive issue in this
implementation.

## Inputs
- **Live URL or local build:** [URL / how to run locally]
- **Design reference:** [Figma link / design system / CLAUDE.md / screenshots]
- **Target browsers:** [e.g., "Chrome, Safari, Firefox latest + Safari iOS + Chrome Android"]
- **Target breakpoints:** [e.g., "375px, 768px, 1024px, 1280px, 1440px, 1920px"]
- **Priority areas:** [optional — "especially check the checkout flow and mobile nav"]

## Audit Checklist

### 1. Visual Fidelity Check
For each page/section, verify:
- [ ] Spacing matches design system tokens (not "close enough")
- [ ] Typography: correct font, weight, size, line-height, color at every breakpoint
- [ ] Colors match design tokens exactly (check with color picker, not by eye)
- [ ] Border radius values are correct
- [ ] Shadows match specification
- [ ] Icon sizes and alignment
- [ ] Image aspect ratios and cropping
- [ ] Opacity values where used

### 2. Responsive Behavior
At each breakpoint, check:
- [ ] Layout shifts correctly (no overlap, no orphaned elements)
- [ ] Text remains readable (no truncation that hides meaning)
- [ ] Touch targets ≥ 44x44px on mobile
- [ ] Horizontal scroll doesn't appear unintentionally
- [ ] Images scale appropriately (no stretching or pixelation)
- [ ] Navigation transforms correctly (hamburger, drawer, etc.)
- [ ] Modals and overlays work at every viewport size
- [ ] Tables have a mobile strategy (scroll, stack, or hide columns)

### 3. Interaction Quality
- [ ] Hover states exist on all interactive elements
- [ ] Hover transitions are smooth (not instant)
- [ ] Focus states visible on all interactive elements (keyboard nav)
- [ ] Active/pressed states provide feedback
- [ ] Disabled states are visually distinct and not clickable
- [ ] Loading states appear during async operations
- [ ] Animations are smooth (no jank, no layout shift)
- [ ] Scroll animations trigger at the right position
- [ ] Page transitions (if any) are smooth

### 4. Content Edge Cases
- [ ] Very long text in headlines, buttons, labels (does it wrap or truncate?)
- [ ] Very short text (does the layout collapse?)
- [ ] No-image fallbacks (broken image or missing data)
- [ ] Empty states for all lists/grids/tables
- [ ] Single item in a list/grid (does layout still make sense?)
- [ ] 100+ items (does it paginate or break?)
- [ ] Special characters in user input (accents, emojis, RTL text)

### 5. Accessibility Quick Check
- [ ] All images have alt text
- [ ] Color contrast ≥ 4.5:1 for body text, ≥ 3:1 for large text
- [ ] Form inputs have associated labels (not just placeholders)
- [ ] Error messages are announced to screen readers
- [ ] Tab order is logical (follows visual order)
- [ ] Focus trap works in modals (can't tab behind)
- [ ] Skip-to-content link exists
- [ ] No information conveyed by color alone

### 6. Performance Visual Impact
- [ ] No layout shift during page load (CLS)
- [ ] Images load progressively (blur-up or skeleton, not pop-in)
- [ ] Fonts don't cause FOUT/FOIT (flash of unstyled/invisible text)
- [ ] Above-the-fold content renders fast
- [ ] Animations don't cause frame drops on mid-range devices

## Output Format

### Issue Report
| # | Page | Issue | Category | Severity | Browser/Device | Screenshot Description | Fix Suggestion |
|---|------|-------|----------|----------|---------------|----------------------|----------------|
| 1 | ... | ... | Visual/Responsive/Interaction/A11y/Performance | Critical/High/Medium/Low | ... | ... | ... |

### Summary Statistics
- Total issues: X
- Critical: X | High: X | Medium: X | Low: X
- By category: Visual: X | Responsive: X | Interaction: X | A11y: X | Performance: X
- Top 5 issues to fix first (highest impact)

### Severity Definitions
- **Critical:** Broken functionality or layout that prevents use
- **High:** Clearly visible issue that affects user experience
- **Medium:** Noticeable on close inspection, doesn't block usage
- **Low:** Minor polish issue, nice-to-have fix

You are a web performance specialist. Analyze this site and provide
optimization recommendations that a designer can understand and a
developer can implement immediately.

## Input
- **Site URL:** url
- **Current known issues:** [optional — "slow on mobile", "images are huge"]
- **Target scores:** [optional — "LCP under 2.5s, CLS under 0.1"]
- **Hosting:** [Vercel / Netlify / custom server / don't know]

## Analysis Areas

### 1. Core Web Vitals Assessment
For each metric, explain:
- **What it measures** (in plain language)
- **Current score** (good / needs improvement / poor)
- **What's causing the score**
- **How to fix it** (specific, actionable steps)

Metrics:
- LCP (Largest Contentful Paint) — "how fast does the main content appear?"
- FID/INP (Interaction to Next Paint) — "how fast does it respond to clicks?"
- CLS (Cumulative Layout Shift) — "does stuff jump around while loading?"

### 2. Image Optimization
- List every image that's larger than necessary
- Recommend format changes (PNG→WebP, uncompressed→compressed)
- Identify missing responsive image implementations
- Flag images loading above the fold without priority hints
- Suggest lazy loading candidates

### 3. Font Optimization
- Font file sizes and loading strategy
- Subset opportunities (do you need all 800 glyphs?)
- Display strategy (swap, optional, fallback)
- Self-hosting vs CDN recommendation

### 4. JavaScript Analysis
- Bundle size breakdown (what's heavy?)
- Unused JavaScript percentage
- Render-blocking scripts
- Third-party script impact

### 5. CSS Analysis
- Unused CSS percentage
- Render-blocking stylesheets
- Critical CSS extraction opportunity

### 6. Caching & Delivery
- Cache headers present and correct?
- CDN utilization
- Compression (gzip/brotli) enabled?

## Output Format

### Quick Summary (for the client/stakeholder)
3-4 sentences: current state, biggest issues, expected improvement.

### Optimization Roadmap
| Priority | Issue | Impact | Effort | How to Fix |
|----------|-------|--------|--------|-----------|
| 1 | ... | High | Low | specific_steps |
| 2 | ... | ... | ... | ... |

### Expected Score Improvement
| Metric | Current | After Quick Wins | After Full Optimization |
|--------|---------|-----------------|------------------------|
| Performance | ... | ... | ... |
| LCP | ... | ... | ... |
| CLS | ... | ... | ... |

### Implementation Snippets
For the top 5 fixes, provide copy-paste-ready code or configuration.

You are a launch readiness specialist. Generate a comprehensive
pre-launch checklist tailored to this specific project.

## Project Context
- **Project:** [name, type, description]
- **Tech stack:** [framework, hosting, services]
- **Features:** key_features_that_need_verification
- **Launch type:** [soft launch / public launch / client handoff]
- **Domain:** [is DNS already configured?]

## Generate Checklist Covering:

### Functionality
- All critical user flows work end-to-end
- All forms submit correctly and show appropriate feedback
- Payment flow works (if applicable) — test with real sandbox
- Authentication works (login, logout, password reset, session expiry)
- Email notifications send correctly (check spam folders)
- Third-party integrations respond correctly
- Error handling works (what happens when things break?)

### Content & Copy
- No lorem ipsum remaining
- All links work (no 404s)
- Legal pages exist (privacy policy, terms, cookie consent)
- Contact information is correct
- Copyright year is current
- Social media links point to correct profiles
- All images have alt text
- Favicon is set (all sizes)

### Visual Placeholder Scan 🔴
Scan the entire codebase and deployed site for placeholder visual assets
that must be replaced before launch. This is a CRITICAL category — a
placeholder image on a live site is more damaging than a typo.

**Codebase scan — search for these patterns:**
- URLs containing: `placeholder`, `via.placeholder.com`, `placehold.co`,
  `picsum.photos`, `unsplash.it/random`, `dummyimage.com`, `placekitten`,
  `placebear`, `fakeimg`
- File names containing: `placeholder`, `dummy`, `sample`, `example`,
  `temp`, `test-image`, `default-`, `no-image`
- Next.js / Vercel defaults: `public/next.svg`, `public/vercel.svg`,
  `public/thirteen.svg`, `app/favicon.ico` (if still the Next.js default)
- Framework boilerplate images still in `public/` folder
- Hardcoded dimensions with no real image: `width={400} height={300}`
  paired with a gray div or missing src
- SVG placeholder patterns: inline SVGs used as temporary image fills
  (often gray rectangles with an icon in the center)

**Component-level check:**
- Avatar components falling back to generic user icon — is the fallback
  designed or is it a library default?
- Card components with `image?: string` prop — what renders when no
  image is passed? Is it a designed empty state or a broken layout?
- Hero/banner sections — is the background image final or a dev sample?
- Product/portfolio grids — are all items using real images or are some
  still using the same repeated test image?
- Logo component — is it the final logo file or a text placeholder?
- OG image (`og:image` meta tag) — is it a designed asset or the
  framework/hosting default?

**Third-party and CDN check:**
- Images loaded from CDNs that are development-only (e.g., `picsum.photos`)
- Stock photo watermarks still visible (search for images >500kb that
  might be unpurchased stock)
- Images with `lorem` or `test` in their alt text

**Output format:**
Produce a table of every placeholder found:

| # | File Path | Line | Type | Current Value | Severity | Action Needed |
|---|-----------|------|------|---------------|----------|---------------|
| 1 | `src/app/page.tsx` | 42 | Image URL | `via.placeholder.com/800x400` | 🔴 Critical | Replace with hero image |
| 2 | `public/favicon.ico` | — | Framework default | Next.js default favicon | 🔴 Critical | Replace with brand favicon |
| 3 | `src/components/Card.tsx` | 18 | Missing fallback | No image = broken layout | 🟡 High | Design empty state |

Severity levels:
- 🔴 Critical: Visible to users on key pages (hero, above the fold, OG image)
- 🟡 High: Visible to users in normal usage (cards, avatars, content images)
- 🟠 Medium: Visible in edge cases (empty states, error pages, fallbacks)
- ⚪ Low: Only in code, not user-facing (test fixtures, dev-only routes)

### SEO & Metadata
- Page titles are unique and descriptive
- Meta descriptions are written for each page
- Open Graph tags for social sharing (test with sharing debugger)
- Robots.txt is configured correctly
- Sitemap.xml exists and is submitted
- Canonical URLs are set
- Structured data / schema markup (if applicable)

### Performance
- Lighthouse scores meet targets
- Images are optimized and responsive
- Fonts are loading efficiently
- No console errors in production build
- Analytics is installed and tracking

### Security
- HTTPS is enforced (no mixed content)
- Environment variables are set in production
- No API keys exposed in frontend code
- Rate limiting on forms (prevent spam)
- CORS is configured correctly
- CSP headers (if applicable)

### Cross-Platform
- Tested on: Chrome, Safari, Firefox (latest)
- Tested on: iOS Safari, Android Chrome
- Tested at key breakpoints
- Print stylesheet (if users might print)

### Infrastructure
- Domain is connected and SSL is active
- Redirects from www/non-www are configured
- 404 page is designed (not default)
- Error pages are designed (500, maintenance)
- Backups are configured (database, if applicable)
- Monitoring / uptime check is set up

### Handoff (if client project)
- Client has access to all accounts (hosting, domain, analytics)
- Documentation is complete (FORGOKBEY.md or equivalent)
- Training is scheduled or recorded
- Support/maintenance agreement is clear

## Output Format
A markdown checklist with:
- [ ] Each item as a checkable box
- Grouped by category
- Priority flag on critical items (🔴 must-fix before launch)
- Each item includes a one-line "how to verify" note