agentleFS
SkillMedevSkillMedev/solo-founder-stack/skills/landing-page-copy/SKILL.md

landing-page-copy

Skill0 starsChanged 39 days agoMITView on GitHub

Write landing-page copy section by section - hero, social proof, features-as-benefits, objections, CTA - leading with one promise and proving it down the page. Use when someone asks "write my landing page", "improve my hero headline", "what should the homepage say", "turn these features into benefits", or is shipping a new page for a launch or campaign. Do NOT use for testing and optimizing an existing page's conversion rate - use landing-page-cro instead; for the one-line claim itself use positioning-statement; for the full message ladder use messaging-hierarchy.

14 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use direct-response-copy.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MoizIbnYousafSkill

    direct-response-copy

    Write copy that converts. Use when writing landing pages, emails, sales copy, headlines, CTAs, social posts, cold emails, or any persuasive text. Triggers on 'copy', 'copywriting', 'sales copy', 'landing page copy', 'cold email', 'headlines', 'write me a page', 'make this convert', 'rewrite this copy', or any request involving persuasive writing. Three modes: Generate (write from scratch), Edit (improve existing copy with Seven Sweeps), Cold Email (outbound sequences). If someone has text that needs to sell harder, this is the skill.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 10 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write top to bottom in the order below, because each section answers the objection the previous one created: the hero makes a claim, proof …

    line 14
  2. Distinctive:

    Write to one person, in second person ("you").

    line 51
  3. Distinctive:

    Read the headline and CTAs aloud.

    line 55
  4. Distinctive:

    Do not lead with the company or the category ("Acme is a platform for…") - lead with the reader's outcome.

    line 87
  5. Distinctive:

    Do not make two promises in the hero.

    line 88
  6. Distinctive:

    Do not use "Submit", "Learn more", or "Get started" without value attached - the button copy is the last thing read before the decision.

    line 89
  7. Distinctive:

    Do not invent testimonials or numbers.

    line 90
  8. Distinctive:

    Do not bury proof below the fold while the claim sits at the top unsupported.

    line 91
  9. Distinctive:

    Do not A/B-test or restructure an existing page here - that diagnosis-first loop belongs to landing-page-cro.

    line 92
  10. Distinctive:

    Every feature line finishes a "which means…" that lands on the reader.

    line 97

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Landing Page Copy

A landing page makes one promise and spends the rest of the page making it believable. The costly mistake this skill prevents is the clever-but-vague page: paid traffic arrives, reads "Supercharge your workflow," and bounces before learning what the product does. Clarity outsells cleverness, and the reader decides in the first five seconds whether to give you thirty more.

Operating procedure

Write top to bottom in the order below, because each section answers the objection the previous one created: the hero makes a claim, proof makes it credible, benefits make it concrete, objections clear the residue, and the CTA collects.

Step 1: Gather inputs

  1. The one promise - the single outcome the page sells. If the user offers three, make them pick one; the others become body copy. If no positioning exists yet, route to positioning-statement first.
  2. The ICP and the pain in their own words (support tickets, sales calls, reviews - not the founder's paraphrase). Label paraphrases as guesses.
  3. The real alternative (spreadsheet, incumbent, doing nothing).
  4. Available proof: testimonials, logos, numbers, screenshots. Default: if none exists, use specificity of mechanism as interim proof and flag the gap.
  5. The one action the page asks for (trial, demo, waitlist) and what happens after the click.
  6. Where traffic comes from - the page must echo the promise of the ad or post that sent them (message match; optimizing this loop afterward is landing-page-cro).

Step 2: Write the hero

  • Headline: the core promise in plain language - the outcome, not the feature. Test: a stranger knows what they get within 5 seconds. Under 10 words.
  • Subhead: who it's for and how it works, in one sentence.
  • CTA button: a verb plus the value ("Start free", "Get the template") - never "Submit" or "Learn more".
  • Supporting visual: show the outcome or the product doing the promise, not an abstract illustration.

Bad hero: "Unlock the power of intelligent automation" / "Our AI-driven platform revolutionizes how modern teams work" / [Learn More] - no outcome, no audience, three buzzwords, a CTA that promises homework.

Good hero: "Send client reports in 5 minutes, not 5 hours" / "ReportKit pulls your agency's campaign data into white-label reports automatically - no spreadsheets" / [Start free - first report in 5 minutes] - outcome with a number, names the audience and mechanism, CTA restates the value.

Step 3: Place social proof immediately under the hero

A logo strip, a usage number, or one strong quote - proof belongs right after the claim, while skepticism is highest. Specificity beats volume: one named customer with a result ("cut reporting time 80% - Dana K., Brightside Agency") outperforms five anonymous star ratings.

Step 4: Write the body in order

  1. Problem - name the pain in the reader's own words; they should think "that's exactly it."
  2. Solution - how the product removes it, framed as outcomes.
  3. Features as benefits - for each feature, complete "which means…" until it lands on the reader's life: "encrypted backups" becomes "you never lose your work." Cut any feature that can't finish the sentence. Three to five, each with a concrete detail.
  4. Deeper proof - testimonials with names and outcomes, screenshots, numbers.
  5. Objections - answer the top 2-3 hesitations plainly (price, migration effort, security, "will this work for my case"), pulled from real sales conversations.
  6. Repeat CTA - same action, same wording as the hero button, now that they're convinced. Optionally add a friction-reducer line beneath ("No credit card. Cancel anytime.").

Step 5: Edit pass

  • Write to one person, in second person ("you"); no first person.
  • Specific beats grand: "set up in 3 minutes" beats "incredibly easy."
  • Cut adjectives; let the proof carry weight. Delete every "powerful", "seamless", "revolutionary".
  • One promise per section; every section moves the reader one step closer to the CTA - cut any that doesn't.
  • Read the headline and CTAs aloud; anything that sounds like marketing rather than a person gets rewritten.

Page skeleton template

HERO
  Headline: [FILL: outcome promise, <10 words]
  Subhead:  [FILL: who it's for + how it works, 1 sentence]
  CTA:      [FILL: verb + value]

PROOF BAR: [FILL: logos / usage number / 1 named quote]

PROBLEM:   [FILL: the pain, in the customer's own words, 2-3 sentences]
SOLUTION:  [FILL: how it's removed, outcome-framed, 2-3 sentences]

BENEFITS (3-5):
  - [FILL: feature] - which means [FILL: outcome for the reader]

DEEP PROOF: [FILL: 1-2 named testimonials with results / screenshot]

OBJECTIONS (2-3):
  - "[FILL: hesitation]" - [FILL: plain answer]

FINAL CTA: [FILL: same verb + value as hero]  [FILL: friction reducer]

Deliverable

Produce a complete page draft in the skeleton order - hero (headline, subhead, CTA), proof bar, problem, solution, 3-5 features-as-benefits, deep proof, objection answers, and repeat CTA - plus a one-line note of the weakest proof point to strengthen before scaling traffic.

Do NOT

  • Do not lead with the company or the category ("Acme is a platform for…") - lead with the reader's outcome.
  • Do not make two promises in the hero; a visitor who must choose chooses to leave.
  • Do not use "Submit", "Learn more", or "Get started" without value attached - the button copy is the last thing read before the decision.
  • Do not invent testimonials or numbers; flag missing proof instead - fabricated proof is a trust and legal liability.
  • Do not bury proof below the fold while the claim sits at the top unsupported.
  • Do not A/B-test or restructure an existing page here - that diagnosis-first loop belongs to landing-page-cro.

Quality bar

  • A stranger can say what the product does, who it's for, and what to click within 5 seconds of seeing the hero.
  • Every feature line finishes a "which means…" that lands on the reader.
  • At least one piece of proof is specific (name, number, or screenshot).
  • Zero unearned adjectives; every claim is either proven or concrete.
  • The page's promise matches the ad or post sending the traffic.

Escalation

Route conversion testing of the live page to landing-page-cro, the one-line claim to positioning-statement, the promise/pillars/proof ladder to messaging-hierarchy, and launch scheduling of the page to launch-plan-sequencer.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.