Skip to content

Instantly share code, notes, and snippets.

@ajayjapan
Created March 7, 2026 14:45
Show Gist options
  • Select an option

  • Save ajayjapan/adbe820125ca4ea80f95935d4c280762 to your computer and use it in GitHub Desktop.

Select an option

Save ajayjapan/adbe820125ca4ea80f95935d4c280762 to your computer and use it in GitHub Desktop.
YC's Design Review with Raphael Schaad turned into a Claude skill for auditing marketing sites. https://www.youtube.com/watch?v=DNSXlBmukck
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.

Engineering & Design Standards: Avoiding "AI Slop"

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.

1. Interaction Design & UX

  • 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 sticky or scroll-snap only 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.

2. Visual Identity & Branding

  • 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.

3. Information Architecture

  • 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.

4. Animation Guidelines

  • 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.

5. How to Apply This Skill

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.

6. Understand Business

Before suggesting fixes, you need to understand the business. For each question below:

  1. Make your best guess based on the site or code
  2. Present the guess to the user and ask them to confirm or correct it
  3. 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.

7. Live Audit (Optional)

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:

  1. Check whether any browser automation tools are available (Playwright, Puppeteer, Selenium, etc.)
  2. 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.
  3. 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.

@ajayjapan
Copy link
Author

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

  1. Create a folder at ~/.claude/skills/marketing-site-design-auditor
  2. Add the file and rename it to SKILL.md
  3. Trigger it with /marketing-site-design-auditor inside Claude Code

I recommend using it alongside Claude's frontend-design skill.

@ajayjapan
Copy link
Author

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment