Prompts / critique
Design critique for the stage the work is in Free
A structured critique of a design, framed by its stage (concept to shipped), ending in observations, impacts and a short list of changes. Refuses feedback that belongs to a later stage.
Run it
- Claude Code:
/mcp__designers__critique - Claude Desktop and claude.ai: plus menu, Add from Designers, Design critique for the stage the work is in
- Any app: Use the critique prompt from the Designers server on figma link, screenshot, or a description of the design.
Arguments
| Name | Meaning |
|---|---|
design * | Figma link, screenshot, or a description of the design |
stage * | concept, wireframe, visual, prototype, build or shipped |
goal | What the design has to achieve and for whom |
focus | What you want feedback on, and what you do not |
* required
What your assistant is told to do
The full instructions, so you can see exactly what you are asking for:
Run a design critique as a senior design lead would: specific, kind to the maker, hard on the work, and aware of the stage.
Design: <design>
Stage: <stage>
Goal and audience: <goal>
Feedback wanted: <focus>
Method:
1. Read the stage rubric: resource designers://reference/critique-rubric. Note what feedback to refuse at this stage and say so once, briefly, if you park any.
2. Look at the design. If the input is a Figma link: parse it (figma.com/design/:fileKey/..., node-id=1-2 means nodeId "1:2"), call get_metadata to see the frames, get_screenshot for each frame you will judge, and get_design_context for layout, text and tokens. Read the picture before the code. If the Figma tools are not connected, say so and ask for screenshots or exported frames instead; do not guess at what is in the file.
3. Call plan_critique with the description and stage if the person wants a session plan for a team; otherwise skip it.
4. State what is working first, with reasons, so it survives the redesign. Name two or three specific strengths, not "nice layout".
5. Write findings as observation, impact, optional direction. Each names the part of the design (frame and element), says what you see, says what it does for the person using it or for the goal, and offers a direction to try, not an instruction. Where a check is objective, run the tool and cite it: check_contrast for colour pairs, review_ui_copy for strings, detect_design_slop for a live page.
6. Run lint_design_feedback on your own findings and rewrite any it flags as vague, opinion or solution-without-problem.
7. Finish with: the three changes most likely to improve the work, ordered; two questions the designer should answer before the next stage; what you could not judge from what you were given (states not shown, real content, devices).
Never say "make it pop", "clean" or "modern". Do not give taste as fact. Keep it under 700 words unless asked for more.