| name | description |
|---|---|
marketing-site-design-auditor |
Use this skill when the user asks to review, audit, critique, or improve a marketing site. Triggers include: "review my landing page", "what's wrong with my design", "make this look less AI-generated", "audit my UI", or any request to refine a vibe-coded or AI-generated marketing site into a more polished, high-converting product. Not intended for general web apps, dashboards, or internal tools. |
This document outlines the technical and aesthetic standards for startup marketing sites, specifically focusing on moving beyond AI-generated defaults to create professional, original, and high-converting products.
- Anti-Scroll-Jacking: Never override the user's native browser scroll. Heavy scroll-jacking makes sites feel like they're "moving through molasses" and breaks the user's sense of progress through the page. Use CSS
stickyorscroll-snaponly when it genuinely enhances readability, not to lock users into a section for an animation. - Intentional Hover Effects: Hover should make an element feel more clickable and alive — not move it away from the cursor, fade it out, or shift the layout. A browser already signals interactivity by turning the cursor into a hand; any CSS hover effect should build on that signal, not contradict it. A subtle lightening, a brand-color fill, or a gentle glow are appropriate. Vertical shifts, fadeouts, or layout-breaking effects are not.
- Never Hide Critical Information Behind Hover: Revealing essential functionality or content only on hover is an anti-pattern. It fails entirely on mobile (where hover doesn't exist and long-press never caught on), and forces desktop users to hunt around the interface to discover what the product does. If information is important enough to show, show it.
- Clickability Clarity: Never use a hand cursor on an element that isn't actually clickable — this is a "head fake" that erodes trust. Every interactive element should behave exactly as its visual affordance suggests.
- Fade-In on Scroll: Scrolling is already motion — layering fade-ins on top adds no value and creates problems. Users who scroll quickly will blow past content as it's still fading in and miss it entirely. A half-loaded FAQ section looks broken, not polished. If fade-ins are used at all, they must be scroll-position-triggered, not timer-based, and must complete before the user can reasonably scroll past them.
- Navigation Clarity: Non-standard navigation (e.g. vertical anchor-jumping, side-scrolling menus) disorients users. Sticky headers should transition smoothly — never show two versions of the header simultaneously. Menu hover states should highlight the active item, not dim it.
- QA as a Core Skill: Specifically check for: text contrast over dynamic or video backgrounds (white text disappearing over a bright frame is a common failure), layout breaks at mobile widths, interactive elements that show a hand cursor but don't respond to clicks, and animations that conflict with each other.
- Beyond the "Purple Gradient": Purple/pink gradients became ubiquitous because LLMs were trained on good examples that used them — and then reproduced them everywhere. The same week a strong site sets a trend, every LLM-generated site starts using it. Avoid these defaults unless they are genuinely core to the brand. The goal is to look like your company, not like a template.
- Iconography & Assets: Avoid generic system emojis, "Google-colored" dashboard icons (red/yellow/green/blue), and bento boxes with a stock icon above two lines of text. These are immediate tells. Use high-resolution, original assets. Blurry hero screenshots or AI-hallucinated UI mockups undermine credibility — if the product is real, show the real product.
- Fake Dashboard Syndrome: AI-generated product screenshots tend to look the same: primary-color callouts, grid-based stat cards, and icons that are a darker shade of their background color. If you're showing a product UI in your hero or features section, make sure it looks like your actual product, not a placeholder dashboard.
- Cohesive Visual Language: Every section of the page — hero, features, testimonials, FAQ, footer — should feel like it came from the same designer. Audit for consistent type scales, spacing rhythms, color usage, and illustration style across the full page.
- The "Above the Fold" Rule: Within the first 5 seconds, a visitor must be able to answer three questions without scrolling: What is it? Who is it for? Why should they care? If those three things plus a clear call to action are not immediately visible, conversion suffers. Every word and element above the fold should earn its place by serving one of those three questions.
- Tight Style Count: The hero should use a maximum of 3 text styles: logo, H1, and subtext. LLMs frequently insert an extra label or tag between the logo and headline — a fifth style that adds vertical space and dilutes hierarchy without adding meaning. A human designer would almost never choose this. Cut it.
- Hierarchy over Clutter: Guide the user's eye with a single, opinionated visual path. Avoid label-stacking (logo → tag → eyebrow → headline → sub-headline) and competing calls to action. Every element should either advance the hierarchy or be removed.
- Meaty Content: Vague claims like "10x everything," "AI-powered," or "close deals faster" are filler. They feel made up because they are. Replace them with specific, credible, data-driven value propositions that tell the visitor exactly what they get and why it matters to them.
- Scroll Progress Awareness: On pages with heavy animations or scroll-jacked sections, users lose track of how far through the page they are. A scroll progress indicator, or simply ensuring sections have natural visual endpoints, helps users stay oriented and prevents them from abandoning the page thinking there's nothing left.
- Invite Scrolling Visually: A hero section that fills 100% of the viewport with no visual hint of content below creates a dead end. Leaving ~10px of the next section peeking above the fold naturally signals there is more to see — without resorting to a "scroll down" arrow, which is patronizing and redundant.
- Contrast & Readability: Check text contrast in two scenarios: (1) static text — body copy and labels should meet minimum contrast ratios, especially light text on dark or gradient backgrounds; (2) dynamic backgrounds — if a video or animated background plays behind navigation or hero text, verify contrast holds across every frame, not just the poster image. White text over a bright video frame is a common failure that only appears at runtime.
- Value-Add Motion Only: Every animation should either demonstrate how the product works or make the interface feel more alive in a way that serves the user. If you cannot articulate why a specific animation is there, remove it. The bar should be: would a human engineer have prioritized building this from scratch? If not, it probably doesn't belong.
- The Distraction Test: If an animation draws more attention than the copy next to it — a line chasing the cursor, meteors shooting across the background, cards constantly rearranging — it is actively harming conversion. The user remembers the animation and nothing about the product. Remove it.
- Just Because You Can Doesn't Mean You Should: Evaluate every effect on its merit, not its ease. If you cannot justify why it's there, remove it.
- Performance: Animations must not degrade scroll performance. JavaScript-hooked scroll animations are a common culprit — they intercept native scrolling to run logic and make the page feel sluggish. Prefer CSS-based transitions. Scrolling should always feel snappy and native.
If the user triggers this skill without providing any code, ask: "What design would you like to review?"
Before doing anything else, determine whether the submission is a marketing site. If it's clearly a dashboard, internal tool, web app, or other non-landing-page UI, respond:
"This skill is designed specifically for marketing sites. It looks like you've shared a [dashboard / web app / etc.] — I'd suggest a general UI review instead. Would you like me to proceed anyway, or is there a marketing site you'd like me to look at?"
When auditing a UI or frontend component, review it against each standard above and output:
- Overall Quality: A brief summary of the UI's general standard.
- Issues Found: A specific list of problems identified.
- Suggestions: Concrete fixes for each issue.
Before suggesting fixes, you need to understand the business. For each question below:
- Make your best guess based on the site or code
- Present the guess to the user and ask them to confirm or correct it
- Wait for their response before moving to the next question
Ask all four questions in order:
Q1 — Target Customer (ICP)
"It looks like your target customer is [your guess — e.g. 'early-stage startup founders who need to automate QA']. Is that right, or would you describe them differently? (Skip to move on)"
Q2 — Core Value Proposition
"Your main value prop seems to be [your guess — e.g. 'saving engineering time by replacing manual game testing with AI agents']. Does that capture it? (Skip to move on)"
Q3 — Brand Identity
"The visual identity reads as [your guess — e.g. 'technical and modern, leaning into purple/dark tones with no strong differentiated brand direction']. Is that intentional, or do you have a defined brand you were trying to hit? (Skip to move on)"
Q4 — Desired Action
"The primary action you want visitors to take appears to be [your guess — e.g. 'signing up for a free trial']. Is that the main conversion goal? (Skip to move on)"
Once all four are answered (or skipped), proceed to the audit.
A static code review alone will miss runtime issues — hover effects, scroll behavior, animation jank, and contrast failures only appear in a live browser.
Before starting the audit:
- Check whether any browser automation tools are available (Playwright, Puppeteer, Selenium, etc.)
- If at least one is available, ask the user if they'd like a live audit and if so, whether they have a URL to test against.
- If multiple tools are available, ask the user which they'd prefer to use.
If no browser automation tool is available, or the user declines, proceed with code review only.
Hi. I really enjoyed watching this episode with Raphael Schaad (@raphaelschaad) and wanted to see if I could make a SKILL.md based on his feedback. Let me know if I missed anything or have suggestions.
Usage
~/.claude/skills/marketing-site-design-auditorSKILL.md/marketing-site-design-auditorinside Claude CodeI recommend using it alongside Claude's
frontend-designskill.