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.

Requirements

Use Python 3.10 or newer. Build, validation, and packaging use the standard library. Scaffolding and favicon exports require Pillow and resvg-cli. Screenshots require Playwright and Chromium. Video exports require ffmpeg. Generated sites are framework-free static files.

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.