About landing-page-craft
A skill for planning and implementing landing pages around a clear audience decision and supported evidence. It guides teams from conversion brief and page structure through responsive implementation and verification.
Key features
- 01Define audience, offer, and action
- 02Map claims to available evidence
- 03Plan sections around user decisions
- 04Write concrete copy and CTAs
- 05Implement responsive, semantic UI
- 06Verify forms, links, and keyboard paths
Use cases
- 01Structuring a page for a specific offer
- 02Placing proof near key decisions
- 03Planning CTA destinations and outcomes
- 04Checking mobile, form, and keyboard behavior
Install
Copy the command and run it in a terminal.
$
npx skills add https:/ / github.com/ divyanshu-iitian/ agent-website-design-skills --skill landing-page-craftAfter installing, type/landing-page-craftin Claude Code to confirm it loaded.
Bundled filesagents/openai.yamlreferences/conversion-flow.md
Details
From the project READMELanding Page Craft
Build a page around a real decision, not a stack of fashionable sections. Make the offer understandable, believable, and actionable before adding polish.
Workflow
- Inspect existing brand, product, audience, traffic source, content, analytics requirements, and technical constraints.
- Write a one-line conversion brief:
- audience;
- situation or intent;
- offer and concrete outcome;
- primary action;
- biggest objection.
- Inventory available proof: product UI, examples, customer evidence, metrics, founder expertise, policies, integrations, security, or process. Never fabricate proof.
- Choose a page argument. Sequence only the sections needed to move the audience from recognition to confidence to action.
- Design the first viewport to answer:
- What is this?
- Is it for me?
- What changes if it works?
- What should I do next?
- Write concrete copy before tuning layout. Make headings informative, CTAs destination-aware, and claims proportional to evidence.
- Select a visual direction that belongs to the offer. Use product UI, real work, relevant imagery, data, or interaction as proof - not generic atmosphere.
- Implement semantic, responsive, performant UI in the project's existing stack. Include important loading, error, form, and success states.
- Place proof and risk-reversal near the decisions they support. Do not dump every trust signal into one logo wall.
- Verify the complete action path on mobile and desktop, including keyboard use, form validation, destinations, and tracking hooks when present.
Page Rules
- The H1 should communicate the offer or outcome; it does not have to repeat the brand name.
- Keep one primary action per decision point. Secondary actions should reduce uncertainty.
- Use real content and realistic lengths early enough to expose layout problems.
- Avoid section-count theater, repeated feature-card grids, fake testimonials, fake scarcity, and unsupported superlatives.
- Do not hide material price, renewal, privacy, eligibility, or cancellation information.
- Keep important content available without requiring decorative animation.
- Treat performance, accessibility, and responsive behavior as conversion features.
Delivery Contract
Provide or implement:
- Conversion brief - audience, offer, action, objection.
- Page argument - ordered sections and the question each answers.
- Evidence map - claim -> nearby proof.
- CTA map - label -> destination -> success behavior.
- Implemented page - when code changes are requested.
- Verification - mobile/desktop screenshots or inspection, keyboard path, form states, and link checks.
Reference
Read references/conversion-flow.md when choosing page structure, proof placement, CTA language, and risk-reversal.
Comments
Markdown supported