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.
3. Select Tier 1, Tier 2, or Tier 3 from the shared quality tiers; higher tiers inherit lower-tier requirements.
4. Classify sources as use, distill, inspiration only, or avoid.
5. Produce the Build-Ready UI Spec.
6. Proceed within the existing task authorization after stating material assumptions; ask only for an actually blocking unresolved choice.
7. Build version 1 using the approved spec.
8. Inspect affected rendered desktop/mobile states; fix observed defects and recheck relevant coverage.
9. Report files changed, commands run, visual QA status, and anything blocked.

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.
• Quality Tier: selected tier, inherited gates, and why the requested commercial outcome maps to it.
• 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.

In original-work mode, extract structural rules and adapt them to the brand/content. In authorized exact-fidelity mode, preserve the requested source details and identify unavailable evidence.

Content Discipline

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

• Choose homepage depth from user tasks, content and page architecture; a detailed single-page site can be correct.
• 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.
• Give each section a clear content role; split or reorganize only when observed crowding or comprehension calls for it.

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

Motion should serve sequence, depth, focus, tactility, narrative, artistic expression or deliberate delight:

• 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.
• Only when Cables Standalone is actually selected, account for its unsandboxed Node integration and external operator code. Use only trusted patches, operators, and npm dependencies; keep client assets separated and export audited web bundles for delivery.

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.

Scope and evidence

Check the applicable gaps in the shared direction/build spec. $route-sellable-web-tier owns requested-tier interpretation; preserve that capability floor without rerunning full release governance for a small edit. Do not add a new spec, media generation or deployment solely because this gate is selected.

Optional specialists

route-sellable-web-tier is optional. Without it, select the requested quality depth using the shared quality-tier reference, preserve project requirements, and avoid imposing enterprise governance on a localized edit.