Landing page structure
Skill Paldom/landing-page-builder-skills/skills/landing-page-structure
Agent Skills for building high-converting, modern, performant landing pages: design tokens, conversion copywriting, marketing UX, layout patterns, Next.js/React + shadcn implementation, scroll motion, and performance/SEO/accessibility.
npx -y skills add Paldom/landing-page-builder-skills --skill landing-page-structureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Designs the section skeleton of a marketing landing page - the page as one sequenced argument, hero anatomy, section ordering, form-field count, and CTA/proof placement. Use when the user asks how to structure, lay out, sequence, or wireframe a landing page, which sections to include, or how many form fields. Not for the words/copy, visual styling, animation, or code.
SKILL.md
5.4 KB, as published. Nobody here has run it
landing-page-structure
Structure a landing page as one argument, not a stack of default sections.
The failure this fixes
Asked to build a landing page, a model drops in a reorderable stack of default sections - hero, feature grid, testimonials block, pricing, FAQ, footer - in template order, with no argument connecting them. The tells: proof exiled to a lone "What our customers say" section (or the footer) instead of sitting next to the claim it backs; a hero carrying three or four competing CTAs; a uniform icon-row feature grid; and a 9-11-field form because the fields were available, not needed. It passes visual inspection but has no story - you can shuffle the sections without hurting comprehension, which proves it is parts, not a sequence.
When to use / when NOT to use
Use for the skeleton: which sections exist, in what order, the hero's internal anatomy, form-field decisions, and where CTAs and proof go.
Not for: the words in those sections (landing-page-copywriting), palette/type
(visual-design-system), motion between sections (scroll-motion), building the
sections in code (nextjs-landing-page), or testing variants
(landing-page-experimentation).
Workflow
- State the one argument. Before placing any section, write the page's single claim and its support as a sentence: problem → stakes → mechanism → proof → CTA. Sections exist to advance that argument; features are narrated inside it, never dumped as a standalone grid.
- Lay out the hero (first screen). It must answer four questions without scrolling: what is this, who is it for, why trust it, what do I do next - i.e. one benefit headline, one supporting subhead, ONE primary CTA, one trust cue (a specific number, one review, or one known logo), and a real product shot (screenshot / short muted loop / interactive demo), not stock art. The majority of visitors never scroll past this screen (cited figures ~57% desktop / ~64% mobile - directional, not a guarantee).
- Sequence the body. Order sections as the argument, with proof adjacent to
each claim. Use a canonical spine (
references/structure-patterns.md) and adapt - do not ship the default order unexamined. Scale length to purchase risk: ~5-7 sections for simple/low-consideration offers, ~10-12 for high-ticket B2B (more objection-handling, dual-stage CTA). - Place CTAs and proof. One primary action, repeated every ~400-600px and once more at the bottom (final CTA carries reassurance microcopy); at most one lower-friction secondary action; sticky/floating CTA on mobile. Cap distinct proof types at 3-5; never centralize all proof in one block or the footer.
- Design forms for the lowest necessary friction. Default ~3 fields B2C,
~4-5 B2B; single-step under ~5 fields, multi-step at 5+ or genuine
conditional logic; capture email on step one so abandonment still yields a
lead. Details:
references/structure-patterns.md. - Run the reorder test. If the sections can be shuffled without hurting comprehension, there is no argument - fix ordering before adding anything.
The rules
- The page is one sequenced argument, not a section list. Out-of-expected order (pricing before the problem, features before trust) imposes "reconciliation cost" that kills scroll momentum.
- Hero answers the four questions in the first screen - one headline, one subhead, one primary CTA, one trust cue, real product shot.
- One primary CTA, repeated - not multiple competing CTAs. A single soft secondary ("Watch 2-min tour") is fine; three co-equal buttons is the anti-pattern. Sticky CTA and above-fold CTA do not stack additively.
- Proof goes adjacent to the claim it supports and to the decision point (beside the CTA, the form, the pricing) - not centralized, not in the footer (footer proof ≈ no proof).
- Form field-count discipline. Field count is the highest-leverage, most-replicated form lever; below ~5 fields, sequencing beats subtraction. Match length to traffic intent (cold → minimal, warm/high-intent → progressive profiling).
- Bento grid is for feature density, not personality. Use it for a multi-feature product's features/proof section with a clear anchor cell (~2x the next largest), 5-9 cells, and a mobile re-prioritization pass. Skip it for a single dominant offer - use a linear sequence.
- Above the fold is a trust signal, not a literal boundary. What matters is whether the first screen instantly establishes relevance and message match.
Output
A section list in order (each section named with its job in the argument), the hero's internal layout, CTA and proof placements, and form-field decisions - plus the reorder-test verdict. Words, styling, motion, and code are deferred to their sibling skills.
References
references/structure-patterns.md- canonical section-order spines (B2B SaaS, narrative CRO arc), hero-pattern-by-funnel-temperature, the form single-vs-multi-step decision, and the directional-vs-fact ledger.