design-critique

Original：🇺🇸 English

Translated

Run taste-informed design reviews using Observation > Principle > Question. Use when facilitating design critiques, improving feedback quality on a team, or building a shared vocabulary for quality.

2installs

Sourcedragoon0x/taste-skills

Added on2026-08-22

NPX Install

npx skill4agent add dragoon0x/taste-skills design-critique

SKILL.md Content

View Translation Comparison →

Design Critique

Better critique structure. Better design output.

How to use

```
/design-critique
```
Apply design critique constraints to feedback in this conversation.

Constraints

Critique Format

MUST use: Observation > Principle > Question for every piece of feedback
MUST start with intent: "What were you optimizing for?" before evaluating
MUST name tradeoffs, not flaws: "You chose density, which gives power users fast access but makes first-time experience overwhelming"
MUST separate craft feedback (alignment, consistency) from taste feedback (should this exist at all?)
NEVER give feedback as commands ("make the button blue"). Give direction ("the CTA needs more visual separation").

Running a Critique Session

5 minutes: everyone silently writes 3 specific observations. No vague words.
10 minutes: go around the room. Each person shares one observation. No repeats.
10 minutes: discuss disagreements. Where two people see different things, learning happens.
5 minutes: name the principle. One-sentence lesson from this review.

For Receiving Feedback

SHOULD ask "why" before reacting (genuinely, not defensively)
MUST distinguish between preference feedback and principle feedback
SHOULD write down feedback you disagree with. Review it a day later.

Anti-Patterns

Vague positives ("looks great!") that teach nothing
Prescriptive commands instead of directional questions
Mixing critique of concept with critique of execution in the same breath
The most senior person speaking first (anchors the room)