Vibe Landing

Vibe Landing

Create a bespoke, production-ready public marketing site with the smallest useful subset of Vibe. Vibe is a basket of fruit: select only the components and architectural choices the brief needs; never treat the whole repository as a required stack.

When to apply

Apply to a new landing page, service website, company website, small corporate site, promotional site, marketing site, local-business website, or single-product website.

Do not select this skill automatically for admin dashboards, desktop apps, mobile apps, backend-only work, complex SaaS/web applications, or work in an existing project. In an existing project, use it only when the user explicitly asks to apply Vibe.

Default approach

• Treat Vibe as the default architectural reference. For a typical marketing site, prefer its website portion.
• Do not automatically add Vibe's backend, database, Prisma, authentication, webapp, mobile app, Terraform, Docker, background jobs, or other infrastructure. These are allowed only when the brief genuinely requires them.
• Keep the stack and dependency graph minimal. Before adding a package or writing a replacement, look for a suitable current Vibe solution and reuse or adapt it when it fits.
• Do not make sites visually uniform. Vibe standardizes architecture and quality; design direction, layout, typography, imagery, and interaction must be tailored to the brief.

Required workflow

Before implementation:

1. Read the user's brief and identify the site type and the required functionality.

2. Study the current Vibe repository structure and the relevant existing implementation before relying on memory. Use the official repository as the source of truth.

3. Choose the minimum sufficient Vibe subset, prioritizing website for ordinary marketing work.

4. State a short PROJECT SCOPE in this format:

   Uses from Vibe:
   Not using:
   Adds:
   Why:
   

5. Immediately begin implementation after the scope, unless a critical ambiguity cannot be resolved safely.

During implementation:

• Start static/HTML-first. Add JavaScript only for a concrete need; use React only for interactions that require it. SEO-critical content must be present in rendered HTML.
• Build responsive, mobile-first layouts; validate useful breakpoints instead of merely shrinking desktop UI.
• Use semantic HTML, logical heading order, keyboard access, visible focus, sufficient contrast, descriptive labels, and appropriate alternative text.
• Implement page-level SEO: accurate title and meta description, canonical and social metadata where applicable, crawlable internal links, and structured data only when it truthfully describes the page.
• Protect Core Web Vitals: minimize blocking resources and client-side JavaScript; reserve media space; avoid layout shifts; defer nonessential work.
• Optimize images: use appropriate dimensions, modern formats and responsive variants where supported, meaningful alt text, and lazy-load only below-the-fold images.
• Do not add animation libraries, Three.js, video effects, or other heavy client functionality by default. Use them only when the requested design or brief materially needs them.

Before handoff:

• Recheck that no unnecessary dependency, subsystem, or infrastructure was introduced.
• Run the production build and fix failures.
• Perform browser QA of the implemented site at mobile and desktop sizes, including navigation, forms or interactions, overflow, visual regressions, keyboard flow, and essential SEO-visible content.