Web Design Picker

Web design picker

Build a complete website-concept review package rather than isolated mockups. The default deliverable is three materially different, responsive website directions; a review shell that switches among them without losing the presentation context; a full-screen presentation mode; a searchable asset catalog with per-format, per-family, and download-all controls; two primary release archives; and supporting review, source, and full-handoff archives.

When invoked for an actual website project, perform the work. Do not stop at a strategy document unless the user asks only for strategy.

Default output contract

Create:

1. Three standalone direction source pages in src/concepts/, built into dist/concepts/.
2. One generated review picker at dist/index.html.
3. One generated asset catalog at dist/design-assets.html.
4. Direction-specific logos, favicons, palettes, design tokens, and supporting graphic elements.
5. Optimized client media when source video or animation is supplied.
6. Desktop and mobile preview images when browser automation is available.
7. A lean static deployment ZIP with index.html at its root.
8. A separate complete design-assets handoff ZIP.
9. A machine-readable and human-readable QA report.

Use scripts/web_design_picker.py as the unified command-line entry point for scaffolding, building, validating, browser-testing, and packaging. Read the workflow reference before beginning a full project.

Non-negotiable rules

• Build three distinct design theses, not one template with three palettes.
• Each direction must differ in information architecture, typography, spacing, geometry, media treatment, interaction, and emotional register.
• Keep each concept independently usable as a static page with its own title, viewport metadata, favicon, accessible navigation, and responsive layout.
• Use real supplied content and media as evidence. Do not invent capabilities, clients, metrics, certifications, software compatibility, or testimonials.
• Treat trademarks and product names accurately. Never imply an affiliation that does not exist.
• Do not use stock imagery merely to fill a composition. Prefer client assets, purposeful diagrams, custom vector elements, crops of real work, or restrained typography.
• Avoid generic AI-site styling. Apply the anti-slop guardrails and run scripts/slop_lint.py before packaging.
• Do not make a fake contact flow. A prototype form may download a structured brief or clearly state that submission is not connected. Production submission requires a real endpoint.
• Do not bundle font files for handoff unless the user owns redistribution rights. Prefer system fonts, licensed web delivery, or outlined logo artwork.
• Every direction and the review shell must include a favicon set.
• Preserve reduced-motion preferences and keyboard operation.
• Do not place a wrapper folder inside the Cloudflare Drop ZIP. The first archive entry must be index.html.
• Keep the deployment ZIP lean. Do not place the complete handoff ZIP inside it. The asset page should assemble ZIP downloads client-side from individual static files.

Workflow

1. Ingest and establish truth

Inspect the current site, supplied files, brand material, screenshots, source copy, and media. Extract:

• audiences and jobs-to-be-done;
• actual services or products;
• strongest proof and differentiators;
• current conversion path;
• factual constraints and unknowns;
• required legal, trademark, privacy, accessibility, or geographic language;
• reusable and missing assets.

Create a concise source-of-truth brief. Mark every assumption that needs confirmation, but continue with a defensible prototype when the answer is not necessary to build it.

2. Define three orthogonal directions

For each direction, write a short thesis containing:

• the perception it should create;
• the primary audience or buying concern it prioritizes;
• its information architecture;
• its typographic and spatial system;
• its media strategy;
• its interaction idea;
• the deliberate tradeoff it makes.

Use the direction strategy rubric. Reject a set when two directions could be made equivalent by changing only colors, fonts, or border radius.

3. Design content before decoration

Write a shared factual content model, then decide how each direction edits, sequences, and frames it. A design direction may emphasize different content, but factual claims must stay consistent.

Prefer concrete language: inputs, outputs, process, deliverables, evidence, constraints, next action. Remove boilerplate such as “bringing visions to life,” “innovative solutions,” or “trusted partner” unless the organization has specific evidence supporting it.

4. Build the standalone concepts

Create complete responsive HTML pages. Inline CSS and lightweight JavaScript are acceptable; local assets should use relative paths. Each page must:

• have a recognizable opening composition rather than a generic hero-card stack;
• include real sections with meaningful transitions and hierarchy;
• make the differentiator prominent rather than burying it in a service grid;
• use interaction sparingly and purposefully;
• include labeled form controls when a form is shown;
• provide an honest prototype behavior;
• work at approximately 390 px, 768 px, 1280 px, and 1440 px widths;
• include a direction-specific favicon.

Do at least three passes: content accuracy, visual distinctiveness, and responsive/alignment polish. Then run the anti-slop review.

5. Build the asset system

For every direction, export the useful design ingredients, not just screenshots:

• primary mark and monochrome mark;
• horizontal lockup when applicable;
• editable SVG and transparent PNG versions;
• favicon SVG, ICO, 32 px, 180 px, 192 px, and 512 px exports;
• palette sheet plus CSS and JSON tokens;
• reusable diagrams, patterns, frames, rules, arrows, icons, or interface graphics;
• poster images and web media derivatives;
• notes identifying concept-only marks, licensing limits, or trademark constraints.

Record assets in config/assets.json. Follow the asset catalog and handoff specification.