mcpbeat Sign in

Facilitating Design Critique Agent Skill

Run or participate in a Bitwarden design critique session — the weekly team critique and one-off product design reviews — grounded in the team's published etiquette guide and the Product Design Review Guidelines.

2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
129
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/bitwarden/ai-plugins --skill facilitating-design-critique

The instruction itself

9 sections, as written by the author

Facilitating Design Critique

This skill grounds the _facilitation_ of design critique in two Bitwarden sources of truth:

the Weekly Design Critique & Etiquette Quick Guide

and the Product Design Review Guidelines.

Read the Confluence pages directly when prepping a real session — the get_confluence_page MCP

tool fetches them. This skill is the practitioner's quick reference, not a replacement for

those pages.

> Cross-plugin dependency. When the design under discussion lives in a Figma file, this

> skill composes using-figma from the bitwarden-design-tools plugin — install it

> alongside bitwarden-designer for the full composition to work.

Pick the right mode

Bitwarden runs two distinct kinds of critique. Treat them differently.

  • Weekly Design Critique. Recurring team session. Presenter sets context for a piece of

work-in-progress; the room asks clarifying questions, then gives feedback. Lightweight

cadence, peer-to-peer, the presenter decides what to apply.

  • Product Design Review. Stakeholder review for a specific design proposal. Invites

product, engineering, research as relevant. Heavier facilitation: scope, criteria, briefing,

walkthrough, structured feedback collection.

Ask which mode the user means before suggesting a structure. The roles, prep, and time

investment differ.

Roles in the room

  • Presenter. Sets context: the goal of the design, the constraints, the open questions,

and what kind of feedback they want. The presenter owns what they apply.

  • Facilitator. Shepherds the session: redirects when discussion drifts, holds a "parking

lot" for side issues that aren't central to the scope, and protects the presenter's stated

feedback ask. In weekly critique this is usually a rotating role; in product design reviews

it's an explicit appointment.

  • Participants. Ask before judging. Share observations, concerns, and ideas. Tied to user

and product goals, not personal preference. Don't dominate.

The Weekly Design Critique Quick Guide reduces this to: **critique the work, support the

person, improve the product.**

Session shape

Both modes share the same arc; the depth differs.

  • Presenter sets context. Goal, constraints, open questions, the kind of feedback wanted.

In product design reviews, this also covers background and the "why" — relevant

documentation, early iterations, user research findings, business goals, end-user goals.

  • Clarifying questions. Ask before judging or suggesting. The room doesn't critique

what it doesn't yet understand.

  • Walkthrough and feedback. Presenter walks the design. Participants share feedback tied

to user impact, product goals, standards, or technical constraints.

  • Wrap-up. Key takeaways and next steps. In product design reviews, document feedback for

future reference in a preferred format and prioritize issues.

Feedback etiquette — do and don't

Do

  • Be specific and constructive.
  • Explain _why_ something works or doesn't.
  • Ask questions to understand intent.
  • Call out what's working, not just issues.
  • Respect time and stay on topic.

Don't

  • Make it personal.
  • Give vague opinions like "I don't like it."
  • Dominate the conversation.
  • Jump to solutions without context.
  • Design on the spot — describe the gap, let the designer solve.

A useful set of opening phrases when the room stalls:

  • "What problem is this solving for the user?"
  • "I'm unclear about [blank] — could you explain?"
  • "Have we considered [blank] as an alternative?"
  • "This part feels strong because [blank]."

Common participation traps

  • "I don't like it." Not feedback. Tie the observation to a user need, business need,

standard, convention, or technical constraint — or skip it.

  • "You are not the user." Personal bias presented as universal experience. Surface it as

bias, not as a finding.

  • Asking _why_ badly. "Why did you do that?" puts the designer on the defensive. "What

are you trying to achieve by doing X?" gets at the same thing without the edge.

  • Solutioning during the review. A well-meaning suggestion can cascade through a design.

Describe the gap. Let the designer weigh the fix offline.

  • Negative-only feedback. Designers move in the direction of what's working as much as

away from what isn't. Lead with strengths, then issues.

  • The unconsidered consequence. "Could we just…" requests often spiral. When a suggestion

feels simple, name the cascading effects you can see and let the designer decide.

Facilitator playbook for product design reviews

When facilitating (not just participating):

  • Before the review. Pick a method to collect feedback. Identify and invite the right

stakeholders. Confirm the presenter has the briefing material ready (goals, background,

early iterations, user research, business and end-user goals).

  • During the review. Define scope. Set feedback expectations. Surface the "why." Run the

walkthrough. Open the floor with the scope and criteria already named. Document feedback in

the agreed format. Hold the parking lot for off-scope discussion.

  • After the review. Prioritize the issues raised. Confirm next steps with the presenter.

Composing with other skills

  • design-review. During the session, the _substance_ of feedback runs through

design-review — the 30/60/90 framework, the Code of Conduct, and (at 60%/90%) the

content-style-guide. This skill shapes the room; design-review shapes what's said.

  • using-figma. When the presentation is from a Figma file, use using-figma to bring

the design context into the discussion (screenshot, metadata, variables) without

context-bombing the room.

Output format

When asked to help prep or run a critique:

  • Mode — Weekly Critique or Product Design Review.
  • Roles — who's facilitating, who's presenting, who's participating.
  • Presenter's setup — goal, constraints, open questions, the feedback ask.
  • Agenda / arc — context → clarifying questions → walkthrough → feedback → wrap-up.
  • Watch-outs for the room — the specific etiquette traps likely to come up given the

work being presented.

Always end with the wrap-up question explicit: _what is the presenter going to do next?_

Other skills for the same job

different authors, same section of the catalogue
Skill Creator
by anthropics
vendor ×10

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

56k tokens scripts
Skill Creator
by vercel-labs
vendor ×10

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.

12k tokens scripts
Skill Creator
by JayZeeDesign
×9

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.

10k tokens scripts
Template Skill
by JayZeeDesign
×7

Replace with description of the skill and when Claude should use it.

35 tokens
Dispatching Parallel Agents
by ZhanlinCui
×5

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

2k tokens
Skill Development
by anthropics
vendor ×4

This skill should be used when the user wants to "create a skill", "add a skill to plugin", "write a new skill", "improve skill description", "organize skill content", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.

9k tokens
Find Skills
by sanity-io
vendor ×4

Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.

1k tokens
Writing Skills
by ZhanlinCui
×4

Use when creating new skills, editing existing skills, or verifying skills work before deployment

26k tokens scripts

How to use it

Copy the folder

Take bitwarden/facilitating-design-critique from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.