git:20260621.2caaecc to git:20260905.f7824ba

---

name: premium-web-build-gate

---

# Premium Web Build Gate

## Overview

Use this skill to prevent generic website output by locking strategy, reference direction, content boundaries, visual system, motion behavior, stack decisions, and QA criteria before implementation. It is a gate: do not start code until the brief below is concrete enough that another design engineer could build from it without guessing.

## Required Order

Follow this sequence for premium web work:

1. Inspect the current project, repo instructions, design docs, route structure, live/local render, assets, and existing copy.

2. Research or re-check current reference sources when the references, tools, product standards, or external sites may have changed.

## Build-Ready UI Spec

Before coding, write a concise spec with these headings:

- `Current System`: framework, entry files, styling system, interaction/motion system, source vs generated assets, junk folders, and planned edit files.

- `Business Truth`: what the organization actually does, stated without invented specifics, fake proof, or copied claims.

- `Page Scope`: what belongs on this page, what belongs on later subpages, and what must be removed to avoid content crowding.

- `Reference Contract`: 3-5 concrete reference behaviors to borrow, 3-5 to avoid, and which references are verified vs user shorthand.

- `Visual Lane`: typography, color/material, layout rhythm, media/art direction, component vocabulary, and density rules.

- `Motion Storyboard`: section-by-section motion beats with purpose, scroll relationship, trigger, duration feel, easing feel, reduced-motion fallback, and performance risk.

- `Implementation Stack`: chosen framework/libraries, why each is needed, and whether it is project-local or global.

- `Acceptance Gates`: desktop/mobile visual checks, interaction checks, accessibility checks, performance risks, and anti-generic checks.

## Reference Rules

Use references as behavior contracts, not vibes:

- Raycast-like means speed, keyboard/product clarity, sharp interaction states, and concrete product proof.

- Linear-like means quiet precision, dense but readable product systems, low-noise hierarchy, and operational specificity.

- Vercel-like means technical credibility, strong infrastructure language, crisp capability segmentation, and clean developer-facing surfaces.

- Squarespace-polished means elegant business flow, strong first viewport, real category clarity, and polished templates without looking generic.

- Viktor Oddy references must be treated as a named designer/source, not vague shorthand. When accessible, verify `viktoroddy.com`, `x.com/viktoroddy`, `motionsites.ai`, `designrocket.io`, and current public articles/videos, then extract concrete traits such as compact studio positioning, AI-site-builder workflows, premium hero/prompt libraries, motion-heavy hero previews, tight CTAs, GIF/video demonstrations, and disciplined type systems. Only use "Viktor-style" shorthand after the actual source has been checked or the user has supplied the traits.

## Content Discipline

Premium pages fail when they become content dumps. Enforce these rules:

- Move detailed services, project examples, process minutiae, and long proof lists to subpages unless the current page specifically needs them.

- Use real copy from the repo/site/docs when available. If copy must be clarified, preserve truth and remove fluff.

- No fake metrics, fake testimonials, fake client names, fake awards, or vague claims like "world-class" unless sourced.

## Visual Rules

Prefer a few decisive moves over many decorative ones:

- Use at most two type families unless a brand system already requires more.

- Keep display type meaningful. Do not use huge words as filler or status noise.

- Avoid repeated card grids, repeated circles, random dots, blobs, generic glowing lines, and decorative effects that do not support the concept.

- Use visual assets, product UI, geometry, video, or spatial scenes when they clarify the business or motion idea.

- Maintain responsive composition: mobile must be intentionally designed, not merely stacked.

- Respect the current brand anchor when the user wants it preserved.

## Motion Rules

- Create fewer, stronger scroll scenes rather than many small ambient animations.

- Each motion beat needs a reason: reveal hierarchy, transform context, guide attention, compare states, or resolve a scene.

- Avoid motion that competes with reading, causes overlap, jitters, drags too long, or looks like a generic template effect.

- Use GSAP/ScrollTrigger/Lenis/Motion/R3F only when they serve the storyboard.

- Always provide `prefers-reduced-motion` behavior and preserve anchor navigation.

- Animate transform, opacity, clip/mask, shader uniforms, or canvas state where possible. Avoid layout-thrashing properties.

## Tool And Skill Trust Gate

Before installing or adopting a new tool/skill:

- Prefer official docs, official skills, reputable maintainers, active repos, clear licenses, and small focused tools.

- Treat community skill lists as lead sources, not install instructions.

- Do not install broad style packs that overlap existing skills unless they add a clear missing gate.

- Install frontend libraries per project, not globally, unless the tool is a CLI or Codex skill.

- Explain why the new dependency or skill materially improves the result.

## Final QA

Before final delivery after implementation:

- Run the site locally when possible.

- Inspect rendered desktop and mobile views when possible.

- Check text overflow, visual overlap, awkward wraps, content density, hover/focus states, reduced motion, console errors, and performance risks.

- Perform an anti-generic pass: remove anything that could belong to any random SaaS/agency template.

- Be honest about anything not tested, especially browser/screenshot QA if tooling or credits blocked it.