landing-page-builder

name	landing-page-builder
description	Use when the user wants to create or revise a conversion landing page in the current repository, including message, proof, CTA flow, search posture, and responsive implementation. Do not use for brand strategy, research-only work, product app flows, corporate sites, or theme-only restyling.

Landing Page Builder

Create or improve a landing page that is meant to persuade a specific audience to take a clear action. Focus on conversion structure, message clarity, proof strategy, visual hierarchy, minimum viable SEO hygiene, and shipped implementation in the current repository.

Use this skill when the user wants to:

• build a new LP or conversion-focused marketing landing page
• refresh an existing landing page to improve clarity or conversion
• turn product notes, feature bullets, or rough copy into a working page
• add CTA sections, proof blocks, pricing teasers, FAQ sections, or hero messaging
• make a landing page responsive, more polished, and easier to scan

Do Not Use For

• brand strategy or broader identity system work
• research-only requests that should start from current web evidence
• full product app implementation outside the landing page flow
• one-off restyling of an existing artifact without changing its message or structure
• screenshot capture work for launch assets

Core Principles

• Start from the conversion goal, not from decorative UI.
• Keep one primary audience and one primary CTA visible throughout the page.
• Make the page easy to scan: strong hierarchy, short sections, and proof near claims.
• Make the product, service, or outcome feel already in use. Prefer concrete UI, workflow states, outputs, examples, or customer outcomes over generic illustration.
• Put credible proof early enough to support the first major claim: logos, quantified outcomes, named customers, security posture, marketplace depth, or fresh product activity.
• Choose a proof mode intentionally: workflow simulation, live product/demo surface, customer outcome gallery, quantified enterprise proof, ecosystem depth, or trust/compliance proof.
• Treat dynamic style as communication, not decoration. Motion, layering, scroll effects, and interactive states should reveal product value, guide attention, or make proof easier to understand.
• Always decide the search posture: indexable page, campaign-only page, or explicitly noindex page.
• Treat basic SEO hygiene as mandatory even when paid traffic is the main acquisition path.
• Preserve the repository's existing stack and design language unless the user asks for a deliberate change.
• Prefer a smaller coherent page over a bloated page with redundant sections.

Reference Material

• Use references/lp-patterns.md when a landing page needs stronger structure, visual proof, CTA strategy, or reference-backed design direction.
• Use references/dynamic-visual-style.md when the LP needs motion, dimensional product visuals, interactive hero treatments, animated proof, or conversion-supporting visual polish.
• For reference-led work, base decisions on structured checks of comparable LPs. Parallelize independent read-only reference checks when that materially speeds comparison, using the same evidence checklist and keeping implementation ownership in one place.

Workflow

1. Frame the landing page brief.

   • Identify the offer, target audience, primary CTA, and traffic context.
   • Gather any available inputs such as existing copy, screenshots, logos, testimonials, pricing notes, or competitor references.
   • Stop if the request is really about strategy, research, or a full application flow instead of an LP.

2. Run a reference-led structure pass when design direction is weak, ambiguous, or explicitly requested.

   • Use references/lp-patterns.md as the baseline pattern library.
   • When comparable LPs are named or directly needed for implementation, check each LP separately for hero promise, CTA split, above-the-fold proof, section order, trust signals, product visualization, interaction, and SEO posture.
   • Keep reference checks implementation-facing: page structure, proof, CTA, visual pattern, and SEO posture. Route broad market research, product positioning, or category strategy elsewhere.
   • When at least two independent comparable LPs need inspection and parallel capacity is available, assign at most three read-only checks in parallel without waiting for an explicit delegation request. Give each check the same structure checklist, prohibit repository writes, and synthesize all results before editing.
   • Keep a single LP, tightly coupled design decisions, and all repository changes with one owner; do not delegate merely to create activity.
   • Synthesize references into a small set of usable decisions: section archetype, proof mode, CTA rhythm, first-screen visual proof, and SEO posture.
   • Do not copy a reference page's styling wholesale; adapt only patterns that support the current offer and repository constraints.

3. Inspect the current implementation surface.

   • Find the existing route, page, layout, styling system, component conventions, and asset locations.
   • If no landing page exists yet, choose the smallest credible web surface that fits the repository.
   • Preserve established framework and styling patterns unless they block the page goal.

4. Define the conversion structure before editing.

   • Decide the section order, usually some subset of: hero, first-screen proof, problem, value proposition, product or output proof, trust, feature or benefit blocks, objection handling, CTA, FAQ, and footer.
   • Make the message hierarchy explicit: headline, subhead, supporting proof, and CTA text.
   • Pick the structure that matches buyer intent: workflow lifecycle, build path, product surface map, customer outcome story, platform taxonomy, or compliance/trust path.
   • Remove or de-emphasize sections that distract from the main action.

• Make the smallest targeted fix, then rerun the affected browser, build, CTA, responsive, motion, or SEO check.
• Stop after three failed repair attempts or two repeats of the same failure with a blocker note.

11. Hand off clearly.

• Summarize the audience, CTA, and section logic that shaped the page.
• State the chosen proof mode and any reference-derived patterns used.
• State the dynamic visual approach and any reduced-motion or responsive assumptions.
• State the chosen SEO posture and any metadata or indexing assumptions.
• Report what was implemented, what was assumed, and what remains unverified.
• If the work expands into brand system design, route to brand-designer. If it becomes artifact-only restyling, route to artifact-theme-applier.

Output Expectations

• A working LP change in the repository, or a concrete blocker report
• The primary audience and CTA the page was optimized around
• The section structure and key messaging choices
• The proof mode, first-screen proof, and any reference patterns applied
• The dynamic visual approach when relevant, including motion role, layered visual treatment, and reduced-motion handling
• The chosen SEO posture and essential metadata decisions
• Validation performed, especially responsive, CTA-path, and SEO-minimum checks
• Any assumptions made for missing copy, assets, proof, or analytics details

Guardrails

• Do not treat a landing page like a generic app feature or dashboard screen.
• Do not overload the page with multiple competing CTAs unless the user explicitly wants that tradeoff.
• Do not drift into broad brand strategy, market research, or campaign planning.
• Do not add heavy dependencies or a new frontend stack for a single LP unless the user explicitly asks for it.
• Do not skip the index or noindex decision, metadata basics, or heading structure just because the page is conversion-focused.
• Do not stop at visual polish if the CTA flow, hierarchy, or copy structure is still weak.
• Do not use decorative visuals as a substitute for product proof, output examples, customer outcomes, or trust evidence.
• Do not add complex animation, canvas, video, or 3D when CSS transitions, static product proof, or a simple interaction would communicate the same value more reliably.