back

landing-copy

Research, audit, or write evidence-backed landing-page messaging, proof, objections, and calls to action. Use when product, pricing, campaign, or waitlist pages need clearer positioning.

Category
marketing
Package
landing-copy/SKILL.md
License
MIT
Author
@tushaarmehtaa
Tags
copylanding-pagepositioningconversionheadlinesclaims

Install

Swipe for more runtimes.

Codex

Skills directory: ~/.agents/skills

Install globally

$npx skills add tushaarmehtaa/tushar-skills --skill landing-copy -g -a codex -y

Invoke

$landing-copy or /skills

You can also describe the task naturally; runtimes may select the skill from its description.

Required access

browser accessfiles you provide

Claude app

This workflow can run in chat using the files and context you provide. Download its complete ZIP, then upload it from Claude's Skills settings.

ChatGPT Skills

This workflow is suitable for ChatGPT Skills. ChatGPT does not document the same upload archive format as Claude, so follow its uploader instead of reusing the Claude ZIP.

ChatGPT upload guide →

Instructions

Source: SKILL.md

Landing copy

Build the page around a defensible buying claim and the evidence needed to evaluate it. Preserve an effective brand voice; do not force every product into terse, casual, benefit-first startup copy.

Choose the mode and page job

  • Positioning — find the claim, audience, alternatives, mechanism, and proof before page copy.
  • Audit — diagnose existing messaging and propose prioritized repairs.
  • Targeted rewrite — improve a hero, proof section, pricing explanation, objection, or CTA in context.
  • Generate — produce a complete page message architecture and copy deck.
  • Experiment — create variants that test one meaningful messaging hypothesis.

Identify the page job: category introduction, product selection, campaign response, feature evaluation, waitlist signup, pricing decision, or another explicit action. Determine traffic intent, buyer awareness, purchase risk, category maturity, and available proof from the brief, repository, customer language, analytics, or supplied research.

Ask only for missing facts that would change the claim, audience, offer, or legal truth. When facts remain unavailable, mark them as content requirements rather than inventing them.

Find the defensible claim

Read claim-first writing before positioning, generate mode, or any rewrite that changes the core proposition.

Document:

  • buyer and situation;
  • failure, cost, or unmet goal;
  • product capability and mechanism;
  • close alternatives and meaningful difference;
  • evidence, constraint, demonstration, or costly promise;
  • exact customer or domain language;
  • limits the page must not imply away.

Generate several plain claim shapes, then choose or recommend the one best supported by importance, specificity, differentiation, and proof. Confirm with the user only when choosing among materially different business promises; otherwise proceed with stated assumptions.

Audit the decision path

Evaluate the page as a sequence rather than scoring isolated ingredients:

  1. Can the intended buyer recognize the page is for their situation?
  2. Is the proposition understandable and important?
  3. Does the page explain or demonstrate how the product changes the outcome?
  4. Is differentiation visible where alternatives enter the decision?
  5. Does proof support the exact claim being made?
  6. Are price, trust, risk, compatibility, effort, and limitations handled near the decisions they affect?
  7. Does each CTA accurately describe the next step and commitment?
  8. Does the voice match the brand, audience, and stakes?

Report missing evidence separately from writing defects. Do not lower copy quality merely because the company has not supplied proof; identify the content gap and narrow unsupported claims.

Design the message architecture

Select only the sections required for this buying decision. Possible roles include:

  • proposition and next action;
  • product evidence or demonstration;
  • mechanism and capabilities;
  • comparison or alternatives;
  • proof and provenance;
  • use-case qualification;
  • pricing context and terms;
  • objections, limitations, security, or trust;
  • final decision support.

Section order follows reader questions and evidence, not a universal hero/features/testimonials/FAQ template. A familiar product with high-intent traffic may need little education; a new category or high-risk purchase may require mechanism, comparison, and proof before action.

Write without flattening the voice

Use concrete domain nouns, actions, mechanisms, constraints, and observable results. Keep technical detail when the buyer needs it. Use customer language when it is representative and accurately sourced.

Headline length, sentence length, feature-first versus benefit-first order, casing, contractions, fragments, humor, and punctuation are contextual choices. Reject filler and unsupported superlatives because they add no substance, not because individual words are universally banned.

Calls to action should make destination, result, or commitment clear in context. Conventional labels can be appropriate when surrounding UI makes them unambiguous. Do not manufacture urgency, scarcity, customer counts, rankings, or performance outcomes.

Read copy patterns and examples only when selecting a narrative framework, diagnosing a recurring copy failure, or designing an experiment. Treat patterns as options, not performance guarantees.

Design experiments honestly

Test one material hypothesis at a time, such as audience framing, problem versus outcome emphasis, mechanism visibility, proof placement, or commitment language. Keep offer, layout, and traffic stable when the goal is to attribute messaging impact.

State the hypothesis, primary measure, guardrail measure, audience, sample or runtime limitation, and decision rule. Do not predict arbitrary lift percentages.

Output contract

Audit or targeted rewrite

Page job and intended buyer:
Core claim and proof status:
Priority findings: [impact, evidence, and source location]
Before -> after: [for grounded repairs]
Content required: [missing facts, proof, or product decisions]
Preserve: [effective language or structure]
Verification and experiment recommendations:

Generate or positioning

Deliver:

  1. claim/evidence ledger;
  2. message architecture with the question each section answers;
  3. complete copy deck labelled by section and component;
  4. CTA destinations and commitment level;
  5. proof, asset, and content requirements;
  6. assumptions, excluded claims, and implementation notes;
  7. optional variants only when they test a stated hypothesis.

Verify

  1. Map every material claim to product behavior, a source, a scoped assumption, or an explicit content requirement.
  2. Run a competitor/alternative swap test on major propositions and explain any generic line retained.
  3. Trace the reader's likely questions through the section order; remove repeated promises that add no mechanism, proof, or decision support.
  4. Check price, security, privacy, compatibility, cancellation, implementation effort, and limitations where relevant to the offer.
  5. Confirm CTA text, destination, and actual commitment agree.
  6. Read the page aloud and compare it with established brand/customer language without normalizing every sentence into one cadence.
  7. Check terminology consistency across landing page, product UI, pricing, and documentation.
  8. Verify no proof, statistic, urgency, guarantee, or comparison was invented or broadened.
  9. For implemented copy, inspect responsive rendering, text overflow, links, analytics hooks, and accessible control names.
  10. Report what was verified directly and what still needs customer, legal, product, or analytics input.

Bundled references

2 files · 131 lines

references/claim-first.md

source ↗

Claim-first landing copy

Use this reference when positioning, generating a page, or changing its core proposition. Skip it for a bounded wording repair that leaves the claim intact.

Establish the claim

Extract evidence before writing headlines:

  1. What fails, costs more, or remains unavailable without the product?
  2. Who experiences that problem, in which situation and level of awareness?
  3. What product action or mechanism changes the outcome?
  4. What demonstration, number, customer fact, constraint, or guarantee can support it?
  5. What do close alternatives do and claim?
  6. What promise would constrain the company if published?
  7. Which buyer terms do outsiders commonly misuse?
  8. What limitation or qualification must remain visible?

Write the claim in deliberately plain language. Separate observation, product capability, interpretation, and expected outcome. Never strengthen the sentence by inventing proof or hiding a constraint.

Generate meaningful alternatives

Vary the strategic frame, not only wording:

  • name the existing loss or failure;
  • state the category and differentiator;
  • explain the mechanism;
  • describe an observable outcome;
  • qualify the buyer or use case;
  • make a costly, supportable promise;
  • challenge the dominant alternative with evidence.

Compare candidates on buyer relevance, specificity, differentiation, proof, comprehension, and business commitment. Recommend one and preserve credible runners-up for a real experiment only when the choice remains uncertain.

Apply the swap and proof tests

Replace the product with a close competitor. If the line survives unchanged, add the missing mechanism, constraint, buyer, evidence, or outcome.

For each material proposition, record:

Claim:
Product behavior or source:
Scope and limitation:
Proof available:
Proof missing:
Allowed wording:
Wording to avoid:

Use only the sections the decision requires. Missing proof becomes a content requirement or a narrower claim, never invented page copy.

references/guide.md

source ↗

Copy patterns and examples

Read this reference only when choosing a narrative framework, diagnosing a recurring copy failure, or designing a messaging experiment. These patterns organize evidence; they do not guarantee conversion.

Choose a narrative shape

Problem, cost, resolution

Use when the buyer recognizes the problem but underestimates its consequence. Name the real failure, establish its cost with evidence, then show how the product changes it. Do not manufacture agitation.

Current state, desired state, mechanism

Use when a before/after contrast is credible and the product mechanism is the bridge. Keep both states concrete enough to verify.

Proposition, demonstration, proof, action

Use for high-intent product pages where the buyer needs to see the capability and trust it before acting.

Category, differentiation, qualification

Use when readers compare alternatives or the product deliberately serves a narrow segment. Name who it is not for when that helps the decision.

Explanation, evidence, implication

Use for technical, regulated, or unfamiliar products where understanding the mechanism matters more than emotional escalation.

Diagnose common failures

Generic proposition

Weak: “A powerful platform for modern teams.”

Repair by adding buyer, task, mechanism, constraint, or observable result from evidence. Do not automatically add a number.

Feature inventory without a decision

Weak: a list of capabilities with no indication of which problem they solve or why they differ.

Repair by grouping capabilities around buyer jobs, workflows, or evaluation criteria. Feature-first language is appropriate when buyers already search for that exact capability.

Benefit language that hides the product

Weak: “Move faster with clarity.”

Repair by naming what the user can do, what the product changes, and the relevant object or workflow.

Unscoped proof

Weak: a customer count, percentage, or testimonial whose population, timeframe, source, or relationship to the claim is unclear.

Repair by adding provenance and scope, narrowing the claim, or removing it until verified.

CTA without commitment clarity

Weak: a label whose destination, cost, data requirement, or next step is surprising.

Repair with the smallest amount of surrounding or button copy that makes the action predictable. Conventional labels may remain when context already does this work.

Objection isolated at the bottom

Weak: critical price, security, compatibility, or cancellation facts appear only in a generic FAQ.

Repair by placing decision-critical information beside the proposition, proof, plan, or action it affects.

Design a useful experiment

Use materially different, defensible variants:

Hypothesis: Buyers hesitate because the mechanism is unclear.
Control: Outcome-led proposition with mechanism below the fold.
Variant: Same outcome with mechanism stated in the hero.
Stable factors: Offer, layout, traffic, proof, CTA destination.
Primary measure: Qualified completion of the target action.
Guardrail: Downstream activation or lead quality.
Decision rule: Defined from available traffic and business cost, not an assumed lift.

Do not test two strategic changes at once when attribution matters. Do not declare a universal winner from one product's result.