Generates a comprehensive, project-specific pre-launch checklist covering every category a designer should verify before going live. Not a generic list it's tailored to the specific project's tech stack, features, and requirements.
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" noteRuns a performance-focused analysis of the built site and produces actionable optimization recommendations. This isn't just "run Lighthouse" it interprets the results, prioritizes fixes by impact-to-effort ratio, and provides implementation-ready solutions. Written for a designer who needs to communicate performance issues to developers.
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.
Systematically checks a built design against its intended specification across browsers, devices, and edge cases. This is the designer's QA not functional testing, but visual fidelity and interaction quality. Produces a categorized issue list with exact reproduction steps and suggested fixes
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
Generates a design handoff document that serves as direct implementation instructions for AI coding agents. Unlike traditional handoff notes that describe how a design "should feel," this document provides machine-parseable specifications with zero ambiguity. Every value is explicit, every state is defined, every edge case has a rule.
1# Design Handoff Notes — AI-First, Human-Readable23### A structured handoff document optimized for AI implementation agents (Claude Code, Cursor, Copilot) while remaining clear for human developers45---67## About This Prompt89**Description:** Generates a design handoff document that serves as direct implementation instructions for AI coding agents. Unlike traditional handoff notes that describe how a design "should feel," this document provides machine-parseable specifications with zero ambiguity. Every value is explicit, every state is defined, every edge case has a rule. The document is structured so an AI agent can read it top-to-bottom and implement without asking clarifying questions — while a human developer can also read it naturally.10...+586 more lines
Use this prompt periodically (monthly, or after major feature additions) to keep the CLAUDE.md in sync with the actual codebase. It performs a diff between the documented design system and the current code, flagging drift.
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)
Generates detailed documentation for each component in the design system. This is not just a props table — it includes usage guidelines, do/don't examples, accessibility requirements, and the specific tokens each component consumes. The output becomes the component section of the CLAUDE.md.
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.
Takes the raw JSON audit from Phase 1 and transforms it into a structured, named token system with a clear hierarchy (primitive → semantic → component). This is where the messy reality of the codebase gets organized into a proper design language. Claude will also flag what to rename, merge, or deprecate.
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.
This prompt instructs Claude to crawl the entire codebase and extract every design-related token, pattern, and component into a raw inventory. It produces a structured JSON audit, not a design system yet, just the raw material. Run this first before any organization or documentation happens. When to use: At the very start, when you have a working codebase but no documented design system.
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.This prompt will help you to refine and polish over the design iteration.
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.
This prompt will help you to build your web site page by page after the kick starter prompt
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.
A prompt to kick start a web design project. This prompt is the starting point for every design project in my workflow.
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.