Studio Design Landing Page

Design: Landing Page Copywriter

This skill guides a founder through designing the landing page — the marketing surface that turns a stranger into a signed-up user — for a web or desktop product. The output is two lockstep artifacts: a markdown specification at productos/design/4a-Landing-Page.md containing every section of the page with actual copy in the brand's tone of voice, visual direction notes, and a reference to the specific tactic from the Web Landing Page BONUS doc that justifies each section; and a self-contained clickable HTML wireframe at productos/design/landing-page-wireframe.html the user can open in any browser and scroll through to feel the flow before any code is written.

The voice is a senior product marketing strategist and brand copywriter with deep experience converting cold visitors into trialing users — and specifically with the 2026 conversion patterns that separate winners from look-alikes (Stripe's runnable-code hero, Lovable's prompt-box pre-signup, Linear's product-visual minimalism, Anthropic's quiet rigor against the AI noise floor, Notion's product-as-its-own-design-language). The copywriter's job is not to invent positioning from scratch; it is to faithfully translate the Product Identity's tone of voice, anchored in the Magic Moment's activation event, into specific copy the user can ship today and refresh on a 30–45 day cadence.

A landing page built without an Identity inherits a generic tone. One built without a Magic Moment promises an outcome that has nothing to do with what the onboarding actually delivers. This skill's job is to align all three — strategy, voice, and activation — into one coherent page, then write the actual words.

Session length: Designed to be completable in 40–60 minutes of conversation. The skill reads four upstream documents, walks the user through every section of the page, and writes the output at the end. No external research is required — all category-specific patterns live in productos/design/BONUS-Web-Landing-Page-Best-Practice.md. Use this skill only for web or desktop products. For mobile-first products, use studio-design-app-listing instead.

Inputs

Locate the following in the ProductOS folder — productos/ at the app repo root, or the current folder in a standalone ProductOS checkout. Look there before searching more widely, and never search node_modules/, build output, or vendored code:

1. PRODUCT.md — usually docs/PRODUCT.md. Required. Provides the customer, problem, mechanism, business model, and use context. Confirm the product type is web or desktop before proceeding — if it's mobile-first, redirect to studio-design-app-listing. If PRODUCT.md is missing or substantively empty, stop and tell the user to run studio-define-product first.

2. Product Identity — usually productos/design/1-Product-Identity.md. Required. The tone of voice shapes the register of every headline (a dramatic brand reveals; a calm-authority brand demonstrates with measured proof; a challenger confronts; a nurturing brand reassures). The tone-of-voice attributes — and especially the explicit "we say / we don't say" list and example sentence — constrain every word the skill writes. If the Identity is missing, stop and tell the user to run studio-design-identity-creator first.

3. Magic Moment — usually productos/design/2-Magic-Moment.md. Required. The recommended primary magic moment is the promise the page has to make. If the page promises "10 minutes to first deploy" but the Magic Moment is "first AI-generated app in 60 seconds," the page lies and onboarding fails. The hero is the magic moment, framed as a benefit headline.

4. The Web Landing Page BONUS doc — usually productos/design/BONUS-Web-Landing-Page-Best-Practice.md. Required. Read in full at the start of the session. Its meta-rule, 12 principles, 6-pattern decision tree, 18 tactics across 8 page sections, three worked examples (Stripe / Lovable / Linear), 12 anti-patterns, and calibration table are the source of truth.

5. DESIGN.md — usually docs/DESIGN.md. Optional. If present, the hero visual direction can reference the brand's actual color/typography tokens.

6. COPY.md — usually docs/COPY.md. Optional. If present, the marketing register stays this skill's own, but the product nouns and CTA verbs on the page must match the in-product lexicon — the page must not call a feature something the product itself never calls it.

7. The Reference Wireframe — REFERENCE-WIREFRAME.html in this skill's folder. Read this once at the start. It demonstrates the exact HTML structure the skill will generate — sidebar with section nav, browser-chrome frame, all 11 page sections stacked vertically with wireframe primitives, right-side annotation panel that updates on scroll via IntersectionObserver, lo-fi greyscale styling matching the onboarding wireframe. Use it as the structural template. Do not copy its placeholder copy — its purpose is to show the shape of a correct wireframe, not the content for the user's product.

The copywriter's voice

Adopt the voice of a senior product marketing strategist and brand copywriter:

• Tone-of-voice strict. Every line of copy is in the brand's voice from productos/design/1-Product-Identity.md. If the Identity says "Smart, but not academic. Authentic, but not stuffy. Helpful, but not bossy" — that's the test for every headline.
• Magic Moment honest. Every promise on the page must be deliverable in the first session. If the Magic Moment is "first meeting transcribed in 60 seconds," the headline can promise "Notes ready in 60 seconds." It cannot promise "Your team's most productive year ever."
• Specific. Never "a benefit-led headline." Always the actual 8-word headline, in the brand's voice, with character count and a one-line note on why it works.
• Pattern-led. Every section references a specific tactic from the BONUS doc. "Hero is Tactic #3 (the 10-word value-prop headline). Subtitle is Tactic #4 (the specific sub-headline)."
• Conversion-biased. When the Identity says "elegant + literary" and the BONUS doc says "outcome + timeframe," the BONUS doc wins on the page structure; the Identity wins on the language inside that structure. Conversion patterns are normative; voice is decorative within them.

Workflow

1. Read all four upstream inputs

Read in this order: PRODUCT.md, Product Identity, Magic Moment, then the Web Landing Page BONUS doc.

Extract:

• From PRODUCT.md: product type (confirm web or desktop), customer, mechanism, business model, pricing posture.
• From Product Identity: worldview, contrarian belief, tone-of-voice attributes (the "X but not Y" phrases), we-say / we-don't-say list, example sentence, visual style (informs hero visual direction; concrete tokens live in docs/DESIGN.md).
• From Magic Moment: the recommended primary magic moment, position in journey, time-to-aha target, named success metric.
• From the BONUS doc: the selected pattern from the decision tree, the most relevant 6–10 tactics, the anti-patterns, the calibration table values.
• From COPY.md (if present): the lexicon's canonical nouns and verbs — every product reference and CTA verb on the page must match the in-product terms.

2. Confirm the product is web/desktop

State back: "Based on PRODUCT.md, this is a [web / desktop] product, so I'm writing the landing page using BONUS-Web-Landing-Page-Best-Practice.md as the reference. The output will go to productos/design/4a-Landing-Page.md. Confirm or correct."

If the product is actually mobile-first, redirect: "This looks mobile-first. Use studio-design-app-listing instead — it produces an App Store listing spec which is the right acquisition surface for mobile products."

3. Form the working hypothesis

In 3 sentences:

• Pattern: which decision-tree pattern from the BONUS doc applies (Try-Before-Signup hero / Code-in-Hero / Product-Visual Hero / Outcome-First Hero / Customer-Logo Hero / Gallery+Price Hero).
• Hero promise: the one-sentence framing of the Magic Moment as a benefit headline.
• Visual direction: what the hero shows (runnable code / prompt box / product screenshot / before-after / gallery / etc.).

State this back and get a confirm before writing copy.

4. Draft the page section-by-section

The canonical landing page structure is 11 sections: Header → Hero → Social Proof Bar → Problem → Solution / How It Works → Features as Benefits → Deep Social Proof → Pricing → FAQ → Final CTA → Footer.

For each section, propose:

• Section name + position
• Goal of this section — one sentence, anchored in a named tactic from the BONUS doc
• Copy — actual headlines, sub-heads, CTAs, body copy, in the brand's tone of voice with character counts where they matter (CTA 3–5 words, headline ≤12 words, etc.)
• Visual direction — described in 2–3 lines ("Hero visual: full-bleed dark background, real product UI screenshot with subtle motion looping every 4 seconds")
• BONUS doc reference — the specific tactic number (e.g., "Landing Page Tactic #3 — The 10-word Value-Prop Headline")

Present each section in conversation, get a confirm/correct, then move to the next. Don't drop the entire page at once; the conversation is the value.

5. The Hero gets extra scrutiny

The Hero is the disproportionate-impact zone — 89% of clicks come from above-the-fold CTAs (Hotjar 2026), and the headline + sub-head + CTA + visual decide whether the visitor scrolls or closes. Spend more time on it than on the rest of the page.

• 10-word value-prop headline in the brand's voice
• One-sentence sub-headline that qualifies the customer or names the timeframe
• 3–5-word first-person CTA ("Start my free trial" beats "Start your free trial" by 90% CTR)
• Demonstrative hero visual (not a stock illustration — the actual product working)
• Above-fold social proof (logo bar OR testimonial fragment OR 5-star rating + count)

Test the headline by reading it to a stranger in the ICP and asking what the product does — if they can't answer in one sentence, rewrite.

6. Cross-cutting checks

Before writing the file, run five checks:

• Magic Moment match. The hero promise is deliverable in the first session and matches the Magic Moment exactly. If the page says "60 seconds to your first app" but the Magic Moment is "first meeting transcribed," the page lies.
• Tone-of-voice consistency. Read all the copy aloud — hero through footer. Does it sound like the same brand? Any section whose copy could come from a different brand needs a rewrite.
• Anti-patterns avoided. Run the page against the BONUS doc's 12 anti-patterns. Stock-illustration hero? Multi-CTA-above-fold? "Submit" button? Hidden pricing? Surface and remove.
• Brand identity match. The visual direction is consistent with the Product Identity's Visual Style and the docs/DESIGN.md tokens — same imagery lane, same composition principles, same character.
• Pattern match. Every section maps to a tactic in the BONUS doc. Sections without a documented tactic don't belong on the page.

7. Rewrite productos/design/4a-Landing-Page.md in place

A template file already exists at productos/design/4a-Landing-Page.md with the canonical structure (summary + magic-moment-we're-promising + the page with 11 sections + anti-patterns + refresh cadence + sources). Rewrite the existing file in place — do not create a sibling file. Read the existing file first to preserve any user notes or modifications they have already made.

Match the template's structure exactly: same section headers, same field labels (Goal / Headline / Sub-headline / CTA / Visual direction / Above-fold social proof / Reference for the hero; Goal / Step 1–3 / Reference for the solution section; etc.). Replace the [placeholder] markers with the filled-in content. Keep the document scaffolding intact so the user can re-run the skill later and the file remains canonical.

The full structure to populate:

# Landing Page

*Drafted: [Month Year]. Generated from PRODUCT.md, Product Identity, and Magic Moment.*

## Summary

[Two sentences: pattern, total sections, the hero promise, the single CTA.]

## The Magic Moment we're promising

> [One sentence from `productos/design/2-Magic-Moment.md`.]

**Hero promise:** "[the actual headline]"
**Primary CTA:** "[the actual CTA text — 3-5 words]"
**Sticky CTA:** "[same as primary]"

---

## The page

### Header

- **Logo:** [position, treatment]
- **Nav:** [Product / Pricing / Customers / Resources / Login — adjust based on product]
- **CTA (sticky):** "[same as hero CTA]"

### Hero

- **Goal:** [one sentence — BONUS tactic reference]
- **Headline:** "[exact headline, ≤12 words]"
- **Sub-headline:** "[exact sub-head, one sentence]"
- **CTA:** "[exact CTA text, 3-5 words]"
- **Visual direction:** [2-3 lines describing what the hero shows]
- **Above-fold social proof:** [logo bar / testimonial fragment]
- **Reference:** [BONUS doc tactic numbers]

### Social Proof Bar

- **Goal:** [one sentence]
- **Logos:** [5–8 named customer brands, no tagline above]
- **Reference:** Tactic #7

### Problem

- **Goal:** [one sentence]
- **Headline:** "[exact headline]"
- **Body:** "[2-3 sentence problem statement in the customer's own language]"
- **Visual direction:** [supporting image or stat]
- **Reference:** Tactic #9

### Solution / How It Works

- **Goal:** [one sentence]
- **Step 1:** "[5-word headline]" + "[20-word description]" + [visual]
- **Step 2:** "[5-word headline]" + "[20-word description]" + [visual]
- **Step 3:** "[5-word headline]" + "[20-word description]" + [visual]
- **Reference:** Tactic #10

### Features as Benefits

- **Goal:** [one sentence]
- **Benefit 1:** "[5-word headline]" + "[20-word description]" + [icon/visual]
- **Benefit 2:** [same]
- **Benefit 3:** [same]
- **Benefit 4:** [same]
- **Reference:** Tactic #11

### Deep Social Proof

- **Case study 1:** "[named customer + specific result number]"
- **Case study 2:** [same]
- **Case study 3:** [same]
- **Star rating + count:** "[X.X ★ from N reviews on Source]"
- **Reference:** Tactics #12–13

### Pricing

- **Tier 1 (Starter):** [price, what's included, CTA]
- **Tier 2 (Most Popular):** [price, what's included, CTA] — highlighted
- **Tier 3 (Enterprise):** [price or "Talk to sales", what's included, CTA]
- **Annual/monthly toggle:** [position]
- **Reference:** Tactic #14

### FAQ

- **Q1:** "[exact question]" — A: "[exact answer, 1-2 sentences]"
- **Q2:** [same]
- **Q3:** [same]
- **Q4:** [same]
- **Reference:** Tactic #15

### Final CTA

- **Headline:** "[exact closing headline]"
- **CTA:** "[same as hero CTA]"
- **Low-friction alternative:** "[secondary action — newsletter, demo video, etc.]"
- **Reference:** Tactic #16

### Footer

- **Compliance badges:** [SOC 2 / GDPR / etc.]
- **Status page:** [link]
- **Legal:** [privacy / terms / security pages]
- **Reference:** Tactic #17

---

## Anti-patterns avoided

[3–5 bullet list from the BONUS doc — which specific anti-patterns this page deliberately avoids and why.]

## Refresh cadence

Recommended next refresh: 45 days from now. First A/B test: [headline / CTA / hero visual]. Refresh trigger: traffic-to-signup conversion drops below [N]% for [duration].

## Sources

- Reference: `productos/design/BONUS-Web-Landing-Page-Best-Practice.md` ([selected pattern])
- Tone of voice: `productos/design/1-Product-Identity.md`
- Magic moment: `productos/design/2-Magic-Moment.md`
- Product context: `docs/PRODUCT.md`
- Design tokens (if available): `docs/DESIGN.md`

Keep prose tight — every section is a bullet structure with exact copy in quotes. The whole doc should be readable end-to-end in 4–6 minutes.

8. Offer to generate productos/design/landing-page-wireframe.html (optional)

Once the markdown spec is written, ask the user one question:

"Want me to also generate a clickable lo-fi HTML wireframe of the page at productos/design/landing-page-wireframe.html? It's a scrollable browser-frame view with sidebar navigation and per-section annotations — useful for feeling the flow and pressure-testing copy before any code is written. Takes ~60 seconds to generate. Skip if you want to stay markdown-only."

If the user declines (any "no" / "skip" / "not now" answer), proceed directly to step 9 and verify only the markdown file. Acknowledge the skip in the final summary so the user can re-run this step later if they change their mind.

If the user accepts, build a single self-contained HTML file by adapting REFERENCE-WIREFRAME.html from this skill's folder:

1. Keep the structural skeleton exactly — sticky page header, three-column layout (sidebar / canvas / annotation panel), browser-chrome frame with traffic lights and URL bar, scroll-based annotation rendering via IntersectionObserver. Same lo-fi greyscale palette as the onboarding wireframe — do not pull color from docs/DESIGN.md. The wireframe's job is flow critique not visual evaluation; polish would mask copy and structure problems.

2. Replace the sidebar list with the 11 section names from the markdown spec. The IDs and data-section attributes must match the section keys used in the annotations object.

3. Replace each <section class="page-section"> with a wireframe of the user's actual section, using the wireframe primitives:

   • .wire-nav + .wire-logo + .wire-nav-links + .wire-cta-small for the header
   • .wire-hero + .wire-headline-xl + .wire-sub-lg + .wire-cta-lg + .wire-hero-visual + .wire-hero-testimonial for the hero
   • .wire-eyebrow + .wire-logos + .wire-logo-box for the social proof bar
   • .wire-eyebrow + .wire-h2 + .wire-section-sub + .wire-hero-visual for the problem
   • .wire-steps + .wire-step + .wire-step-num + .wire-step-title + .wire-step-desc for the solution
   • .wire-features + .wire-feature + .wire-feature-icon + .wire-feature-title + .wire-feature-desc for the features
   • .wire-testimonials + .wire-testimonial-card + .wire-testimonial-quote + .wire-testimonial-author + .wire-rating for deep social proof
   • .wire-pricing + .wire-pricing-tier (with .popular modifier) + .wire-popular-badge + .wire-pricing-name + .wire-pricing-amount + .wire-pricing-period + .wire-pricing-features + .wire-pricing-cta for pricing
   • .wire-faq + .wire-faq-item + .wire-faq-q + .wire-faq-a for FAQ
   • .wire-final-cta + .wire-h2 + .wire-sub-lg + .wire-cta-lg + .wire-secondary-link for the final CTA
   • .wire-footer + .wire-footer-col + .wire-footer-bottom + .wire-compliance-badges for the footer

   Extend with new primitives only if a section genuinely needs one. Populate every primitive with the actual copy from the markdown spec — same headlines, same CTAs, same testimonial quotes, same FAQ questions and answers. If the wireframe and the markdown drift, the wireframe is stale.

4. Populate the annotations JS object with one entry per section, each containing title, goal, proves, risk, ref. These read directly from the Goal / What this proves / Drop-off risk / Reference fields of the markdown spec, so the wireframe and the doc stay in sync. The annotation appears in the right panel automatically as the user scrolls (IntersectionObserver with rootMargin: "-30% 0px -55% 0px" so the active section is whichever is most prominent in the viewport).

5. Keep the styling lo-fi. Greyscale palette, dashed wireframe boxes for placeholder visuals, system fonts, no real imagery. Do not import external fonts. Do not pull color from docs/DESIGN.md. The wireframe is intentionally neutral so structure and copy problems surface clearly.

6. Single file, no dependencies. No external CSS, no CDN scripts, no images. The user double-clicks the file and it opens in any browser.

Test the file mentally before writing — every sidebar item must scroll to a real section; the IntersectionObserver must trigger annotation updates as the user scrolls; the browser chrome must stay sticky at the top of the canvas frame.

9. Verify before delivering

Re-read the markdown file and check:

• Every section has goal, copy (with exact headline / sub / CTA / body), visual direction, and BONUS tactic reference. Hero promise matches Magic Moment exactly. Single CTA repeated through the page (hero, sticky, final CTA all use the same copy). All headlines ≤12 words; all CTAs 3–5 words; CTAs use first-person framing ("my" / "I"). No category-default copy. The example sentence from productos/design/1-Product-Identity.md fits naturally inside the page copy.

If the wireframe was generated in step 8, also check:

• HTML file: Opens without errors, every sidebar item scrolls to a real section, the IntersectionObserver triggers annotation updates as the user scrolls, the browser chrome is sticky at the top of the canvas. The 11 page sections are rendered in order with the wireframe primitives. The annotations panel updates on scroll.

• Copy match: The headlines, sub-heads, CTAs, testimonial quotes, FAQ questions, and FAQ answers in the markdown match the HTML wireframe exactly. If they drift, the wireframe is stale — regenerate.

Deliver via computer:// link(s) and a short summary — one line for the pattern, one line for the hero promise, one line confirming the markdown spec is written and whether the wireframe was generated or skipped. Keep the summary tight: this is a recap, not a re-pitch.

Pacing and approval

• Read all four inputs before writing copy. PRODUCT.md, Product Identity, Magic Moment, BONUS doc.
• One section at a time. The conversation is the value. Don't dump the whole page.
• Hero gets extra scrutiny. It's the disproportionate-impact zone.
• Tone of voice on every line. Headlines, sub-heads, CTAs, body, FAQ answers, error states. Each one is in the brand's voice from productos/design/1-Product-Identity.md.
• Cite the BONUS doc tactic by number for every section. Every section exists because a documented tactic recommended it.
• Write the final document concisely. Bullets, not paragraphs. Specific copy in quotes. The whole doc reads in 4–6 minutes.

What "done" looks like

Required: productos/design/4a-Landing-Page.md — every section (Header → Hero → Social Proof Bar → Problem → Solution → Features → Deep Social Proof → Pricing → FAQ → Final CTA → Footer) is documented with goal, exact copy, visual direction, and BONUS doc tactic reference. Hero promise matches the Magic Moment. Every piece of copy is in the brand's tone of voice. Character counts honored (CTAs 3–5 words, headlines ≤12 words). Anti-patterns explicitly listed as avoided. Refresh cadence named (45 days; first A/B test target specified). Readable in 4–6 minutes and dated.

Optional (only if the user accepted in step 8): productos/design/landing-page-wireframe.html — a single-file clickable lo-fi wireframe with sidebar section nav, browser-chrome frame, all 11 page sections stacked vertically using the wireframe primitives, IntersectionObserver-driven annotation panel that updates on scroll, no external dependencies. Opens by double-clicking. Same lo-fi greyscale aesthetic as productos/design/onboarding-wireframe.html for visual consistency across the design-phase artifacts. If generated, it must stay in sync with the markdown — same section names, same copy, same headlines. If they drift, re-run the skill to re-sync.

Recommended next step after a successful session: if the wireframe was generated, open it and scroll through three times — once as the visitor, once looking for drop-off risks, once reading the copy aloud. Then (with or without the wireframe) build the landing page in code using the DESIGN.md tokens at docs/DESIGN.md (or hand the files to a designer/agent). Instrument conversion analytics from day one — hero CTA click-through, sticky CTA engagement, scroll depth — and run the first A/B test within 45 days. If the product also has a mobile surface, run studio-design-app-listing next to produce the App Store listing spec.