design-critiquer
Use this skill when reviewing, evaluating, or giving structured feedback on UI designs, wireframes, mockups, or design systems. Trigger phrases: 'critique this design', 'give feedback on my UI', 'review this wireframe', 'what's wrong with this design'. Do NOT use for writing code, implementing designs, or marketing material critique.
What this skill does
# Design Critiquer
## Overview
This skill provides structured, actionable design critiques grounded in UX principles, visual design fundamentals, and usability heuristics. A good design critique is not a list of personal preferences—it connects observations to user impact and business outcomes. This skill helps you evaluate designs across key dimensions: usability, hierarchy, accessibility, consistency, and clarity. Whether you are reviewing a lo-fi wireframe or a polished high-fidelity mockup, the output is prioritized, constructive feedback that the designer can act on immediately.
## When to Use
- Reviewing wireframes, mockups, or prototypes before development
- Running a design critique session or design review meeting
- Evaluating a redesign against the existing product for regression
- Auditing a live UI for usability and accessibility improvements
- Peer-reviewing a teammate's design work
- Self-critiquing your own design before presenting it
## When NOT to Use
- Writing or implementing code (use `frontend-design` skill instead)
- Creating marketing materials or campaign assets — different discipline
- Evaluating brand identity at a strategic level (brand strategy is a separate domain)
- Legal or compliance review of design assets
- Performance profiling or technical evaluation of a front-end implementation
## Quick Reference
| Task | Approach |
|------|----------|
| First pass | Evaluate from the user's perspective before looking at individual elements |
| Hierarchy | Check: can you read the page in 5 seconds and know what to do? |
| Accessibility | Contrast ratios (4.5:1 text, 3:1 UI), touch targets (44×44px min), focus order |
| Consistency | Same element, same style everywhere — spot deviations from the design system |
| Usability heuristics | Apply Nielsen's 10: visibility, feedback, control, standards, error prevention, etc. |
| Prioritization | Sev 1 (blocks users) → Sev 2 (frustrates users) → Sev 3 (polish/preference) |
| Tone | Critique the design, not the designer; lead with impact, not judgment |
| Positive feedback | Name what works and why — it's as actionable as what doesn't |
## Instructions
1. **Understand the context before critiquing.** Identify: What is this screen trying to accomplish? Who is the user? What stage of the design is this (wireframe vs. polished mockup)? Calibrate the depth of your critique to the fidelity—pixel-perfect feedback on a wireframe wastes everyone's time.
2. **Do a five-second first impression.** Look at the design for five seconds, then look away and answer: What is this page for? What is the primary action? What did my eye go to first? If these are unclear, the hierarchy needs work—this is your most important finding.
3. **Evaluate visual hierarchy and layout.** Check whether size, color, weight, and whitespace guide the eye through the intended reading order. The primary action should be visually dominant. Group related elements. Ensure spacing is consistent and intentional, not random.
4. **Apply Nielsen's usability heuristics.** Systematically check the top relevant heuristics: (1) Visibility of system status, (2) Match between system and real world, (3) User control and freedom, (4) Consistency and standards, (5) Error prevention, (6) Recognition over recall, (7) Flexibility and efficiency, (8) Aesthetic and minimalist design, (9) Error recovery, (10) Help and documentation.
5. **Check accessibility fundamentals.** Verify text contrast meets WCAG AA (4.5:1 for normal text, 3:1 for large text). Confirm interactive elements are at least 44×44px for touch. Check that the design communicates information through more than color alone. Identify any content that depends on hover states with no keyboard equivalent.
6. **Assess consistency with the design system.** Identify any components, spacing, typography, or color values that deviate from established patterns. Inconsistencies erode trust and make the product feel unpolished—even when users can't articulate why.
7. **Prioritize feedback by severity.** Classify every finding: Severity 1 = blocks task completion or causes errors, Severity 2 = creates confusion or frustration, Severity 3 = polish and preference. Lead with Sev 1 findings. Clearly separate preference from principle.
8. **Frame feedback constructively.** Use the format: **Observation → Impact → Suggestion.** "The primary button and secondary button have the same visual weight [observation], which makes it unclear which action to take [impact]. Consider making the primary action visually dominant with a filled style and reserving the outline style for secondary actions [suggestion]."
## Examples
### Example 1: E-Commerce Checkout Screen Critique
**Input:** "Critique this checkout screen. It has: a large product image on the left, a form on the right with fields for name/email/address/card number, a 'Place order' button at the bottom, and a small security badge in the footer. Users are abandoning at this step."
**Output:**
#### Five-Second Test Result
The layout is clear — it reads as a checkout form. However, the primary action ("Place order") is buried at the bottom, requiring a scroll most mobile users won't complete.
#### Severity 1 — Blocks Completion
**Button placement and visibility**
The "Place order" CTA is below the fold on mobile. Users who don't scroll never see it. Move the button directly below the last form field, or add a sticky CTA at the bottom of the viewport on mobile.
**Form field order**
Asking for card details before confirming the order summary creates anxiety. Show an order summary (items, total, shipping cost) before payment fields. Users need to confirm what they're paying before they trust you with payment details.
#### Severity 2 — Frustrates Users
**Security badge placement**
The security badge is in the footer, after the payment form — where users least expect it. Place trust signals (SSL lock icon, accepted card logos, "Secure checkout" language) directly adjacent to the card number field, where purchase anxiety peaks.
**No inline validation**
Card number and email errors appear only after submit. Add real-time validation (confirm email format, format card numbers with spaces as users type). Errors at submit feel punishing; errors in the moment feel helpful.
**Field labels vs. placeholders**
If labels disappear when typing begins (placeholder-only pattern), users lose context mid-form. Use persistent floating labels or label-above-field patterns.
#### Severity 3 — Polish
**Product image size**
The large product image on the left takes significant real estate. At checkout, the user has already decided to buy — a smaller image or order summary card serves them better. Consider converting this space to a concise order summary instead.
#### What Works Well
- Single-column form on the right provides a clear linear path
- "Place order" button label is specific and clear — better than "Submit" or "Continue"
---
### Example 2: Dashboard Wireframe Critique
**Input:** "Review this dashboard wireframe for a SaaS analytics tool. It shows: a left sidebar with 12 nav items, a top bar with username and settings icon, a main area with 8 metric cards in a 4x2 grid, and a large line chart below. Users say it feels overwhelming."
**Output:**
#### First Impression
The layout signals "analytics tool" immediately, which is good. But 12 sidebar items and 8 metric cards compete equally for attention — there is no clear starting point. Users feeling overwhelmed is a direct symptom of missing hierarchy.
#### Severity 1 — Blocks Effective Use
**Navigation overload**
12 top-level nav items exceeds the cognitive limit for scannable menus (~7 items). Group related items under collapsible sections or move secondary items into a settings area. Consider which 5–7 items represent 80% of user journeys and elevate those.
**No primary metric**
All 8 metric cards are the same size and weight. Users don't know which number matters most. Identify the 1–2 KPIsRelated in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.