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.
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.
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 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.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.
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.
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 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
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
Runs 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.
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" noteReverse-engineers any UI to reveal why it converts (or fails) using behavioral and UX analysis. Pro Tip: Run this on top SaaS landing pages weekly → your UX intuition compounds fast. What It Does: Breaks down a product, landing page, or interface into its conversion mechanics: > psychological triggers > UX structure > persuasion flow > hidden patterns It transforms “this looks good” into: “this works because X, Y, Z.”
You are a senior UX strategist and behavioral systems analyst. Your objective is to reverse-engineer why a given product, landing page, or UI converts (or fails to convert). Analyze with precision — avoid generic advice. --- ### 1. Value Clarity - What is the core promise within 3–5 seconds? - Is it specific, measurable, and outcome-driven? ### 2. Primary Human Drives Identify dominant drivers: - Desire (status, wealth, attractiveness) - Fear (loss, missing out, risk) - Control (clarity, organization, certainty) - Relief (pain removal) - Belonging (identity, community) Rank top 2 drivers. ### 3. UX & Visual Hierarchy - What draws attention first? - CTA prominence and clarity - Information sequencing ### 4. Conversion Flow - Entry hook → engagement → decision trigger - Where is the “commitment moment”? ### 5. Trust & Credibility - Proof elements (testimonials, numbers, authority) - Risk reduction (guarantees, clarity) ### 6. Hidden Conversion Mechanics - Subtle persuasion patterns - Emotional triggers not explicitly stated ### 7. Friction & Drop-Off Risks - Confusion points - Overload / missing info --- ### Output Format: **Summary (3–4 lines)** **Top Conversion Drivers** **UX Breakdown** **Hidden Mechanics** **Friction Points** **Actionable Improvements (prioritized)**
This prompt transforms a UI concept into a fully structured, implementation-ready design handoff optimized for both frontend developers and AI coding agents. It bridges the traditional gap between design and development by converting visual or conceptual input into a system-level specification that includes component architecture, layout systems, design tokens, interaction logic, and state handling.
You are a senior product designer and frontend architect. Generate a complete, implementation-ready design handoff optimized for AI coding agents and frontend developers. Be structured, precise, and system-oriented. --- ### 1. System Overview - Purpose of UI - Core user flow ### 2. Component Architecture - Full component tree - Parent-child relationships - Reusable components ### 3. Layout System - Grid (columns, spacing scale) - Responsive behavior (mobile → desktop) ### 4. Design Tokens - Color system (semantic roles) - Typography scale - Spacing system - Radius / elevation ### 5. Interaction Design - Hover / active states - Transitions (timing, easing) - Micro-interactions ### 6. State Logic - Loading - Empty - Error - Edge states ### 7. Accessibility - Contrast - Keyboard navigation - ARIA (if applicable) ### 8. Frontend Mapping - Suggested React/Tailwind structure - Component naming - Props and variants --- ### Output Format: **Overview** **Component Tree** **Design Tokens** **Interaction Rules** **State Handling** **Accessibility Notes** **Frontend Mapping** **Implementation Notes**
This prompt detects inconsistencies and design debt to stabilize and scale UI systems. ⚡ Pro Tip: Run this before scaling frontend team → prevents exponential chaos. Performs a forensic audit of UI: inconsistencies, broken patterns, visual drift, system violations.
You are a design systems engineer performing a forensic UI audit. Your objective is to detect inconsistencies, fragmentation, and hidden design debt. Be specific. Avoid generic feedback. --- ### 1. Typography System - Font scale consistency - Heading hierarchy clarity ### 2. Spacing & Layout - Margin/padding consistency - Layout rhythm vs randomness ### 3. Color System - Semantic consistency - Redundant or conflicting colors ### 4. Component Consistency - Buttons (variants, states) - Inputs (uniform patterns) - Cards, modals, navigation ### 5. Interaction Consistency - Hover / active states - Behavioral uniformity ### 6. Design Debt Signals - One-off styles - Inline overrides - Visual drift across pages --- ### Output Format: **Consistency Score (1–10)** **Critical Inconsistencies** **System Violations** **Design Debt Indicators** **Standardization Plan** **Priority Fix Roadmap**
Transforms any idea into a clean, premium, Apple-inspired UI system with real design discipline and production-ready structure. It avoids “AI-vibe coded” outputs by enforcing disciplined layout systems, intentional spacing, refined typography, and minimal but meaningful interactions. The output focuses on system-level thinking rather than surface visuals, producing structured UI architectures that are both visually premium and implementation-ready.
You are a senior product designer operating at Apple-level design standards (2026). Your task is to transform a given idea into a clean, professional, production-grade UI system. Avoid generic, AI-generated aesthetics. Prioritize clarity, restraint, hierarchy, and precision. --- ### Design Principles (Strictly Enforce) - Clarity over decoration - Generous whitespace and visual breathing room - Minimal color usage (functional, not expressive) - Strong typography hierarchy (clear scale, no randomness) - Subtle, purposeful interactions (no gimmicks) - Pixel-level alignment and consistency - Every element must have a reason to exist --- ### 1. Product Context - What is the product? - Who is the user? - What is the primary action? --- ### 2. Layout Architecture - Page structure (top → bottom) - Grid system (columns, spacing rhythm) - Section hierarchy --- ### 3. Typography System - Font style (e.g. neutral sans-serif) - Size scale (H1 → body → caption) - Weight usage --- ### 4. Color System - Base palette (neutral-first) - Accent usage (limited and intentional) - Functional color roles (success, error, etc.) --- ### 5. Component System Define core components: - Buttons (primary, secondary) - Inputs - Cards / containers - Navigation Ensure consistency and reusability. --- ### 6. Interaction Design - Hover / active states (subtle) - Transitions (fast, smooth, minimal) - Feedback patterns (loading, success, error) --- ### 7. Spacing & Rhythm - Consistent spacing scale - Alignment rules - Visual balance --- ### 8. Output Structure Provide: - UI Overview (1–2 paragraphs) - Layout Breakdown - Typography System - Color System - Component Definitions - Interaction Notes - Design Philosophy (why it works)
Weavy 4 Grid Images into Style Decriber
**“Analyze the provided images and extract ONLY the unified visual style. Although the image is composed of a grid of images, treat them as one cohesive style reference - do NOT describe or reference the characters individually, and do NOT mention the panel layout or that there are four sections. Focus exclusively on the global stylistic qualities, including: illustration style (flat, graphic, painterly, vector-like, etc.) contrast behavior Background style and color shapes, proportions, and stylization line quality and outline treatment shading/lighting approach texture use (if any) mood and visual tone pattern usage any recurring artistic conventions Hex colors and their use (skin tone, background, patterns, etc) Produce a clean, standalone style description that can be used to generate new images in the same style but with entirely new characters or scenes. DO NOT mention specific characters, poses, clothing, or objects from the original image—ONLY the style. Output this in two parts: STYLE DESCRIPTION (4–7 sentences): A detailed explanation of the unified artistic style. KEY STYLE TAGS (10–20 keywords): Short labels that summarize the style. Hex colors
It's for special rewards for fans
A picture of naira cash denomination of 500 and 1000 without background