/design-critique
Use to give structured feedback on a screen, flow, or mockup — first impression, hierarchy, usability, consistency, accessibility, and what to fix first.
$ npx -y skills add getcrew44/crew44 --skill design-critique --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/design-critique
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use to give structured feedback on a screen, flow, or mockup — first impression, hierarchy, usability, consistency, accessibility, and what to fix first.
SKILL.md
design-critique.SKILL.mdname: design-critique
description: Use to give structured feedback on a screen, flow, or mockup — first impression, hierarchy, usability, consistency, accessibility, and what to fix first.
Design Critique
Give the kind of feedback a designer actually wants: specific, prioritized, and tied to the user's goal — not adjectives.
Frame the critique
Ask, then critique. The same screen gets different feedback at different stages.
- **Stage.** Exploration (push for range), refinement (tighten), or polish (catch what shipped).
- **Context.** Who is it for? What is the user trying to do? What is this screen in service of?
- **Focus.** All of it, or one slice (navigation, the empty state, the hero, the form)?
Pass 1: First impression (two seconds)
- What draws the eye first? Is that what should?
- Is the purpose of the screen clear before you read any copy?
- What's the emotional read — calm, urgent, dense, sparse — and does that match the user's state?
Pass 2: Hierarchy and reading flow
- Does the reading order match what the user is trying to do?
- Are the right elements emphasized? Anything competing with the primary action?
- Is whitespace doing work, or just sitting there?
Pass 3: Usability
- Can the user accomplish the goal without backtracking?
- Are interactive elements obviously interactive? Are read-only elements clearly not?
- Are there unnecessary steps, fields, or confirmations?
Pass 4: Consistency
- Does this match the existing design system, or invent locally? Name the specific deviations.
- Spacing, typography, color tokens — pulled from the system, or magic numbers?
- Do similar elements behave similarly across the screen?
Pass 5: Accessibility floor
- Color contrast: body text ≥ 4.5:1, large text and UI ≥ 3:1.
- Touch targets ≥ 44×44.
- Focus order is logical; focus indicators are visible.
- Form inputs have labels, not just placeholders.
How to deliver feedback
- **Be specific.** "The CTA competes with the navigation" beats "the layout is confusing."
- **Explain the why.** Tie each note to a user need or principle, not just taste.
- **Suggest, don't just diagnose.** A direction is more useful than a problem.
- **Call out what works.** Reinforces the moves to keep.
- **Rank by impact.** Lead with the change that buys the most.
Output
- **Overall impression** — one or two sentences. What works, what's the biggest opportunity.
- **Findings** — grouped by pass (hierarchy, usability, consistency, accessibility). Each finding names the element, the issue, the severity (critical / moderate / minor), and the suggested fix.
- **What works well** — short list. Preserve these.
- **Top three changes** — prioritized. For each: what to change, why, expected effect.
Read more
name: design-critique description: Use to give structured feedback on a screen, flow, or mockup — first impression, hierarchy, usability, consistency, accessibility, and what to fix first.
Design Critique
Give the kind of feedback a designer actually wants: specific, prioritized, and tied to the user's goal — not adjectives.
Frame the critique
Ask, then critique. The same screen gets different feedback at different stages.
- **Stage.** Exploration (push for range), refinement (tighten), or polish (catch what shipped).
- **Context.** Who is it for? What is the user trying to do? What is this screen in service of?
- **Focus.** All of it, or one slice (navigation, the empty state, the hero, the form)?
Pass 1: First impression (two seconds)
- What draws the eye first? Is that what should?
- Is the purpose of the screen clear before you read any copy?
- What's the emotional read — calm, urgent, dense, sparse — and does that match the user's state?
Pass 2: Hierarchy and reading flow
- Does the reading order match what the user is trying to do?
- Are the right elements emphasized? Anything competing with the primary action?
- Is whitespace doing work, or just sitting there?
Pass 3: Usability
- Can the user accomplish the goal without backtracking?
- Are interactive elements obviously interactive? Are read-only elements clearly not?
- Are there unnecessary steps, fields, or confirmations?
Pass 4: Consistency
- Does this match the existing design system, or invent locally? Name the specific deviations.
- Spacing, typography, color tokens — pulled from the system, or magic numbers?
- Do similar elements behave similarly across the screen?
Pass 5: Accessibility floor
- Color contrast: body text ≥ 4.5:1, large text and UI ≥ 3:1.
- Touch targets ≥ 44×44.
- Focus order is logical; focus indicators are visible.
- Form inputs have labels, not just placeholders.
How to deliver feedback
- **Be specific.** "The CTA competes with the navigation" beats "the layout is confusing."
- **Explain the why.** Tie each note to a user need or principle, not just taste.
- **Suggest, don't just diagnose.** A direction is more useful than a problem.
- **Call out what works.** Reinforces the moves to keep.
- **Rank by impact.** Lead with the change that buys the most.
Output
- **Overall impression** — one or two sentences. What works, what's the biggest opportunity.
- **Findings** — grouped by pass (hierarchy, usability, consistency, accessibility). Each finding names the element, the issue, the severity (critical / moderate / minor), and the suggested fix.
- **What works well** — short list. Preserve these.
- **Top three changes** — prioritized. For each: what to change, why, expected effect.
Orchestrate a crew of specialist AI agents in one local-first workspace. Each role on its best model, with memory and skills that compound. Free, MIT.
Repo: getcrew44/crew44
Other skills on crew44.
- /brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Open skill - /executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Open skill - /finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Open skill - /receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Open skill - /requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Open skill - /systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Open skill

