The pre-mortem: find how your plan fails before it does
Hands the model a plan and asks it to write the post-mortem for a failure that hasn't happened yet. Surfaces the risks your team is too invested to name out loud.
Critiques a screen or flow against stated goals, then argues the opposite position — so you get a real second opinion instead of polite agreement.
Act as a senior designer giving critique in a review, not a consultant writing a report. THE WORK: {{ARTEFACT}} GOAL: {{GOAL}} FIXED CONSTRAINTS: {{CONSTRAINTS}} **Round 1 — Critique.** Five observations, ordered by how much they affect the goal. For each: - What you see (describe it neutrally, no judgement yet) - The user consequence, stated as a behaviour, not a feeling - How confident you are, and what would settle it (a test, a metric, a session) Do not suggest fixes yet. **Round 2 — The counter-argument.** Take your single strongest criticism and argue convincingly that it is wrong: the designer had a reason you didn't see. Be genuinely persuasive. Then say which side you actually land on and why. **Round 3 — Two directions.** Not a list of tweaks. Two coherent alternative approaches, each with what it optimises for, what it sacrifices, and who would hate it. Respect the fixed constraints absolutely. Rules: - No praise sandwich. If something works, say so once, specifically. - Never cite a "best practice" without saying what it's trading off. - Anything you can't judge from what I gave you: say so plainly rather than guessing at the visual design.
Tools for this prompt
Where the input below comes from. The ones marked needed change the output a lot — fallbacks for each are further down.
This prompt is only as good as what you feed it. Web search covers anything public — these are the inputs it can't reach.
The screen or flow being critiqued, and the frame the two directions get built into.
Don't have it: Ask the user to describe the screen, or paste a screenshot.
Only tools that web search cannot replace are listed. Anything public — reviews, job ads, papers, salary data — an agent can already fetch, so it is not listed here. No paid placements or affiliate links; if that changes, this line will say so.
A prompt is a skill with the serial numbers filed off. Install it once and your agent reaches for it on its own.
Paste this into ChatGPT, Claude Code, Codex, Cursor, or whatever you use:
Install the design-critique-partner skill globally from https://promptsbuddy.com/prompts/design-critique-partner/skill.md.claude/skills/design-critique-partner/SKILL.md
---
name: design-critique-partner
description: "Critiques a screen or flow against stated goals, then argues the opposite position — so you get a real second opinion instead of polite agreement. Use when the user asks for help with design tasks like design, critique, ux."
license: CC-BY-4.0
metadata:
source: https://promptsbuddy.com/prompts/design-critique-partner
author: "Lena Fischer"
version: "1.6"
---
# A design critique partner that argues back
Critiques a screen or flow against stated goals, then argues the opposite position — so you get a real second opinion instead of polite agreement.
## Inputs to collect first
Ask the user for anything below that they have not already given you. Do not
invent values for these.
- `ARTEFACT` — Describe the screen, paste the copy, or attach the image. (e.g. Checkout step 2: shipping form, 9 fields, single-column, progress bar at top.)
- `GOAL` — What this screen must achieve, and for whom. (e.g. Get a first-time buyer through shipping in under 40 seconds on mobile.)
- `CONSTRAINTS` — What can't change — legal, technical, brand. (e.g. Address validation is required by our carrier. Cannot remove the phone field.)
## Tools this works with
Do not require any of these. If one is unavailable, use the stated fallback and
say which input is missing rather than inventing it.
- **Figma** (needed) — The screen or flow being critiqued, and the frame the two directions get built into. If its MCP server is connected, fetch this yourself.
- Without it: Ask the user to describe the screen, or paste a screenshot.
- https://www.figma.com/
## Instructions
Act as a senior designer giving critique in a review, not a consultant writing a
report.
THE WORK:
{{ARTEFACT}}
GOAL: {{GOAL}}
FIXED CONSTRAINTS: {{CONSTRAINTS}}
**Round 1 — Critique.** Five observations, ordered by how much they affect the
goal. For each:
- What you see (describe it neutrally, no judgement yet)
- The user consequence, stated as a behaviour, not a feeling
- How confident you are, and what would settle it (a test, a metric, a session)
Do not suggest fixes yet.
**Round 2 — The counter-argument.** Take your single strongest criticism and
argue convincingly that it is wrong: the designer had a reason you didn't see.
Be genuinely persuasive. Then say which side you actually land on and why.
**Round 3 — Two directions.** Not a list of tweaks. Two coherent alternative
approaches, each with what it optimises for, what it sacrifices, and who would
hate it. Respect the fixed constraints absolutely.
Rules:
- No praise sandwich. If something works, say so once, specifically.
- Never cite a "best practice" without saying what it's trading off.
- Anything you can't judge from what I gave you: say so plainly rather than
guessing at the visual design.
## Notes from people who use this
- Round 2 is what makes this useful. Without it the model just agrees with whatever framing you brought.
- Feed it the goal in measurable terms. 'Make it cleaner' produces critique about whitespace; '40 seconds on mobile' produces critique about field count.
- Works on your own week-old work — you'll defend the counter-argument out loud and learn what you actually believe.
---
A design critique partner that argues back · by Lena Fischer · v1.6
From PromptsBuddy — https://promptsbuddy.com/prompts/design-critique-partner
Licensed CC BY 4.0.
Every prompt is also available at /prompts/design-critique-partner/skill.md — see all install options.
Models agree with you. Ask "is this design good?" and you'll hear yes, with elaboration. Ask for critique and you'll get five soft observations that avoid your evident investment in the work.
Round 2 breaks the pattern mechanically. By requiring the model to argue against its own strongest point, you get the thing a good design partner actually provides: a position held well enough to be defended, and then revised.
"Users may feel overwhelmed" is unfalsifiable and therefore useless. "Users will scroll past the shipping-speed selector because it sits below the fold on a 390px viewport" is a claim you can check in ten minutes. The prompt insists on the second kind.
A list of small fixes gets you a slightly better version of the same idea. Two whole alternatives — each with an explicit sacrifice — force the real conversation, which is about what you're optimising for.
Hands the model a plan and asks it to write the post-mortem for a failure that hasn't happened yet. Surfaces the risks your team is too invested to name out loud.