Premium Website Builder Skill

Build original, production-safe interfaces whose visual quality comes from coherent art direction, not decoration. Preserve working product behavior while improving structure, content, responsive design, and motion.

Load only the references needed

• Read quality-bar.md before creating or judging a visual direction.
• Read motion-and-responsive.md when the work includes animation, responsive layouts, navigation, marquees, or dense mobile interfaces.
• Read production-safety.md before modifying an existing application, live site, authentication flow, checkout, API-backed page, or third-party integration.
• Read framework-guides.md after identifying the project stack.
• Read verification.md before declaring the work complete.

Core rules

1. Inspect before designing. Read the existing source, routes, content, data flow, assets, breakpoints, and screenshots.
2. Treat references as evidence of quality and interaction—not permission to clone protected expression, copy, branding, or assets.
3. Establish a visual thesis in one sentence before implementation.
4. Preserve routes, APIs, authentication, payments, analytics, SEO, localization, and data contracts unless the request explicitly changes them.
5. Use real content and verified brand assets. Never invent product names, logos, prices, statistics, testimonials, integrations, or provider capabilities.
6. Make every section compositionally useful. Avoid repetitive card grids, arbitrary gradients, emoji icons, and decoration without hierarchy.
7. Make motion communicate state, direction, continuity, or system behavior. Do not add animation merely to make the page move.
8. Design mobile behavior deliberately. Desktop compressed into one column is not a mobile design.
9. Verify in a real browser at target breakpoints. Source inspection alone is insufficient.
10. Do not claim completion without evidence.

Workflow

1. Establish scope and safety

• Identify whether the task is greenfield, a redesign, or a bug fix.
• Record files and systems that are in scope.
• Inspect repository status and preserve unrelated user changes.
• For an existing application, map the route-to-template-to-style-to-script chain before editing.
• Separate presentation changes from behavioral changes. Investigate broken behavior before touching it.

2. Audit the current experience

Inspect the page at desktop and mobile widths. Capture:

• page purpose and primary user action;
• content hierarchy and section order;
• typography, spacing, color, borders, surfaces, and imagery;
• repeated layout patterns;
• interaction states and motion;
• responsive failures and overflow;
• inaccurate labels, logo mismatches, placeholders, dead links, or fake data;
• backend/API fields and event handlers that presentation changes must preserve.

Run python3 scripts/audit_frontend.py <project-or-page-directory> for an initial static audit. Treat its output as leads to inspect, not a substitute for browser testing.

3. Analyze references without cloning

For each reference, extract a visual grammar:

• Hierarchy: scale jumps, reading order, density, and focal points.
• Geometry: width system, grid, alignment, radius language, and whitespace rhythm.
• Surface: background depth, borders, textures, shadows, and contrast.
• Type: families, weights, tracking, line length, and label treatment.
• Motion: trigger, duration, easing, direction, and functional meaning.
• Responsive behavior: what collapses, wraps, scrolls, hides, or changes interaction model.

Then create an original composition using the target brand, content, and user flow. Do not reproduce the reference's copy, exact section sequence, proprietary illustration, or distinctive trade dress.

4. Write the visual thesis

State one sentence that constrains the design, for example:

A precise network operations interface with editorial typography, restrained luminous status color, and motion that visualizes traffic flow.

Derive a small token system from that thesis:

• canvas and elevated surfaces;
• primary text, secondary text, and quiet labels;
• one primary accent and at most one supporting accent;
• border strengths;
• spacing scale;
• radius scale;
• type scale;
• motion durations and easing.

Use CSS custom properties, theme tokens, or the framework's existing design-token mechanism. Do not scatter unexplained values.

5. Design the page architecture

Give each section one job and one dominant visual idea. Alternate composition based on content needs rather than arbitrary variety:

• editorial split for positioning or explanation;
• instrument panel for live/system concepts;
• sequence or timeline for process;
• comparison table for exact mappings;
• controlled rail for ecosystems or integrations;
• data visualization for measurable relationships;
• focused CTA for conversion.

Use fewer, stronger sections before adding more. Remove filler sections that do not advance understanding or action.

6. Implement in the native stack

• Reuse the project's components, styles, asset pipeline, router, and conventions.
• Build semantic HTML first; layer styles and motion afterward.
• Keep shared rules shared and page-specific art direction scoped.
• Use existing dependencies when capable. Do not introduce a framework solely for a visual change.
• Componentize repeated structures, but do not force unrelated sections into one generic component.
• Keep data dynamic when the original page is dynamic.

7. Add purposeful motion

Assign every animation an explicit purpose:

• reveal hierarchy;
• indicate connection or status;
• explain flow or sequence;
• preserve continuity in a rail;
• provide interaction feedback.

Prefer transforms and opacity. Provide prefers-reduced-motion behavior. Avoid scroll-jacking, autoplay controls for decorative motion, constant competing loops, and hover-only access to essential content.

8. Engineer mobile separately

At minimum test 360, 390/393, 412, 768, 1024, and the first desktop pixel above the mobile breakpoint.

• Stack navigation rows with explicit flex basis; do not rely on width: 100% inside a shrinking flex item.
• Restore desktop-hidden links when a hamburger menu replaces constrained desktop navigation.
• Keep tap targets at least 42–44px.
• Convert dense tables to scrolling, comparison cards, or prioritized columns.
• Let rails scroll or animate without causing document overflow.
• Recompose hero art rather than merely scaling it down.
• Keep text line lengths and heading wraps intentional.

9. Verify before release

Follow verification.md. At minimum prove:

• the requested page loads;
• real assets load and labels match them;
• all intended interactions work;
• no horizontal overflow exists at target widths;
• no new browser errors occur;
• reduced-motion behavior exists where motion is used;
• neighboring pages using changed shared files remain intact;
• automated tests and format checks pass;
• only scoped files are committed.

Quality gates

Reject the work and iterate when any statement is true:

• The page could belong to any brand after swapping the logo.
• Three or more sections repeat the same card-grid composition without content justification.
• Visual interest depends primarily on gradients, glow, floating circles, or oversized text.
• An icon or logo does not match its visible label.
• Animation has no explainable purpose or competes with another loop.
• Mobile is a squeezed desktop layout.
• Static placeholders replace real application data.
• A redesign changes working behavior without explicit authorization.
• Completion is based on intuition rather than screenshots, computed layout evidence, and tests.

Handoff format

Lead with the result. Report:

• what changed;
• what intentionally did not change;
• affected files or pages;
• browser widths and interactions tested;
• automated checks run;
• deployment or commit reference when applicable;
• any limitation that remains.

Do not say “professional,” “pixel-perfect,” or “fully working” as unsupported adjectives. Show the evidence that earns those descriptions.