UMKM Landing Page Master Skill
0. Mission
Create a distinctive, trustworthy, mobile-first landing page that helps a real business turn visitors into customers.
This skill coordinates six specialist responsibilities:
- Project orchestration and research — understand the brief, inspect the existing project, extract content and assets, plan the build, and maintain a clear delivery path.
- Conversion strategy — define the audience, offer, objections, message hierarchy, page structure, and primary action.
- Creative direction — develop an original visual concept rooted in the brand, product, audience, and real-world references.
- Frontend implementation — build maintainable, semantic, responsive HTML/CSS/JavaScript with verified assets.
- Design taste and anti-slop review — prevent generic AI visual patterns and make every design decision purposeful.
- Browser QA and deployment readiness — inspect the rendered page, test interactions and responsive states, fix defects, and prepare for Vercel.
Primary output: a working HTML/CSS/JavaScript website ready for Vercel. Preserve an existing framework or project architecture when supplied; do not migrate a working project without a clear reason.
1. Non-negotiable principles
1.1 Facts before decoration
- Treat the user's PRD, business documents, menus, price lists, banners, and approved website content as the source of truth.
- Never invent prices, ingredients, product availability, operating hours, addresses, delivery coverage, certifications, awards, testimonials, ratings, customer counts, or business claims.
- When information is missing, omit it, mark it as NEEDS DATA, or ask one focused question if it materially blocks the build.
- Distinguish verified facts, reasonable design assumptions, and content that needs client confirmation.
1.2 Assets are content
- Inspect supplied banners, photos, logos, PDFs, menus, and brochures before designing.
- Preserve brand logos and product photography accurately. Do not replace a supplied logo with an AI interpretation.
- Build an asset inventory: filename, dimensions, format, subject, likely placement, source, and verification status.
- Prefer original business photography. Use generated or stock imagery only when allowed and clearly distinguish it from real customer/product evidence.
- Do not fabricate testimonials or use illustrative people as if they were real customers.
1.3 One audience, one offer, one primary action
- Define the primary audience and the most important business outcome.
- Select one dominant conversion action, e.g. order via WhatsApp, call, visit store, request quote, book appointment, or purchase.
- Secondary actions must not compete with the primary CTA above the fold.
- Make CTA copy specific to the action and destination, not generic "Learn More".
1.4 Brand-led, not template-led
- Every business needs an intentional visual direction of its own.
- Do not recycle the same hero composition, palette, typography, card layout, icon style, and section order across unrelated brands.
- References are for extracting principles and interaction ideas, not copying another brand's identity.
- Do not use asymmetry, oversized typography, parallax, gradients, glassmorphism, or animation merely to appear creative. Use them only when they fit the brand and improve communication.
1.5 Mobile-first and fast
- Design for narrow screens first, then expand to tablet and desktop.
- Prioritise readable copy, reachable CTA, fast-loading imagery, clear navigation, and low-friction ordering.
- Respect reduced-motion preferences and avoid motion that interferes with reading or purchasing.
2. Supported business contexts
Adapt the structure and visual language to the actual business:
- Food and beverage: kebab, dimsum, bakery, coffee shop, restaurant, catering, snack and beverage brands.
- Retail and fashion: apparel, accessories, cosmetics, gifts, local product brands.
- Services: salon, beauty, repair, education, event service, professional and other local services.
Do not force all business categories into the same page structure. Menu-led businesses need menu discovery and ordering; appointment-led services need trust, service explanation, availability, and booking; fashion may need collections, size information, materials, and purchase flow.
3. Workflow overview
Follow these phases in order. You may combine steps when the project is small, but do not skip source inspection, creative direction, responsive implementation, or QA.
- Project intake and repository reconnaissance.
- Source-of-truth, content, and asset extraction.
- Audience, offer, objections, and conversion strategy.
- Brand-specific vibe discovery and creative direction.
- Information architecture, section plan, and copy.
- HTML/CSS/JavaScript implementation.
- Design-taste and anti-AI-slop review.
- Browser QA, responsive, and interaction testing.
- SEO, accessibility, performance, and Vercel readiness.
- Delivery report with verified status and known limitations.
4. Phase 1 — Project intake and research
4.1 Inspect before changing
- Inspect the repository, existing framework, package files, routes, components, CSS conventions, and deployment configuration.
- Identify whether this is a new build, redesign, or enhancement.
- Preserve working architecture and brand-approved elements unless the user explicitly requests a change.
- Do not overwrite existing work before understanding it.
- Identify available browser, screenshot, image, and deployment tools. Do not claim a tool was used unless it was actually invoked.
4.2 Read all supplied inputs
Inspect relevant files and references, which may include:
- PRD, brief, brand guide, product catalog, menu, price list, promotions, brochures, PDFs, Word files, spreadsheets.
- Banner designs, logos, product photographs, packaging, storefront photos, social media visuals.
- Existing website URLs, social profiles, reference websites, screenshot references.
- User instructions, revision history, approved copy, constraints, and exclusions.
4.3 Create a project fact sheet
Record:
- Business name and category.
- Location and service area, only when supplied or verified.
- Target audience and buying context.
- Products/services and verified prices.
- Unique selling points supported by evidence.
- Ordering, booking, payment, delivery, and contact methods.
- Operating hours, policies, and constraints.
- Primary conversion event.
- Existing brand identity and assets.
- Unknowns and assumptions.
Output: a concise PROJECT-FACTS.md or equivalent working note when the project scope justifies it.
5. Phase 2 — Content and asset extraction
5.1 Text extraction
- Extract factual copy from supplied documents and images.
- Reconcile duplicate or conflicting data using the newest explicitly approved source.
- Keep original product names and spelling unless the user requests editing.
- Preserve prices, variants, sizes, ingredients, dimensions, and terms exactly.
- Flag conflicting facts rather than silently choosing one.
5.2 Image and asset catalog
For every supplied image, record:
- Asset path/name.
- Dimensions and file type.
- Visible subject and content.
- Brand/product relevance.
- Proposed section and crop.
- Whether the asset is original, stock, generated, or unknown.
- Verification status.
5.3 Image usage rules
- Use actual product images for product cards and menu items whenever available.
- Do not replace the real logo with text, an icon, or an invented logo.
- Do not crop out important text, product details, packaging, or brand elements.
- Use
object-fitandobject-positiondeliberately; different source images may need different crops. - Optimise large files into suitable responsive formats when tooling permits.
- Add meaningful alt text; use empty alt text for purely decorative images.
- Verify every final image URL or local path in the browser.
Output: an asset map and a missing-assets list.
6. Phase 3 — Conversion strategy
6.1 Conversion brief
Define:
- Audience: who is most likely to buy or enquire?
- Context: where do visitors come from and what do they already know?
- Offer: what is being sold or requested?
- Value: what tangible benefit does the customer receive?
- Friction: what doubts prevent action?
- Proof: what real evidence can reduce those doubts?
- Action: what exactly should the visitor do next?
6.2 Objection discovery
Consider relevant objections, such as:
- Price and value.
- Product quality and freshness.
- Portion, size, ingredients, or materials.
- Trust, hygiene, reliability, and service quality.
- Location, delivery, and availability.
- Booking, payment, or ordering steps.
- Return, cancellation, or warranty policy.
Only address objections with supported information. Do not invent proof.
6.3 Message hierarchy
- Hero headline: communicate the offer or outcome, not merely the business name.
- Subheadline: clarify what is offered, for whom, and why it matters.
- Primary CTA: specific verb plus clear action.
- Benefits: connect features to customer outcomes.
- Proof: place real supporting evidence near the claims it supports.
- FAQ: resolve remaining purchase friction.
- Final CTA: restate the next step clearly.
6.4 CTA examples
- Food: "Pesan Dimsum via WhatsApp", "Lihat Menu", "Pesan untuk Acara".
- Coffee shop: "Lihat Menu Kopi", "Pesan untuk Pickup", "Lihat Lokasi".
- Fashion: "Belanja Koleksi", "Lihat Panduan Ukuran".
- Services: "Booking Jadwal", "Minta Estimasi Harga", "Konsultasi via WhatsApp".
Verify destination URLs, numbers, message templates, and tracking parameters before delivery.
7. Phase 4 — Vibe discovery and brand-specific creative direction
7.1 Read the brand before selecting a style
Infer from the business:
- Brand personality and positioning.
- Product texture, material, origin, context, or craft.
- Audience expectations and purchase mindset.
- Local/cultural context, only where supported.
- Competitor conventions worth differentiating from.
- The feeling the website should evoke.
- What the website should never be mistaken for.
7.2 Create a unique direction
Write a short visual thesis that specifies:
- Direction name and concept.
- Mood and intended emotional response.
- Typography roles and rationale.
- Color palette with semantic roles.
- Layout/composition approach.
- Image art direction and crop principles.
- Surface, border, and depth treatment.
- Signature design element.
- Motion principles.
- Mobile adaptation.
Do not simply map every project to a preset style. Combine visual influences thoughtfully, but make the combination coherent and appropriate.
7.3 Freshness and anti-convergence check
Before coding, ask:
- Could this layout belong to any unrelated brand?
- Is the hero composition simply the most common AI default?
- Are color and font choices justified by the brand?
- Is there one recognisable visual idea?
- Are the sections arranged for this audience and conversion goal?
- Does the mobile experience have its own composition rather than merely shrinking desktop?
If the concept feels generic, revise the art direction before implementation.
7.4 Design system
Define tokens before component styling:
- Colors: background, surface, text, muted text, border, primary, accent, semantic states.
- Typography: display, heading, body, label, metadata.
- Type scale and line heights.
- Spacing scale.
- Container widths and breakpoints.
- Radius and border rules.
- Elevation/depth.
- Motion duration and easing.
Use a restrained, brand-specific system. Do not ban a font, color, layout, or effect universally; avoid it when it is an unjustified default.
Output: DESIGN.md or an equivalent documented design specification.
8. Phase 5 — Information architecture and section composition
8.1 Choose sections from business needs
Possible sections include:
- Announcement bar.
- Header/navigation.
- Hero.
- Product or service overview.
- Menu/catalog/collection.
- Benefits and differentiators.
- Ingredients/materials/process.
- How to order or book.
- Gallery.
- Testimonials/reviews (real only).
- Location and opening hours (verified only).
- Pricing/packages (verified only).
- FAQ.
- Contact and final CTA.
- Footer.
This is a component library, not a mandatory order. Select, rename, combine, remove, and reorder sections according to the brief and visitor journey.
8.2 Section purpose test
Every section must answer at least one question:
- What does the customer need to understand?
- What decision or objection does it help with?
- What evidence does it provide?
- What action does it make easier?
Remove sections that add no meaningful value.
8.3 Hero requirements
The first screen should make clear:
- What business/product/service this is.
- Who it is for or what it offers.
- Why the visitor should care.
- What the next action is.
Use the best available brand/product asset. Do not force a two-column hero, centered headline, floating dashboard mockup, or decorative gradient.
9. Phase 6 — HTML/CSS/JavaScript implementation
9.1 Stack selection
- If an existing project is provided, preserve its stack unless migration is explicitly requested.
- For a new static landing page, default to semantic HTML5, external CSS, and minimal vanilla JavaScript.
- Use React/Vite/Next.js only when requested or justified by the project.
- Do not add a framework or dependency just to animate a small element.
- Pin or document dependencies; avoid unnecessary scripts and remote libraries.
9.2 Suggested static structure
project/
├── index.html
├── styles.css
├── script.js
├── assets/
│ ├── images/
│ ├── icons/
│ └── fonts/
├── README.md
└── vercel.json # only when needed
9.3 HTML requirements
- Use semantic landmarks:
header,nav,main,section,article,footer. - Maintain a logical heading hierarchy.
- Provide descriptive link text and accessible names for controls.
- Use buttons for actions and links for navigation.
- Include viewport, title, description, canonical URL when known, and Open Graph metadata.
- Do not add fake links such as
href="#"for unfinished actions.
9.4 CSS requirements
- Use project-level design tokens.
- Keep layout responsive with fluid sizing and content-aware breakpoints.
- Avoid fixed heights for content-heavy sections.
- Prevent horizontal overflow.
- Use focus-visible states.
- Respect color contrast.
- Prefer simple, maintainable selectors over brittle overrides.
- Avoid excessive specificity and duplicated rules.
9.5 JavaScript requirements
- Use JavaScript only where interaction needs it.
- Ensure mobile navigation, menus, accordions, forms, galleries, and CTA handlers work.
- Validate inputs and show helpful error/success states.
- Do not fake form submission. Connect to a real endpoint or clearly mark the integration as not configured.
- Avoid console errors and unnecessary event listeners.
- Respect
prefers-reduced-motion.
9.6 Mobile-first requirements
- Verify the layout around 320–375px, 390–430px, tablet, and desktop widths.
- Prioritise a legible first fold and reachable primary CTA.
- Ensure navigation is usable with touch and keyboard.
- Make buttons and interactive targets comfortably tappable.
- Avoid small type, dense multi-column grids, and clipped product images.
- Stack or re-compose content intentionally; do not just compress desktop layouts.
9.7 Interaction and motion
- Use animation to clarify hierarchy, state, or storytelling.
- Keep motion brief and non-blocking.
- Use scroll-triggered animation sparingly.
- Do not animate every section identically.
- Avoid parallax on critical text, menus, or purchase controls.
- Disable or simplify motion when reduced motion is requested.
10. Phase 7 — SEO, local business data, and accessibility
10.1 SEO
- Unique page title and meta description.
- Correct heading hierarchy.
- Descriptive image alt text.
- Open Graph and social preview metadata.
- Descriptive URLs where applicable.
- Internal links and relevant content.
- Sitemap/robots only when appropriate to the deployment.
10.2 LocalBusiness structured data
- Add Schema.org LocalBusiness or a more specific subtype only when the business facts are known.
- Use accurate business name, address, telephone, URL, opening hours, price range, and geographic data only when verified.
- Do not fabricate ratings, reviews, coordinates, or opening hours.
- Validate JSON-LD syntax.
10.3 Accessibility
- Semantic HTML and keyboard navigation.
- Visible focus states.
- Sufficient text contrast.
- Labels for form controls.
- Accessible navigation and disclosure widgets.
- Useful alt text.
- Reduced-motion support.
- Avoid color-only status communication.
11. Phase 8 — Design taste and anti-AI-slop review
11.1 Contextual never-list
Do not use these as automatic defaults:
- Purple/blue gradient hero with glowing orb.
- Generic centered headline + two CTA buttons + floating dashboard mockup.
- Three identical feature cards repeated across sections.
- Repeated rounded containers with identical shadows.
- Inter/Roboto or another default font without brand rationale.
- Emoji as interface icons.
- Random blobs, sparkles, decorative circles, or floating badges.
- Generic stock imagery unrelated to the actual product.
- Fake testimonials, fake ratings, fabricated statistics, or invented trust logos.
- Generic CTA labels that do not describe the action.
- Excessive glassmorphism, gradients, shadows, parallax, or motion.
- Section order copied unchanged from a generic template.
These patterns are not universally forbidden; they require a clear reason grounded in the brand and context.
11.2 Typography
- Choose typefaces for brand character, readability, language support, and licensing.
- Establish display, heading, body, and metadata roles.
- Ensure Indonesian diacritics and punctuation render correctly.
- Avoid using many font families or weights without reason.
- Check line breaks and heading wraps on mobile.
11.3 Color
- Derive colors from the brand, product, packaging, environment, or approved identity.
- Define semantic roles and accessible text contrast.
- Avoid adding accent colors without a purpose.
- Do not assume dark backgrounds or gradients automatically look premium.
11.4 Layout and composition
- Use a deliberate visual hierarchy.
- Introduce asymmetry, overlap, editorial grids, or varied section compositions only when appropriate.
- Avoid repeating identical card grids.
- Preserve comfortable reading width and consistent alignment.
- Ensure visual variety does not damage usability.
11.5 Depth and surface
- Create hierarchy through spacing, contrast, borders, image composition, and restrained elevation.
- Use shadows only when they clarify surface relationships.
- Avoid stacking blur, glow, transparency, and shadow effects without a clear purpose.
11.6 Motion
- Choose one coherent motion language.
- Prioritise purposeful transitions and feedback.
- Avoid constant motion that competes with the product or CTA.
- Verify performance and reduced-motion behaviour.
11.7 Pre-flight design review
Before declaring the page visually complete, check:
- Does the page look specific to this brand?
- Does the hero communicate the offer quickly?
- Is the main CTA visually clear and functional?
- Are typography and color deliberate?
- Are section layouts varied for a reason?
- Are actual product/business assets used correctly?
- Is the mobile composition designed rather than merely shrunk?
- Is anything present only because AI commonly generates it?
Fix issues rather than merely listing them.
12. Phase 9 — Browser QA and testing
12.1 Required browser checks
When browser tooling is available:
- Load the page at mobile and desktop viewports.
- Inspect the first fold and every major section.
- Check image loading, crop, aspect ratio, and broken URLs.
- Test navigation and all CTA destinations.
- Test menus, accordions, forms, sliders, and other interactions.
- Check layout overflow, clipping, overlapping, and sticky behaviour.
- Check console errors and failed network requests when tooling exposes them.
- Test keyboard navigation and focus visibility.
- Verify reduced-motion behaviour.
12.2 Functional test matrix
At minimum test:
- Primary CTA.
- Secondary links.
- WhatsApp message URL or phone link, if used.
- Menu/navigation.
- Forms and validation, if present.
- FAQ accordions, if present.
- Mobile navigation.
- External links and target behaviour.
12.3 QA status vocabulary
Use only:
- PASS — tested and working.
- FAIL — tested and broken; must be fixed or explicitly reported.
- NEEDS DATA — requires information or credentials not supplied.
- NOT TESTED — no actual test was performed.
Never report a test as PASS just because the code appears correct.
13. Phase 10 — Performance and Vercel readiness
13.1 Performance
- Compress and resize images.
- Prefer modern image formats when supported.
- Lazy-load below-the-fold images.
- Do not lazy-load the primary hero image when it harms LCP.
- Reserve image dimensions to reduce layout shift.
- Minimise external dependencies and blocking scripts.
- Avoid autoplay video unless it is essential and optimised.
- Use font loading strategies that limit layout shift.
13.2 Vercel readiness
- Confirm the project root and build settings.
- For static HTML, ensure
index.htmlis in the deployment root. - For framework projects, preserve the correct build command and output directory.
- Add
vercel.jsononly when routing/headers/rewrites require it. - Ensure no secret API keys or private credentials are committed.
- Check relative asset paths and case sensitivity.
- Verify the deployed URL after deployment when access is available.
13.3 Deployment honesty
- Do not claim deployment succeeded unless deployment actually ran and returned success.
- Do not claim a live URL was tested unless it was opened and checked.
- If deployment is not possible, provide exact deployment instructions and state what remains.
14. Delivery requirements
Deliver:
- Working project files.
- A concise summary of the implemented brand direction.
- Sections included and the conversion path.
- Source files and assets added/modified.
- QA checklist with PASS / FAIL / NEEDS DATA / NOT TESTED.
- SEO/accessibility/performance notes.
- Deployment status and URL only when verified.
- Remaining content/data that needs client confirmation.
Do not hide known limitations. Do not describe unfinished work as complete.
15. Quick-start checklist
- Inspect repository and existing project architecture.
- Read PRD, menu, banners, business documents, and references.
- Extract factual business information and list unknowns.
- Catalogue and verify all supplied assets.
- Define one audience, one offer, and one primary conversion action.
- Discover and document a unique brand-specific creative direction.
- Define design tokens and section plan.
- Write factual conversion-focused copy.
- Build semantic HTML/CSS/JavaScript.
- Implement mobile-first layouts and interactions.
- Review against anti-AI-slop and design-taste rules.
- Test browser rendering, links, forms, images, and responsive states.
- Check SEO, structured data, accessibility, and performance.
- Verify Vercel configuration and deployment readiness.
- Deliver the files and an honest QA report.
16. Source provenance and adaptation
This master skill is a synthesis and adaptation, not a verbatim copy or a claim that the source repositories were installed as runtime dependencies. The following source files were fetched from their GitHub default branches and inspected when preparing version 1.0.1. Blob SHAs identify the exact file contents observed at that time.
| Source | File | Git blob SHA | Main contribution |
|---|---|---|---|
| Aston1690/claude-skill-landing-page | SKILL.md | 3e7f558b76e71196444d68f47fd5c66d18077669 | Research, brand/content extraction, asset verification, build workflow, browser QA, Vercel deployment |
| elayadesign/ai-design-skills | skills/landing-page-design/SKILL.md | 519a6f2cd6c942c2fb36a906b8ef7d11f78ba6d1 | Intake, audience/objections, page structure, conversion copy, SEO/AEO, visual system |
| 2389-research/landing-page-design | skills/SKILL.md | 7b20a36dfe5d6e17c16f218dafb76fe0a70eba5d | Mandatory vibe discovery, original aesthetic direction, anti-convergence, animation vocabulary |
| jezweb/claude-skills | plugins/frontend/skills/landing-page/SKILL.md | 644d94583e2bf32e8673255d633f349da9033bd3 | Deployable HTML structure, section patterns, mobile-first requirements, semantic HTML, SEO, accessibility |
| madebymustafa/design-taste | skills/design-taste/SKILL.md | d6bac0ab1e3df4466153a5ba64ce1001a804910b | Contextual anti-slop rules, typography, color, composition, depth, motion, pre-flight checklist |
Adaptation policy
- Concepts and workflow practices were adapted to the UMKM/local-business context; source files were not concatenated or represented as verbatim copies.
- Conflicting requirements were reconciled in favour of factual content, brand fit, maintainability, accessibility, and conversion clarity.
- Framework-specific examples were generalised. Preserve the user's existing stack; static HTML/CSS/JS is the default only when no existing project is supplied.
- QA and deployment are mandatory workflow responsibilities, but status must be reported honestly. Never claim tests or deployment that did not occur.
- Review original repository licences before redistributing adapted material or creating derivative works.