Landing page structure
Skill Paldom/landing-page-builder-skills/skills/landing-page-structure
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.From its SKILL.md
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.
SKILL.md
5.4 KB, ~1.2k tokens by cl100k_base, 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.
What ships with it: 2 files
9.1 KB alongside SKILL.md
evals/
- evals.json3.8 KB
references/
- structure-patterns.md5.3 KB