/ios-design-brief — Visual Design System

Establish the project's visual identity and write it to docs/DESIGN-SYSTEM.md as a concrete, implementable spec. Draft-first and sighted: look at the actual app and the brief, propose a direction in chat, refine with the user, then write the doc. No code changes here — that's /ios-design-elevate.

Next step: /ios-design-elevate applies this system to the Views, verifying each screen visually.

Principles

• Look before you decide. If the app builds, screenshot it and judge the real rendered screens — never design from imagination. (Visual Loop below.)
• Draft-first, in chat. Propose a concrete direction; the user reacts. Never write questionnaires into the document.
• Fit this app. Derive the direction from the brief's personality/audience and what's on screen. Do not reach for a house aesthetic — there is no default theme. A fitness app, a finance app, and a journaling app should look nothing alike.
• Concrete, not vague. Every choice is specified at the SwiftUI level — actual weights, sizes, design: variants, tracking, hex values with role assignments, gradient stops, indicator shapes, animation curves/durations. "Bold typography" is not a spec; .system(size: 34, weight: .black, design: .rounded) is.
• Distinctive over safe. Aim for a look recognizable from a single screenshot. Avoid startup-blue, generic cards, platform-default-everything — but let the distinctiveness come from the app's domain, not a template.
• Color scheme is foundational. Decide dark / light / adaptive first — every color, material, and contrast choice depends on it.

Visual Loop (how to "look")