Seraphy Mascot
SeraphyAgent
G

gokbeyinac

@gokbeyinac

15Prompts
Rank #9Global

13 contributions in the last year

Less
More
Development

Design System Extraction Prompt Kit

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 ScopeAnalyze 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 InventoryFor 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 FormatReturn 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.

#coding#text#ai+1
G
gokbeyinac
Development

Token Architecture

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 HierarchyDesign 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 Rules1. 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 progression5. Create named animation presets from one-off values## Output FormatProvide:1. **Complete token map** in JSON — all three tiers with references2. **Migration table** — current value → new token name → which files use it3. **Deprecation list** — values to remove with suggested replacements4. **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 consolidationchoices, so transparency matters more than confidence.

#coding#text
G
gokbeyinac
Development

Component Documentation

You are a design systems documentarian creating the component specificationfor 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 SpecificationFor 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 MapComponent: 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 ExampleProvide a copy-paste-ready code example using the actual codebase'spatterns (import paths, className conventions, etc.)## Output FormatMarkdown, structured with headers per section. This will be directlyinserted into the CLAUDE.md file.

#coding#text#ai
G
gokbeyinac
Development

CLAUDE.md Assembly

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 oftruth 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 StructureCompile 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 CardA 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 ReferenceOrganized 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 & ConstraintsHard 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 RuleThis file must be AUTHORITATIVE. If there's ambiguity between theCLAUDE.md and the actual code, the CLAUDE.md should be updated tomatch reality — never the other way around. This documents what IS,not what SHOULD BE (that's a separate roadmap).

#coding#text#ai+1
G
gokbeyinac
Development

Update/Sync Prompt

You are updating an existing FORME.md documentation file to reflectchanges 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 Tasks1. **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 updating3. **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 original4. **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 changed5. **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]"

#coding#text#ai+1
G
gokbeyinac
Writing & Content

"Explain It Like I Built It" Technical Documentation for Non-Technical Founders

You are a senior technical writer who specializes in making complex systemsunderstandable to non-engineers. You have a gift for analogy, narrative, andturning architecture diagrams into stories.I need you to analyze this project and write a comprehensive documentationfile called `FORME.md` that explains everything about this project inplain 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 StructureWrite 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 BlueprintExplain 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 SystemMap 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 OtherTrace 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 ToolboxFor 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 & ConfigurationExplain 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 StoriesThis 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 CardA 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-NEGOTIABLE1. **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 ToneWRONG — dry and jargon-heavy:"The application implements server-side rendering with incrementalstatic regeneration, utilizing Next.js App Router with React ServerComponents for optimal TTFB."RIGHT — clear and engaging:"When someone visits our site, the server pre-builds the page beforesending it — like a restaurant that preps your meal before you arriveinstead of starting from scratch when you sit down. This is called'server-side rendering' and it's why pages load fast. We use Next.jsApp Router for this, which is like the kitchen's workflow system thatdecides 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"

#analysis#writing#communication+2
G
gokbeyinac
Development

Design Handoff Notes - AI First, Human Readable

# Design Handoff Notes — AI-First, Human-Readable### A structured handoff document optimized for AI implementation agents (Claude Code, Cursor, Copilot) while remaining clear for human developers---## About This Prompt**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.**The core philosophy:** If an AI reads this document and has to guess anything, the document has failed.**When to use:** After design is finalized, before implementation begins. This replaces Figma handoff, design spec PDFs, and "just make it look like the mockup" conversations.**Who reads this:**- Primary: AI coding agents (Claude Code, Cursor, Copilot, etc.)- Secondary: Human developers reviewing or debugging the AI's output- Tertiary: You (the designer), when checking if implementation matches intent**Relationship to CLAUDE.md:** This document assumes a CLAUDE.md design system file already exists in the project root. Handoff Notes reference tokens from CLAUDE.md but don't redefine them. If no CLAUDE.md exists, run the Design System Extraction prompts first.---## The Prompt```You are a design systems engineer writing implementation specifications.Your output will be read primarily by AI coding agents (Claude Code, Cursor)and secondarily by human developers.Your writing must follow one absolute rule:**If the reader has to guess, infer, or assume anything, you have failed.**Every value must be explicit. Every state must be defined. Every edge casemust have a rule. No "as appropriate," no "roughly," no "similar to."## Project Context- **Project:** ${name}- **Framework:** [Next.js 14+ / React / etc.]- **Styling:** [Tailwind 3.x / CSS Modules / etc.]- **Component library:** [shadcn/ui / custom / etc.]- **CLAUDE.md location:** [path — or "not yet created"]- **Design source:** [uploaded code / live URL / screenshots]- **Pages to spec:** [all / specific pages]## Output Format RulesBefore writing any specs, follow these formatting rules exactly:1. **Values are always code-ready.** WRONG: "medium spacing" RIGHT: `p-6` (24px)2. **Colors are always token references + fallback hex.** WRONG: "brand blue" RIGHT: `text-brand-500` (#2563EB) — from CLAUDE.md tokens3. **Sizes are always in the project's unit system.** If Tailwind: use Tailwind classes as primary, px as annotation If CSS: use rem as primary, px as annotation WRONG: "make it bigger on desktop" RIGHT: `text-lg` (18px) at ≥768px, `text-base` (16px) below4. **Conditionals use explicit if/else, never "as needed."** WRONG: "show loading state as appropriate" RIGHT: "if data fetch takes >300ms, show skeleton. If fetch fails, show error state. If data returns empty array, show empty state."5. **File paths are explicit.** WRONG: "create a button component" RIGHT: "create `src/components/ui/Button.tsx`"6. **Every visual property is stated, never inherited by assumption.** Even if "obvious" — state it. AI agents don't have visual context.---## Document StructureGenerate the handoff document with these sections:### SECTION 1: IMPLEMENTATION MAPA priority-ordered table of everything to build.AI agents should implement in this order to resolve dependencies correctly.| Order | Component/Section | File Path | Dependencies | Complexity | Notes ||-------|------------------|-----------|-------------|-----------|-------|| 1 | Design tokens setup | `tailwind.config.ts` | None | Low | Must be first — all other components reference these || 2 | Typography components | `src/components/ui/Text.tsx` | Tokens | Low | Heading, Body, Caption, Label variants || 3 | Button | `src/components/ui/Button.tsx` | Tokens, Typography | Medium | 3 variants × 3 sizes × 6 states || ... | ... | ... | ... | ... | ... |Rules:- Nothing can reference a component that comes later in the table- Complexity = how many variants × states the component has- Notes = anything non-obvious about implementation---### SECTION 2: GLOBAL SPECIFICATIONSThese apply everywhere. AI agent should configure these BEFORE building any components.#### 2.1 BreakpointsDefine exact behavior boundaries:```BREAKPOINTS { mobile: 0px — 767px tablet: 768px — 1023px desktop: 1024px — 1279px wide: 1280px — ∞}```For each breakpoint, state:- Container max-width and padding- Base font size- Global spacing multiplier (if it changes)- Navigation mode (hamburger / horizontal / etc.)#### 2.2 Transition Defaults```TRANSITIONS { default: duration-200 ease-out slow: duration-300 ease-in-out spring: duration-500 cubic-bezier(0.34, 1.56, 0.64, 1) none: duration-0}RULE: Every interactive element uses `default` unless this document specifies otherwise.RULE: Transitions apply to: background-color, color, border-color, opacity, transform, box-shadow. Never to: width, height, padding, margin (these cause layout recalculation).```#### 2.3 Z-Index Scale```Z-INDEX { base: 0 dropdown: 10 sticky: 20 overlay: 30 modal: 40 toast: 50 tooltip: 60}RULE: No z-index value outside this scale. Ever.```#### 2.4 Focus Style```FOCUS { style: ring-2 ring-offset-2 ring-brand-500 applies-to: every interactive element (buttons, links, inputs, selects, checkboxes) visible: only on keyboard navigation (use focus-visible, not focus)}```---### SECTION 3: PAGE SPECIFICATIONSFor each page, provide a complete implementation spec.#### Page: ${page_name}**Route:** `/exact-route-path`**Layout:** ${which_layout_wrapper_to_use}**Data requirements:** [what data this page needs, from where]##### Page Structure (top to bottom)```PAGE STRUCTURE: ${page_name}├── Section: Hero│ ├── Component: Heading (h1)│ ├── Component: Subheading (p)│ ├── Component: CTA Button (primary, lg)│ └── Component: HeroImage├── Section: Features│ ├── Component: SectionHeading (h2)│ └── Component: FeatureCard × 3 (grid)├── Section: Testimonials│ └── Component: TestimonialSlider└── Section: CTA ├── Component: Heading (h2) └── Component: CTA Button (primary, lg)```##### Section-by-Section SpecsFor each section:**${section_name}**```LAYOUT { container: max-w-[1280px] mx-auto px-6 (mobile: px-4) direction: flex-col (mobile) → flex-row (desktop) gap: gap-8 (32px) padding: py-16 (64px) (mobile: py-10) background: bg-white}CONTENT { heading { text: "${exact_heading_text_or_content_source}" element: h2 class: text-3xl font-bold text-gray-900 (mobile: text-2xl) max-width: max-w-[640px] } body { text: "${exact_body_text_or_content_source}" class: text-lg text-gray-600 leading-relaxed (mobile: text-base) max-width: max-w-[540px] }}GRID (if applicable) { columns: grid-cols-3 (tablet: grid-cols-2) (mobile: grid-cols-1) gap: gap-6 (24px) items: ${what_component_renders_in_each_cell} alignment: items-start}ANIMATION (if applicable) { type: fade-up on scroll trigger: when section enters viewport (threshold: 0.2) stagger: each child delays 100ms after previous duration: duration-500 easing: ease-out runs: once (do not re-trigger on scroll up)}```---### SECTION 4: COMPONENT SPECIFICATIONSFor each component, provide a complete implementation contract.#### Component: ${componentname}**File:** `src/components/${path}/${componentname}.tsx`**Purpose:** [one sentence — what this component does]##### Props Interface```typescriptinterface ${componentname}Props { variant: 'primary' | 'secondary' | 'ghost' // visual style size: 'sm' | 'md' | 'lg' // dimensions disabled?: boolean // default: false loading?: boolean // default: false icon?: React.ReactNode // optional leading icon children: React.ReactNode // label content onClick?: () => void // click handler}```##### Variant × Size MatrixDefine exact values for every combination:```VARIANT: primary SIZE: sm height: h-8 (32px) padding: px-3 (12px) font: text-sm font-medium (14px) background: bg-brand-500 (#2563EB) text: text-white (#FFFFFF) border: none border-radius: rounded-md (6px) shadow: none SIZE: md height: h-10 (40px) padding: px-4 (16px) font: text-sm font-medium (14px) background: bg-brand-500 (#2563EB) text: text-white (#FFFFFF) border: none border-radius: rounded-lg (8px) shadow: shadow-sm SIZE: lg height: h-12 (48px) padding: px-6 (24px) font: text-base font-semibold (16px) background: bg-brand-500 (#2563EB) text: text-white (#FFFFFF) border: none border-radius: rounded-lg (8px) shadow: shadow-smVARIANT: secondary [same structure, different values]VARIANT: ghost [same structure, different values]```##### State SpecificationsEvery state must be defined for every variant:```STATES (apply to ALL variants unless overridden): hover { background: ${token} — darken one step from default transform: none (no scale/translate on hover) shadow: ${token_or_none} cursor: pointer transition: default (duration-200 ease-out) } active { background: ${token} — darken two steps from default transform: scale-[0.98] transition: duration-75 } focus-visible { ring: ring-2 ring-offset-2 ring-brand-500 all other: same as default state } disabled { opacity: opacity-50 cursor: not-allowed pointer-events: none ALL hover/active/focus states: do not apply } loading { content: replace children with spinner (16px, animate-spin) width: maintain same width as non-loading state (prevent layout shift) pointer-events: none opacity: opacity-80 }```##### Icon Behavior```ICON RULES { position: left of label text (always) size: 16px (sm), 16px (md), 20px (lg) gap: gap-1.5 (sm), gap-2 (md), gap-2 (lg) color: inherits text color (currentColor) when loading: icon is hidden, spinner takes its position icon-only: if no children, component becomes square (width = height) add aria-label prop requirement}```---### SECTION 5: INTERACTION FLOWSFor each user flow, provide step-by-step implementation:#### Flow: [Flow Name, e.g., "User Signs Up"]```TRIGGER: user clicks "Sign Up" button in headerSTEP 1: Modal opens animation: fade-in (opacity 0→1, duration-200) backdrop: bg-black/50, click-outside closes modal focus: trap focus inside modal, auto-focus first input body: scroll-lock (prevent background scroll)STEP 2: User fills form fields: ${list_exact_fields_with_validation_rules} validation: on blur (not on change — reduces noise) field: email { type: email required: true validate: regex pattern + "must contain @ and domain" error: "That doesn't look like an email — check for typos" success: green checkmark icon appears (fade-in, duration-150) } field: password { type: password (with show/hide toggle) required: true validate: min 8 chars, 1 uppercase, 1 number error: show checklist of requirements, highlight unmet strength: show strength bar (weak/medium/strong) }STEP 3: User submits button: shows loading state (see Button component spec) request: POST /api/auth/signup duration: expect 1-3 secondsSTEP 4a: Success modal: content transitions to success message (crossfade, duration-200) message: "Account created! Check your email to verify." action: "Got it" button closes modal redirect: after close, redirect to /dashboard toast: none (the modal IS the confirmation)STEP 4b: Error — email exists field: email input shows error state message: "This email already has an account — want to log in instead?" action: "Log in" link switches modal to login form button: returns to default state (not loading)STEP 4c: Error — network failure display: error banner at top of modal (not a toast) message: "Something went wrong on our end. Try again?" action: "Try again" button re-submits button: returns to default stateSTEP 4d: Error — rate limited display: error banner message: "Too many attempts. Wait 60 seconds and try again." button: disabled for 60 seconds with countdown visible```---### SECTION 6: RESPONSIVE BEHAVIOR RULESDon't describe what changes — specify the exact rules:```RESPONSIVE RULES:Rule 1: Navigation ≥1024px: horizontal nav, all items visible <1024px: hamburger icon, slide-in drawer from right drawer-width: 80vw (max-w-[320px]) animation: translate-x (duration-300 ease-out) backdrop: bg-black/50, click-outside closesRule 2: Grid Sections ≥1024px: grid-cols-3 768-1023px: grid-cols-2 (last item spans full if odd count) <768px: grid-cols-1Rule 3: Hero Section ≥1024px: two-column (text left, image right) — 55/45 split <1024px: single column (text top, image bottom) image max-height: 400px, object-coverRule 4: Typography Scaling ≥1024px: h1=text-5xl, h2=text-3xl, h3=text-xl, body=text-base <1024px: h1=text-3xl, h2=text-2xl, h3=text-lg, body=text-baseRule 5: Spacing Scaling ≥1024px: section-padding: py-16, container-padding: px-8 768-1023px: section-padding: py-12, container-padding: px-6 <768px: section-padding: py-10, container-padding: px-4Rule 6: Touch Targets <1024px: all interactive elements minimum 44×44px hit area if visual size < 44px, use invisible padding to reach 44pxRule 7: Images all images: use next/image with responsive sizes prop hero: sizes="(max-width: 1024px) 100vw, 50vw" grid items: sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw"```---### SECTION 7: EDGE CASES & BOUNDARY CONDITIONSThis section prevents the "but what happens when..." problems:```EDGE CASES:Text Overflow { headings: max 2 lines, then truncate with text-ellipsis (add title attr for full text) body text: allow natural wrapping, no truncation button labels: single line only, max 30 characters, no truncation (design constraint) nav items: single line, truncate if >16 characters on mobile table cells: truncate with tooltip on hover}Empty States { lists/grids with 0 items: show ${emptystate} component - illustration: ${describe_or_reference_asset} - heading: "${exact_text}" - body: "${exact_text}" - CTA: "${exact_text}" → ${action} user avatar missing: show initials on colored background - background: generate from user name hash (deterministic) - initials: first letter of first + last name, uppercase - font: text-sm font-medium text-white image fails to load: show gray placeholder with image icon - background: bg-gray-100 - icon: ImageOff from lucide-react, text-gray-400, 24px}Loading States { page load: full-page skeleton (not spinner) component load: component-level skeleton matching final dimensions button action: inline spinner in button (see Button spec) infinite list: skeleton row × 3 at bottom while fetching next page skeleton style: bg-gray-200 rounded animate-pulse skeleton rule: skeleton shape must match final content shape (rectangle for text, circle for avatars, rounded-lg for cards)}Error States { API error (500): show inline error banner with retry button Network error: show "You seem offline" banner at top (auto-dismiss when reconnected) 404 content: show custom 404 component (not Next.js default) Permission denied: redirect to /login with return URL param Form validation: inline per-field (see flow specs), never alert()}Data Extremes { username 1 character: display normally username 50 characters: truncate at 20 in nav, full in profile price $0.00: show "Free" price $999,999.99: ensure layout doesn't break (test with formatted number) list with 1 item: same layout as multiple (no special case) list with 500 items: paginate at 20, show "Load more" button date today: show "Today" not the date date this year: show "Mar 13" not "Mar 13, 2026" date other year: show "Mar 13, 2025"}```---### SECTION 8: IMPLEMENTATION VERIFICATION CHECKLISTAfter implementation, the AI agent (or human developer) should verify:```VERIFICATION:□ Every component matches the variant × size matrix exactly□ Every state (hover, active, focus, disabled, loading) works□ Tab order follows visual order on all pages□ Focus-visible ring appears on keyboard nav, not on mouse click□ All transitions use specified duration and easing (not browser default)□ No layout shift during page load (check CLS)□ Skeleton states match final content dimensions□ All edge cases from Section 7 are handled□ Touch targets ≥ 44×44px on mobile breakpoints□ No horizontal scroll at any breakpoint□ All images use next/image with correct sizes prop□ Z-index values only use the defined scale□ Error states display correctly (test with network throttle)□ Empty states display correctly (test with empty data)□ Text truncation works at boundary lengths□ Dark mode tokens (if applicable) are all mapped```---## How the AI Agent Should Use This DocumentInclude this instruction at the top of the generated handoff documentso the implementing AI knows how to work with it:```INSTRUCTIONS FOR AI IMPLEMENTATION AGENT:1. Read this document fully before writing any code.2. Implement in the order specified in SECTION 1 (Implementation Map).3. Reference CLAUDE.md for token values. If a token referenced here is not in CLAUDE.md, flag it and use the fallback value provided.4. Every value in this document is intentional. Do not substitute with "close enough" values. `gap-6` means `gap-6`, not `gap-5`.5. Every state must be implemented. If a state is not specified for a component, that is a gap in the spec — flag it, do not guess.6. After implementing each component, run through its state matrix and verify all states work before moving to the next component.7. When encountering ambiguity, prefer the more explicit interpretation. If still ambiguous, add a TODO comment: "// HANDOFF-AMBIGUITY: [description]"``````---## Customization Notes**If you're not using Tailwind:** Replace all Tailwind class references in the prompt with your system's equivalents. The structure stays the same — only the value format changes. Tell Claude: "Use CSS custom properties as primary, px values as annotations."**If you're handing off to a specific AI tool:** Add tool-specific notes. For example, for Cursor: "Generate implementation as step-by-step edits to existing files, not full file rewrites." For Claude Code: "Create each component as a complete file, test it, then move to the next."**If no CLAUDE.md exists yet:** Tell the prompt to generate a minimal token section at the top of the handoff document covering only the tokens needed for this specific handoff. It won't be a full design system, but it prevents hardcoded values.**For multi-page projects:** Run the prompt once per page, but include Section 1 (Implementation Map) and Section 2 (Global Specs) only in the first run. Subsequent pages reference the same globals.

#coding#ai#structured
G
gokbeyinac
Creative

Visual QA & Cross-Browser Audit

You are a senior QA specialist with a designer's eye. Your job is to findevery visual discrepancy, interaction bug, and responsive issue in thisimplementation.## 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 CheckFor 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 BehaviorAt 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

#text
G
gokbeyinac
Development

Lighthouse & Performance Optimization

You are a web performance specialist. Analyze this site and provideoptimization recommendations that a designer can understand and adeveloper 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 AssessmentFor 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 SnippetsFor the top 5 fixes, provide copy-paste-ready code or configuration.

#coding#text#ai+1
G
gokbeyinac
Entertainment

Pre-Launch Checklist Generator

You are a launch readiness specialist. Generate a comprehensivepre-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 assetsthat must be replaced before launch. This is a CRITICAL category — aplaceholder 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 FormatA 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

#text#ai
G
gokbeyinac