betterclever/clever-web-design

Clever Web Design

Preserve the user's product, framework, content, brand, and functional requirements. The approved visual is the quality bar; implementation convenience is not a reason to weaken it.

Establish the visual

1. Resolve only the constraints that materially affect the design: purpose, audience, content, brand, art direction, target viewports, any chosen framework, and the functional contract of non-trivial integrations.
2. Locate and inspect any visual the user refers to. If no approved reference is supplied, use ImageGen to create a plausible full-page website concept rather than a mood board. Iterate until the user approves it.
3. Do not begin full implementation before approval unless the user explicitly asks to skip the gate. Obtain an approved visual or explicit responsive composition for every important viewport.

Approval covers visual direction, not hallucinated text, data, claims, or brand marks. Establish exact copy and data as code-owned content. Use supplied or authoritative brand assets rather than image-generated approximations; clearly label invented demo content.

Decompose before building

Show a concise implementation map before generating assets:

• Code: text, navigation, controls, data, state, responsive structure, and accessible semantics.
• CSS/SVG: simple geometry, icons, gradients, borders, shadows, masks, and repeatable effects.
• Generated assets: characters, sculptures, organic shapes, material-rich objects, complex scenery, textures, and distinctive illustrations.
• Hybrid: generated artwork positioned, masked, lit, or animated with code.

If procedural recreation would visibly weaken distinctive artwork, generate an asset. Do not rebuild concept art as crude CSS or SVG merely because it is possible. Do not flatten meaningful interface content into an image.

For each generated asset, identify its role, layer, crop, transparency, resolution, and responsive behavior. Generate important artwork separately at sufficient resolution, using the approved concept as a visual reference so identity, pose, material, lighting, and perspective remain coherent. Prefer transparent backgrounds and cut out or clean edges when necessary. Do not use the concept screenshot itself as the production page except for an intentionally non-interactive background.

Implement

Use the user's chosen stack; otherwise choose the simplest stack compatible with the project. Build semantic, accessible, responsive interface code and compose the generated assets to reproduce the approved concept's hierarchy, typography, palette, materials, depth, scale, cropping, and spacing. Size and encode assets for their rendered use; avoid making decorative artwork the page's performance bottleneck.

Render the real page at the same viewport as the approved concept. Also inspect important responsive states. Judge actual screenshots and running behavior, never a builder-written summary.

Run the blind visual gauntlet

Use subagents when available. The builder must never grade its own work.

1. Choose the concrete bar: the approved concept at matching viewport sizes, plus explicit user requirements. For complex pages, split the design into the smallest important regions or assets that can be improved and judged independently.
2. After each build wave, render fresh screenshots. For each critic, independently randomize the approved concept and implementation as neutral A/B candidates. Normalize viewport, dimensions, crop, and file type; remove provenance-revealing labels and metadata; keep the mapping outside the critic's context.
3. Fan out at least two independent critics, normally three when capacity permits. Spawn every critic fresh with no forked conversation history and do not reuse it in another round. Give it only a provenance-neutral textual brief, the requirements, and exact paths to its neutral A/B images; do not separately identify or supply the approved concept. Permit it to open only those images and forbid all other workspace, code, browser, terminal, message, prior-output, or agent inspection.
4. Require each critic to cite visible evidence and return A, B, or materially indistinguishable, plus the largest gap and highest-leverage correction. Generic uncertainty or abstention is a loss. Numeric scores cannot replace the verdict.
5. Reveal the mapping only to the lead agent. The implementation has not won if any critic prefers the reference. Consolidate findings in a material-gap ledger, fix the largest gaps, recheck resolved gaps for regressions, render again, and use a new blind jury. Important separable pieces may run through their own builder-critic loops in parallel when edits will not conflict.
6. Regional verdicts are provisional. Before any final pass, run a fresh blind jury on the complete page at every required viewport after regional work is integrated.
7. After the blind-stage win, run two fresh labelled checks with no prior verdicts. A fidelity auditor returns explicit PASS only when no material mismatch with the approved concept remains. A functional tester returns explicit PASS only when every requirements-derived interaction, responsive, and accessibility checklist item passes on the running page. Each returns FAIL with evidence otherwise. A prettier but materially different page does not pass. The builder may fix findings but may not clear either gate.
8. After major parallel work, use a fresh holistic pass to smooth inconsistencies across the complete page.

Do not stop after an arbitrary number of rounds. Pass only when every fresh blind critic prefers the implementation or finds it materially indistinguishable, both labelled gates clear, and the responsive result preserves the approved hierarchy. A defect is material when it violates an explicit requirement or visibly changes content, hierarchy, legibility, interaction, fidelity, or responsive behavior.

Record the evaluated build revision and screenshot hashes. Any mutation after evaluation invalidates every earlier verdict. After a fix from any gate, rerun the complete-page blind jury and both labelled gates with fresh agents against the same final build at every required viewport.

The user may stop the loop or set a resource limit. If fixes oscillate, no materially different correction remains, capacity prevents at least two independent critics, or a resource limit is reached, stop without claiming a pass and report the gap ledger and limiting constraint.

Deliver

Present the working website, generated assets, and a brief account of any intentional differences from the approved concept. Do not burden the user with internal agent transcripts.