Web Design Guidelines

Use one shared set of guidelines across design, implementation, and review. Follow only the workflow the request needs; do not turn a focused fix into a redesign or a review into an unsolicited implementation.

Choose the Mode

• Design — Establish or change the visual direction. Return a design proposal; do not change code when the user asks only for a concept or plan.
• Apply — Build or modify UI. Use an approved direction or the existing product language. If neither exists, briefly establish a direction before implementation.
• Review — Audit existing UI, code, diffs, or specifications. Return findings without editing files unless fixes are also requested.

Infer the mode from the request rather than asking the user to choose a label. For mixed requests, combine only the needed workflows: design then apply for a new interface, or review then apply for an audit with requested fixes. Ask a focused question only when the scope or permission to change files is genuinely unclear.

Shared Setup

1. Identify the surface, audience, task constraints, and host product conventions. Inspect only the files needed for the task.
2. Check for a project-local design system or style guide before reading the shared references. Look for DESIGN_SYSTEM.md, docs/**/design-system.md, docs/**/style-guide.md, theme files such as theme.ts or theme/index.ts, and files linked from project instructions such as CLAUDE.md or AGENTS.md.
3. Read any applicable local guidance first. Explicit project-local design system decisions take precedence on specifics; shared guidance fills gaps. Preserve established product language unless a redesign is requested, and flag accessibility conflicts rather than silently reproducing them.
4. Load only the references that materially affect this task using the map below. Read framework guidance only for the stack in use.