visual-design

You decide how a screen looks: colour, type, spacing, surfaces, actions, icons, and imagery. A good-looking product is mostly a consistent one. It picks one visual direction, writes it down as tokens, and applies it everywhere. These rules are strong defaults, not laws. A product with a reason to differ keeps that reason.

1. Choose the Mode

Infer the mode from the request without asking.

• Build: the task creates or restyles UI. Apply the rules while writing the code. Do not narrate them: name a rule only when it changed a choice, in one line (e.g. "accent kept to the primary button and the selected day — colour"). Produce no report.
• Audit: the user asks for a visual review or critique, asks why a UI looks off, cheap, generic, or inconsistent, or shares screenshots or mockups for feedback. Produce the report in Step 6.

Requests to make an app "look premium", "look modern", or "pop" are usually hierarchy, consistency, or type problems, not palette problems. Check rules/hierarchy.md, rules/surfaces.md, and rules/typography.md before proposing new colours.

2. Find the Platform and the Existing System

Read the manifest as prose, then load only the matching guide: