# Design Critique

> Run a design critique with a clear presenter contract, feedback rules that attack the work not the person, and captured decisions. Use when a designer brings work in progress to a group for structured feedback rather than approval.

- **Type:** Skill
- **Install:** `agentstack add skill-amey-thakur-ai-skills-design-critique`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [Amey-Thakur](https://agentstack.voostack.com/s/amey-thakur)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [Amey-Thakur](https://github.com/Amey-Thakur)
- **Source:** https://github.com/Amey-Thakur/AI-SKILLS/tree/main/skills/big-tech-processes/design-critique
- **Website:** https://amey-thakur.github.io/AI-SKILLS/

## Install

```sh
agentstack add skill-amey-thakur-ai-skills-design-critique
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Design critique

A critique is a working session where a designer shows unfinished work and a
group helps make it better. It is not a status update and not a sign-off gate.
Left unstructured, it collapses into taste debates about color while the actual
problem goes unexamined, and the designer leaves with fifty opinions and no
decision. A method keeps the room aimed at the goal and turns feedback into
changes someone owns.

## Method

1. **Open with the presenter contract.** Before showing a single screen, the
   designer states the problem being solved, the constraints, the fidelity stage,
   and the two or three decisions they actually want feedback on. Without that
   frame, the room defaults to bikeshedding whatever is easiest to have an
   opinion about.
2. **Frame the user and the metric, not the feature.** Present the
   job-to-be-done, who has it, and what success looks like. Reviewers cannot
   judge a checkout flow without knowing whether the goal is fewer steps or fewer
   errors, and those pull in opposite directions.
3. **Enforce the feedback rules out loud.** Critique the design against the
   stated goal, not personal preference; ask "what problem does this solve"
   before proposing an alternative; and separate observation from prescription. A
   facilitator names it when someone jumps to a fix: "that is a solution, what is
   the problem you saw".
4. **Match critique altitude to fidelity.** Wireframes get flow and hierarchy
   feedback, not typography notes. Debating font pairing on a gray-box layout
   burns the session on decisions that were never on the table.
5. **Sort feedback by weight as it lands.** Tag each point blocking, consider, or
   nit. Blocking means the goal is not met, consider is the designer's call, and
   a nit never justifies a redesign. Untagged feedback all sounds equally urgent.
6. **Capture decisions, open questions, and owners in a running doc.** Write
   "Decided: single-step guest checkout. Open: forced login for returning users,
   owner Priya, due Friday." A critique held only in memory is one the group
   re-argues next week.
7. **Close with the designer synthesizing.** The presenter restates what will
   change, what they are deferring, and what they are rejecting and why. Critique
   advises; the designer decides. If the room votes, it was never a critique.

## Signals

- Did the presenter get feedback on the decisions they asked about, or on
  whatever caught the loudest reviewer's eye?
- Can you read the doc afterward and list every change and its owner?
- Did anyone confuse "I would do it differently" with "this fails the goal"?

## Boundaries

Critique gathers input; it does not grant approval, and it is not design by
committee. Route the ship-or-hold decision to your design review or launch
process, and defer usability questions to testing with real users, since a room
of colleagues is not your audience. Follow the studio's own critique cadence
where one exists.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Amey-Thakur](https://github.com/Amey-Thakur)
- **Source:** [Amey-Thakur/AI-SKILLS](https://github.com/Amey-Thakur/AI-SKILLS)
- **License:** MIT
- **Homepage:** https://amey-thakur.github.io/AI-SKILLS/

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-amey-thakur-ai-skills-design-critique
- Seller: https://agentstack.voostack.com/s/amey-thakur
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.