Design Critique

Protocol

Step 1 — Inspect and ground

• Inspect the supplied screenshot(s). If none is available, ask the user to attach one; v1 does not capture screens.
• Name the screen's job. State the surface, primary user, and task in one line. If the thread and screenshot do not support them, ask up to two short questions rather than guessing.
• Read meta/DESIGN.md when it exists and governs the screen. An established product convention is not a finding. Without a governing design source, apply universal principles and mark system consistency unverified.
• Bound the evidence. A screenshot supports visible layout, hierarchy, typography, content, and displayed states. It does not prove keyboard behavior, focus order, semantics, responsive behavior, motion, or undisplayed states.

Step 2 — Recommend and confirm directions

• Honor directions the user already named; recommend additions or removals with reasons, but never replace them silently.
• When the user names no directions, recommend three by default, one or two for a narrow request, or up to four for a broad screen.
• Show the remaining directions as lower-value options.