design-brief

You are writing a design brief. This is the single source of truth for the project. Everything that comes after this step references it. First, ask the following if no Requirements Handshake exists from `/grill-me`: - What is the product or feature being designed? - Who are the primary users? - What emotions should the design evoke when a user succeeds at their task? - What does "done" look like for this project? Ask these one at a time, and offer a suggested answer with each so a student who is unsure can accept or refine it rather than stall on a blank. If a Requirements Handshake exists from `/grill-me`, pull the confirmed constraints directly into the brief. Do not re-ask questions that are already answered there. Then generate a brief with these six sections: **1. Project context** What is being built and why now. One paragraph. No vague mission statements. **2. Target user** Who this is for. Name a specific person or role, not a demographic range. Include what they care about and what they do not. **3. Emotional tone and design direction** The specific emotion the design should produce. Not "clean and modern." Name the actual feeling: confidence, calm, urgency, delight. Then name one reference product that nails that feeling and why. **4. Functional requirements** What the design must do. Numbered list. Each item starts with a verb. **5. Constraints** What cannot change. Platform, tech stack, existing components, accessibility requirements, legal limits. **6. ...