Name the route and the state you want reviewed
Meg needs to know which page or screen matters and what state the reader should be looking at before she can judge the design clearly.
→
Good shape: page, intended state, and why that state matters. Avoid asking for a generic vibe check on an undefined surface.
State the visual question, not only the implementation status
A strong request names the design uncertainty: hierarchy, density, component precedent, readability, or whether the route still matches the project language.
→
“What should change?” is weaker than “Is the scan-first hierarchy still clear after this new control rail?”
Bring the relevant design rule or proof pointer
The handoff is stronger when Meg can compare the route against the intended language instead of inferring the design rules from the output alone.
→
That may be a PDLP pointer, an existing route precedent, or a clear reference to the part of Atlas grammar the builder meant to reuse.
Ask for the next move, not just an opinion
The most useful result is a revised-or-approved next step the builder can act on immediately.
→
A good Meg review changes the route: tighten spacing, simplify hierarchy, reuse a proven pattern, or proceed as-is.