[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-landing-page-audit":3},{"slug":4,"name":4,"description":5,"files":6,"size":44,"readme":45},"landing-page-audit","Audits a landing page — a live URL, a screenshot, or the page's code — against Refactoring UI principles (Adam Wathan & Steve Schoger) plus landing-page checks (first screen, CTAs, proof, section rhythm, mobile), and benchmarks its weakest sections against real, category-matched sections from Landingfolio's gallery via the Landingfolio MCP. Returns a severity-grouped report (Critical \u002F Major \u002F Minor) where every finding names the element, the rule, why it matters, and a concrete fix. Use when the user says \"audit my landing page\", \"review this page\", \"critique my homepage\", \"what's wrong with this design\", \"design feedback on \u003Curl>\", \"why doesn't this page convert\", or hands over a URL, screenshot or component. Works without the MCP (rules-only audit). NOT for copy rewriting, accessibility compliance, SEO, or code-quality review.",[7,11,14,17,20,23,26,29,32,35,38,41],{"path":8,"size":9,"executable":10},"SKILL.md",11552,false,{"path":12,"size":13,"executable":10},"references\u002Fcolor.md",3688,{"path":15,"size":16,"executable":10},"references\u002Fdepth.md",2536,{"path":18,"size":19,"executable":10},"references\u002Fhierarchy.md",2807,{"path":21,"size":22,"executable":10},"references\u002Fimages.md",2019,{"path":24,"size":25,"executable":10},"references\u002Findex.md",1265,{"path":27,"size":28,"executable":10},"references\u002Flanding-page.md",3140,{"path":30,"size":31,"executable":10},"references\u002Fpolish.md",2868,{"path":33,"size":34,"executable":10},"references\u002Fprocess.md",1813,{"path":36,"size":37,"executable":10},"references\u002Fspacing.md",2489,{"path":39,"size":40,"executable":10},"references\u002Ftypography.md",2760,{"path":42,"size":43,"executable":10},"LICENSE.md",1069,38006,"---\nname: landing-page-audit\ndescription: Audits a landing page — a live URL, a screenshot, or the page's code — against Refactoring UI principles (Adam Wathan & Steve Schoger) plus landing-page checks (first screen, CTAs, proof, section rhythm, mobile), and benchmarks its weakest sections against real, category-matched sections from Landingfolio's gallery via the Landingfolio MCP. Returns a severity-grouped report (Critical \u002F Major \u002F Minor) where every finding names the element, the rule, why it matters, and a concrete fix. Use when the user says \"audit my landing page\", \"review this page\", \"critique my homepage\", \"what's wrong with this design\", \"design feedback on \u003Curl>\", \"why doesn't this page convert\", or hands over a URL, screenshot or component. Works without the MCP (rules-only audit). NOT for copy rewriting, accessibility compliance, SEO, or code-quality review.\n---\n\n# Landing Page Audit\n\nReviews a landing page the way a senior designer would: looks at it on desktop and on a phone, walks a fixed rule set, compares its weakest sections with how real live pages handle the same section, and returns a short, severity-grouped list of specific fixes.\n\n`\u003Cskill-dir>` below means the folder this SKILL.md is in.\n\n## When to use this skill\n\n- \"Audit my landing page\" \u002F \"review https:\u002F\u002F…\" \u002F \"critique this homepage\"\n- \"What's wrong with this design?\" \u002F \"design feedback before launch\"\n- \"Why does this page feel off \u002F amateur \u002F generic?\"\n- A screenshot, a `.html`\u002F`.vue`\u002F`.jsx`\u002F`.tsx`\u002F`.svelte` file, or a URL plus \"thoughts?\"\n\n## When NOT to use this skill\n\n- Rewriting the copy → a copy pass (e.g. the `humanize-copy-pass` skill); this audit flags design problems only\n- WCAG\u002Faccessibility compliance, SEO, page speed, or code quality → not covered\n- Designing new sections → `explore-landing-sections`\n- Only fixing the mobile layout → `mobile-responsive-pass`\n\n## Connect the Landingfolio MCP\n\nThe MCP lets the audit compare the page's weakest sections with real, current sections of the same type from landingfolio.com (\"7 of the 8 live pricing sections pulled highlight one plan; yours shows three equal cards\"), instead of judging against rules alone. It's free (100 requests a day).\n\n**Check first:** look for tools from a server named `landingfolio` — `list_categories`, `get_components`, `get_inspiration_page` (Claude Code shows them as `mcp__landingfolio__*`).\n\n**If they're missing**, run the rules-only audit (skip Step 4) and say so in one line at the top of the report and in your reply. Never block on it:\n\n> Benchmarks skipped: the Landingfolio MCP isn't connected. To compare your sections with real live examples, get a free token at https:\u002F\u002Fwww.landingfolio.com\u002Fmcp and run:\n> `claude mcp add --transport http landingfolio https:\u002F\u002Fmcp.landingfolio.com\u002Fmcp --header \"Authorization: Bearer \u003Cyour-token>\"`\n> (Cursor, Codex, Windsurf, VS Code and others: the same page has the snippet for each.)\n\n## Critical rules\n\n1. **Look at the actual page before opining.** Screenshots at desktop and 390px for a URL; read the file for code. Never critique from an idea of \"what a typical landing page looks like\".\n2. **Every finding cites a rule** from `references\u002F` (name the file). If you can't point to a rule, drop the finding.\n3. **Every finding names the element** (section + element, selector, file:line, or visual region) and gives a concrete fix. ❌ \"Improve hierarchy.\" ✅ \"Hero: 'Start free' and 'Book a demo' are identical solid purple buttons — keep 'Start free' solid, make 'Book a demo' an outline button.\"\n4. **Keep the reason.** \"This violates X *because Y*; try Z\" — never just \"this is bad\".\n5. **Benchmarks are evidence, not rules.** A benchmark line strengthens a finding and links the real examples; it never creates a finding on its own (\"other pages use dark heroes\" is not a problem).\n6. **Calibrated severity.** Most pages have 3–8 real problems, not 25. Audit only; don't redesign or edit code unless the user asks after the report.\n\n## Workflow\n\n```\n- [ ] Step 1: Identify the artifact and its product category\n- [ ] Step 2: Capture and inspect it (desktop + 390px)\n- [ ] Step 3: Walk the rule set\n- [ ] Step 4: Benchmark the weakest sections (MCP path)\n- [ ] Step 5: Calibrate severity\n- [ ] Step 6: Write the report\n```\n\n### Step 1: Identify the artifact\n\n| Input | How to handle |\n|-------|---------------|\n| URL (live or `localhost`) | Screenshot it (Step 2) **and** fetch its HTML for exact values |\n| Screenshot (`.png`\u002F`.jpg`) | Open it; ask for a mobile screenshot too if only desktop was given (or note mobile wasn't audited) |\n| Component\u002Fpage file (`.html`, `.vue`, `.jsx`, `.tsx`, `.svelte`, `.astro`) | Read it and the styles it uses; if the dev server runs, also screenshot the rendered page |\n| Figma link | Ask for an exported PNG — Figma URLs aren't renderable |\n| Nothing given | Ask once: \"Which URL, file or screenshot should I audit?\" |\n\nNote the product's category in a few words (B2B SaaS, dev tool, consumer app, agency, e-commerce, course…). It sets expectations for proof and CTAs.\n\n### Step 2: Capture and inspect\n\nFor a URL, take two full-page screenshots — 1280px wide and 390px wide — with whatever the environment has: a screenshot skill such as `screenshot-capture`, a browser MCP, or Playwright (`npx playwright screenshot --full-page --viewport-size=390,844 \u003Curl> mobile.png`). Open both.\n\nBefore auditing, describe what you see in 2–3 lines (the sections in order, the overall look) so the user can check you're looking at the right thing. Then list the page's sections with their Landingfolio category: `hero`, `logo-cloud`, `feature`, `how-it-works`, `testimonial`, `pricing`, `faq`, `call-to-action`, `footer`, …\n\nFrom the code\u002FHTML, note the real values: font families, sizes and weights; text colors; spacing values; shadows, radii, borders; button styles.\n\n### Step 3: Walk the rule set\n\nRead each reference and check its rules against the page:\n\n| Dimension | File | Look for |\n|-----------|------|----------|\n| Landing page | [landing-page.md](references\u002Flanding-page.md) | First screen clarity, one primary CTA, proof near decisions, section rhythm, mobile |\n| Hierarchy | [hierarchy.md](references\u002Fhierarchy.md) | >3 text colors, competing focal points, grey on color, no clear primary action |\n| Spacing | [spacing.md](references\u002Fspacing.md) | No scale, ambiguous grouping, cramped or uniform section gaps |\n| Typography | [typography.md](references\u002Ftypography.md) | Too many sizes, line length, line-height, weak headline contrast |\n| Color | [color.md](references\u002Fcolor.md) | Too few shades, contrast failures, opacity-greys |\n| Depth | [depth.md](references\u002Fdepth.md) | Shadows with no light source, flat cards on busy backgrounds |\n| Images | [images.md](references\u002Fimages.md) | Stretched or low-quality images, text over busy photos, unproven illustrations |\n| Polish | [polish.md](references\u002Fpolish.md) | Default bullets\u002Fcontrols, no accents, bland empty areas |\n| Process | [process.md](references\u002Fprocess.md) | No system (one-off values everywhere), mixed radius personalities |\n\nBe honest: most pages violate a handful of rules meaningfully. Don't fill every bucket.\n\n### Step 4: Benchmark the weakest sections (MCP path)\n\nPick the **2–3 sections with the most serious findings** (often the hero plus one of pricing, features or testimonials). For each:\n\n1. `list_categories` once, to get exact slugs.\n2. `get_components` with that section's category. Download and open 6–8 of the screenshots that fit the product category — never judge from URLs alone:\n   ```bash\n   mkdir -p .landing-audit\u002Frefs && curl -sL \"\u003Cimage-url>\" -o .landing-audit\u002Frefs\u002F\u003Ccategory>-\u003Cn>.jpg\n   ```\n3. For each finding in that section, check how the references handle the same thing. Write a **Benchmark** line only when they show a clear pattern: \"6 of 8 live pricing sections highlight one plan (e.g. \u003Csource>, \u003Csource>)\". Link 1–3 `source` URLs.\n4. Also note anything the references consistently do that the page lacks *and* that a rule in `references\u002F` supports (e.g. testimonials with photos → polish.md, images.md). That can become a finding with the rule cited.\n\nIf the user names a site they want to be closer to and it's on Landingfolio, `get_inspiration_page` with its slug returns the full page in tiles — compare section by section.\n\n### Step 5: Calibrate severity\n\n- **Critical** — the page fails its job: you can't tell what the product is from the first screen, the primary CTA is missing or invisible, text is unreadable, the mobile layout is broken (horizontal scroll, clipped content).\n- **Major** — visibly wrong and hurts trust: competing CTAs, no proof near the decision, flat uniform sections, weak headline contrast, low-quality or stretched images.\n- **Minor** — polish: default bullets, inconsistent radius, a slightly long line length, an off line-height.\n\nIf more than two findings are Critical, re-read and demote.\n\n### Step 6: Write the report\n\nWrite it to `landing-page-audit.md` in the project root (or where the user asked) and give the path plus the Critical list in your reply. Use this format:\n\n```markdown\n# Landing page audit — \u003Cpage name or URL>\n\n**Looked at:** \u003Cwhat you inspected: URL at 1280 + 390px \u002F file \u002F screenshot>\n**Benchmarks:** \u003C\"N live \u003Ccategories> sections from Landingfolio\" or \"skipped — Landingfolio MCP not connected\">\n\n## Critical\n### 1. \u003CShort title>\n**Where:** \u003Csection › element, selector or file:line>\n**Violates:** \u003Crule, file in references\u002F>\n**Why it matters:** \u003Cthe rule's reason>\n**Benchmark:** \u003Coptional — \"6 of 8 live hero sections …\" + 1–3 source links>\n**Fix:** \u003Cspecific change>\n\n## Major\n### 2. …\n\n## Minor\n### 3. …\n\n## What's working\n- \u003C1–3 things to keep>\n\n## Next step\n\u003Cone line, e.g. \"Want me to apply fixes 1–4?\" or \"Want 3–4 directions for the hero? (explore-landing-sections)\">\n```\n\n## Examples\n\n**\"Audit https:\u002F\u002Facme.dev\"** → screenshots at 1280 and 390 + HTML → sections: header, hero, logo-cloud, feature ×3, pricing, faq, footer → rules: hero has two identical CTAs (hierarchy), feature cards use 4 greys (color), pricing has three equal cards with no recommended plan (landing-page) → benchmark hero + pricing: `get_components hero`, `get_components pricing`, 8 each viewed → report: 1 Critical, 3 Major, 2 Minor, with benchmark links on the hero and pricing findings.\n\n**\"Audit `src\u002Fpages\u002Findex.astro`\", MCP not connected** → read the file and its CSS, screenshot the dev server at both widths → rules-only report with \"Benchmarks: skipped\" and the connect note.\n\n## Troubleshooting\n\n- **Audit reads generic, could apply to any page:** you skipped Step 2 or padded findings. Re-open the screenshots; every finding needs a named element.\n- **Everything is Critical:** severity inflation. Critical = the page can't do its job.\n- **A benchmark became the finding** (\"other sites use bento grids\"): drop it unless a rule in `references\u002F` backs it.\n- **The page is JS-rendered and the HTML fetch is empty:** rely on the screenshots and the browser's computed styles.\n- **User disagrees with a finding:** the reason is the conversation, not the rule. If their context justifies the choice, drop it.\n- **429 from the MCP:** the free tier is 100 requests a day; benchmark one section instead of three.\n\n## Reference\n\nThe rule set lives in [references\u002F](references\u002F): condensed rules from *Refactoring UI* plus [landing-page.md](references\u002Flanding-page.md). See [references\u002Findex.md](references\u002Findex.md).\n"]