SkillVaultskills Browse all 500 skills

Frontend · Version 3.0.0 · Reviewed 2026-08-02

Website Builder

Improve landing page architecture and Responsive UI implementation with evidence, explicit trade-offs, and a verification plan.

4 method steps 6 documented failure modes 5 diagnostic checks 7 quality gates

Turns a product brief into a polished, responsive, accessible, SEO-ready website with a coherent design system and deployable implementation.

₹199 one-time

Get this skill archive

What this skill helps you do

  • Landing page architecture
  • Responsive UI implementation
  • Accessibility and performance validation

How Website Builder works

You provide

The product brief, audience, brand assets, content, and conversion goal

It inspects

Information architecture and design tokens tied to measurable acceptance criteria

It decides

Responsive components, metadata, forms, analytics, and deployment-ready code

You verify

Keyboard, reflow, contrast, Core Web Vitals, links, and production preview checks

What it checks first

Website Builder turns a product brief into a polished, responsive, accessible, SEO-ready website with a coherent design system and deployable implementation. Use it when the work involves Landing page architecture, Responsive UI implementation, Accessibility and performance validation.

  1. A single primary conversion path that remains obvious at mobile, tablet, and desktop widths instead of competing calls to action.
  2. A content hierarchy derived from user questions and proof needs, not from a generic sequence of hero, features, and testimonials.
  3. Reusable type, spacing, color, radius, elevation, and motion tokens before section-level styling begins.
  4. Real asset dimensions and copy lengths in the first implementation pass, because placeholders hide overflow, crop, and density failures.
  5. Performance measured at the deployed origin with production fonts, images, scripts, analytics, and cache headers enabled.

Failure modes it recognizes

  • A desktop-first layout that looks polished at 1440px but overflows or collapses at 320px because components use fixed widths and unbreakable text.
  • A visually impressive hero with no credible proof or next action, producing attention without conversion.
  • Cumulative layout shift from unbounded images, late font swaps, or client-only content that changes dimensions after hydration.
  • Decorative animation that ignores reduced-motion preferences or keeps the main thread busy during interaction.
  • A contact or checkout form that appears successful before the server accepts the submission, losing leads without visible errors.
  • Metadata, canonical URLs, structured data, sitemap entries, and social previews diverging from the actual routed page.

Answers it will reject

  • Copying a fashionable template before defining the audience and conversion goal; visual polish cannot repair the wrong information hierarchy.
  • Using arbitrary pixel values in every section instead of a small token system, which makes responsive correction inconsistent and expensive.
  • Hiding overflow to make a screenshot pass, which clips real content and keyboard focus rather than fixing layout constraints.
  • Claiming a perfect Lighthouse score from localhost while shipping unoptimized production assets and third-party scripts.

Decision rules it applies

  • If a section does not answer a user question, provide proof, or advance the primary action, remove or combine it.
  • Prefer CSS layout and responsive primitives over JavaScript viewport branching unless behavior, not presentation, must change.
  • Use semantic native elements first; add ARIA only when native semantics cannot represent the interaction.
  • Treat accessibility, SEO, analytics, error states, and deployment as acceptance criteria, not post-launch polish.

Evidence it asks for

  • Chrome DevTools device emulation plus real 320px, 768px, and 1440px viewport screenshots to catch reflow and content-density defects.
  • Lighthouse or PageSpeed Insights against the deployed URL for LCP, CLS, INP, render blocking, and asset opportunities.
  • Automated axe-core scanning followed by keyboard-only navigation and visible-focus review for critical flows.
  • Search Console URL inspection, structured-data validation, and social-card preview tools for indexability and sharing metadata.

The method inside

  1. Establish the current state and the constraint that actually limits landing page architecture.
  2. Separate the requested solution from the underlying problem in Responsive UI implementation, and name the assumptions carrying the most risk.
  3. Compare only viable options for accessibility and performance validation against weighted constraints, cost of reversal, and operational ownership.
  4. Commit to a sequenced recommendation with success criteria, guardrails, and the observation that would reverse it.

Deliverables

  • Landing page architecture assessment
  • Responsive UI implementation decision and action plan
  • Accessibility and performance validation verification checklist

Evidence requirements

  • Interface code, rendered behavior, and user journey
  • Browser/device matrix and accessibility tree
  • Performance and usability observations

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

Build a premium website for a developer tool. I have rough copy and a logo, but no information architecture or visual system.

Expected output

Start by turning the rough copy into one conversion path: problem, proof, workflow, pricing, and final CTA. Define reusable type, spacing, color, and component tokens before building sections, then validate mobile reflow, keyboard access, metadata, Core Web Vitals, forms, analytics, and the production deployment...

Boundaries and compatibility

Ideal for

  • Landing page architecture: produce a decision or artifact grounded in supplied evidence.
  • Responsive UI implementation: produce a decision or artifact grounded in supplied evidence.
  • Accessibility and performance validation: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Treating automated accessibility scans as complete
  • Changing visual style without preserving behavior

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.