50+ Claude Code Skills for Designers and Product Managers

Sorted Pixels，From the desk of Tommaso Nervegna, an ongoing exploration of design, technology, and human creativity.关注

There are now thousands of “AI tools for designers” articles. Almost none of them give you something you can install in ninety seconds and use on a real project this afternoon.

This one does.

Below are 50 hand-picked Claude Code skills drawn from five excellent open-source collections. Every one is real, MIT-licensed, and installable today. I’ve grouped them by the moment in your workflow where you’d actually reach for them — not by repo, because nobody works that way.

Three things to know before you start:

  1. Skills load automatically. Once installed, you don’t summon them by name. You just describe the problem in plain English and Claude picks the right skill. The names below are for you to know what’s in your toolkit.
  2. Commands are different. Commands (prefixed with /) are workflows you trigger explicitly. They chain multiple skills together.
  3. Most of these work outside Claude Code too. The SKILL.md format is portable. Cursor, Codex CLI, Gemini CLI, even Cowork — same skills, different runners.

Let’s go.

A. The five collections you’re installing from

Bookmark these. Everything below comes from one of them.

1. Designer Skills — by MC Dean 63 skills, 27 commands, 8 plugins covering research → systems → UI → delivery. Install: claude install github:Owl-Listener/designer-skills

2. Inclusive Design Skills— by MC Dean 40 skills, 18 commands, 6 plugins. Accessibility as a design discipline, not a code review. Install: claude install github:Owl-Listener/inclusive-design-skills

3. AI Design Skills — by MC Dean 42 skills, 18 commands, 6 plugins for designing agentic products. Install: claude plugin marketplace add Owl-Listener/ai-design-skills

4. Layers — by Jamie Mill 9 skills across the 7 layers of product design. Stop staying at the surface. Install: npx skills add jamiemill/layers-skills

5. PM Skills Marketplace — by Paweł Huryn 65 skills, 36 commands, 8 plugins covering discovery → strategy → launch → growth. Install: claude plugin marketplace add phuryn/pm-skills

B. Discovery & research — before you draw anything

1. /layers-orient (Layers) A diagnostic that audits your project across all seven design layers and tells you which one is actually the bottleneck. Use this when you don’t know where to start. It will almost always tell you you’ve been working at the wrong layer. → Why use it: Stops you from polishing screens when the conceptual model isn’t decided.

2. /layers-user-needs (Layers) Elicit and prioritize user needs as job stories. Outputs opportunities ready to flow into product strategy. → Why use it: Forces specificity. “Users want a dashboard” becomes “When [situation], I want to [motivation], so I can [outcome].”

3. /layers-observed-behaviour (Layers) Plan and synthesize user research at the observed-behaviour layer — produces job stories with confidence ratings. → Why use it: The confidence rating is the killer feature. It separates what you actually saw from what you assumed.

4. user-persona (Designer Skills → design-research) Create refined user personas from research data — demographics, goals, frustrations, behavioral patterns. Not the slide-deck cardboard cutout kind. → Why use it: Persona work that draws on the same frameworks an experienced researcher would, not vibes.

5. journey-map (Designer Skills → design-research) End-to-end user journey map with stages, touchpoints, emotions, pain points, and opportunity areas. → Why use it: The opportunity-area output is what most journey maps skip. That’s where the next sprint’s work lives.

6. empathy-map (Designer Skills → design-research) The classic 4-quadrant Says/Thinks/Does/Feels synthesis. → Why use it: Useful when interview data is messy and you need to compress it before strategy work.

7. inclusive-personas (Inclusive Design Skills) Personas with disability woven in as a natural dimension — not a separate “accessibility persona” on a slide nobody looks at. Specific assistive technology, environments, scenarios. → Why use it: The single highest-leverage move for shifting accessibility left in your process.

8. /discover (PM Skills → pm-product-discovery) A full discovery cycle: ideation → assumption mapping → prioritization → experiment design. Chains four skills together. → Why use it: This is Teresa Torres’ continuous discovery loop, executable in one command.

9. opportunity-solution-tree (PM Skills → pm-product-discovery) Build an Opportunity Solution Tree (Teresa Torres) — outcome → opportunities → solutions → experiments. → Why use it: The most rigorous structure I know for showing how a feature ladders up to an outcome. Pair it with #2.

10. identify-assumptions-existing (PM Skills → pm-product-discovery) Identify risky assumptions across Value, Usability, Viability, and Feasibility. → Why use it: Marty Cagan’s four risks, encoded. Catches the assumption that’s about to sink your roadmap.

C. Strategy & framing — making the decisions designers normally skip

11. /layers-product-strategy (Layers) Connects user opportunities to business outcomes and solution bets. Outputs a strategy tree with prioritized experiments. → Why use it: The bridge between research output and execution input. Without this layer the rest is theatre.

12. /layers-conceptual-model (Layers) Define the product’s objects, relationships, states, and vocabulary independently of any interface. Jamie calls this “the most load-bearing layer.” He’s right. → Why use it: If you’ve ever had a team disagree about what the design “is” while looking at the same screen, this is the fix.

13. /layers-domain (Layers) Map domain concepts, terminology conflicts, and bounded contexts. Produces a noun harvest for the conceptual model. → Why use it: When PM, design, and engineering are using the same word for different things — and the meetings keep going sideways.

14. /strategy (PM Skills → pm-product-strategy) Creates a complete 9-section Product Strategy Canvas — vision through defensibility. → Why use it: For when “what’s our strategy here?” needs to be a document, not a vibe.

15. value-proposition (PM Skills → pm-product-strategy) 6-part JTBD value proposition: Who, Why, What before, How, What after, Alternatives. → Why use it: The “What before / What after” framing is where most value props break. This catches that.

16. swot-analysis + pestle-analysis + porters-five-forces (PM Skills → pm-product-strategy) Three classic business strategy frameworks, now agentic. Run them together with /market-scan for a full macro environment analysis. → Why use it: When you need to walk into a leadership conversation prepared. Especially if you’re a designer trying to get a seat at that table.

17. /ux-strategy:frame-problem (Designer Skills → ux-strategy) Takes an ambiguous challenge and structures it into a clear problem statement. → Why use it: “We need to redesign onboarding” is not a problem. This makes it one.

18. /ux-strategy:benchmark (Designer Skills → ux-strategy) Run a competitive benchmarking analysis with structured output. → Why use it: Saves you the three days of Mobbin you don’t have.

19. north-star-metric (PM Skills → pm-marketing-growth) Define your North Star Metric and supporting input metrics. Classifies your business as the right “game” (attention, transaction, productivity). → Why use it: Metric work where designers usually get overruled. Walk in with this and you won’t.

D. The design system layer — where most teams hemorrhage hours

20. /design-systems:tokenize (Designer Skills → design-systems) Extract and organize design tokens from an existing system or codebase. → Why use it: If you’ve ever inherited a design system with hex codes scattered everywhere, this is the cleanup.

21. /design-systems:audit-system (Designer Skills → design-systems) Audit a design system for consistency, accessibility, and coverage. → Why use it: Run this before any system migration or version bump. The output is the meeting agenda.

22. /design-systems:create-component (Designer Skills → design-systems) Scaffold a full component specification — props, variants, states, accessibility, edge cases. → Why use it: The spec is what engineers will actually build from. This makes it complete on the first pass.

23. /ui-design:color-palette (Designer Skills → ui-design) Generate a full color system with primary, secondary, neutral, and semantic colors — all passing WCAG AA. → Why use it: Color systems that pass contrast checks on the first try. Rare.

24. /ui-design:type-system (Designer Skills → ui-design) Create a complete typography system — scale, hierarchy, line heights, responsive behavior. → Why use it: Type systems usually get reverse-engineered after-the-fact. This builds it correctly upfront.

25. /ui-design:responsive-audit (Designer Skills → ui-design) Audit a design for responsive behavior across breakpoints. → Why use it: Catches the desktop-first thinking before it ships.

E. Interaction, state, and the unhappy paths

26. /layers-interaction-flow (Layers) Map interaction structure and flow. Outputs breadboard notation with edge cases, failure paths, and open decisions. → Why use it: “Breadboarding” is from Basecamp’s Shape Up methodology — it forces structural decisions before visual ones. This skill encodes that.

27. /interaction-design:map-states (Designer Skills → interaction-design) Model states and transitions for a component as a state machine. → Why use it: The component states you forgot — loading, empty, error, partial, offline — get caught here, not in QA.

28. /interaction-design:error-flow (Designer Skills → interaction-design) Design error handling for a feature, end to end. → Why use it: Error states are 60% of the design work and get 5% of the attention. This rebalances that.

29. cognitive-load-assessment (Inclusive Design Skills → cognitive-accessibility) Assesses a flow for cognitive load — memory demands, attention requirements, decision complexity. → Why use it: Catches the kind of complexity that doesn’t show up in heatmaps but kills task completion for tired, stressed users.

30. /cognitive-accessibility:review (Inclusive Design Skills) A full cognitive accessibility review across cognitive load, plain language, wayfinding, error handling, focus, and memory. → Why use it: It evaluates whether a tired, stressed, unfamiliar user can complete the task without help. That bar is harder to clear than WCAG.

F. Validation — making sure it works before you ship

31. /prototyping-testing:evaluate (Designer Skills → prototyping-testing) Run a heuristic evaluation with severity-ranked findings. → Why use it: Nielsen’s ten heuristics, applied systematically. Catches issues a usability test would flag but cheaper.

32. /prototyping-testing:experiment (Designer Skills → prototyping-testing) Design an A/B experiment with hypothesis, success metrics, and sample size guidance. → Why use it: Experiments designers run that actually have statistical validity.

33. /design-research:test-plan (Designer Skills → design-research) Create a complete usability test plan — recruitment, tasks, success criteria, observation rubric. → Why use it: The plan is where most usability tests fail. This fixes that upstream.

34. /interview (prep or summarize) (PM Skills → pm-product-discovery) Prepare an interview script with JTBD probing questions, or summarize an interview transcript into JTBD, satisfaction signals, and action items. → Why use it: The same skill before and after. Reduces interview work by half.

35. /analyze-test (PM Skills → pm-data-analytics) Analyzes A/B test results — statistical significance, sample size validation, ship/extend/stop recommendation. → Why use it: For the moment you have a result that “looks positive” and need to know if you can actually ship it.

G. Designing AI products (because we all are now)

36. model-interaction-design plugin (AI Design Skills) Seven skills for how humans and agents take turns — mixed-initiative interaction, turn-taking patterns, interruption handling. → Why use it: The foundation. If you’re designing anything agentic and haven’t thought through turn-taking, you’re going to ship something brittle.

37. error-personality (AI Design Skills → system-behavior-shaping) How the agent shows up when it fails. Tone, voice, recovery framing. → Why use it: AI products break differently than software. Error states are a brand surface now.

38. harm-anticipation (AI Design Skills → ai-alignment-reasoning) Map the ways your agent could cause harm before launch. Outside-of-the-model alignment work. → Why use it: The kind of thing legal asks about at sign-off. Better to have done it.

39. handoff-protocol (AI Design Skills → design-agent-orchestration) Design how agents (or agent ↔ human) hand off control. Non-negotiable for multi-agent systems. → Why use it: Where most multi-agent systems silently degrade. This skill names the patterns.

40. prompt-architecture plugin (AI Design Skills) Chain-of-thought, constraint specification, system prompts. Seven skills for the prompts your product runs on. → Why use it: Prompts are now product surfaces. This is the discipline for treating them like one.

H. Execution & delivery

41. /write-prd (PM Skills → pm-execution) Generates a comprehensive 8-section PRD from a feature idea or problem statement. → Why use it: PRD quality is now the rate-limiting input for agent-driven build. This is the easiest upgrade you can make.

42. /design-ops:handoff (Designer Skills → design-ops) Generate a developer handoff package — measurements, behaviours, edge cases, QA checklist. → Why use it: Handoff docs engineers actually use. The QA checklist is the part that surprised me.

43. /accessibility-decisions:handoff (Inclusive Design Skills) Generates an accessibility specification for engineering — specific HTML elements, keyboard behaviours, screen reader announcements, test cases. → Why use it: Replaces “make it accessible” with a testable spec. Should be standard practice by now.

44. pre-mortem (PM Skills → pm-execution) Risk analysis classifying threats as Tigers (real and urgent), Paper Tigers (look scary, aren’t), or Elephants (slow-moving but enormous). → Why use it: The classification is what makes this useful. Most risk reviews treat everything as equally urgent.

45. /sprint retro (PM Skills → pm-execution) Structured sprint retrospective facilitation. → Why use it: Retros that don’t dissolve into vibes. Pair with the meeting summarizer (#46).

46. summarize-meeting (PM Skills → pm-execution) Meeting transcript → decisions + action items. → Why use it: The one PM skill every designer should also install. Decisions that get recorded survive. The rest evaporate.

I. Personal infrastructure — the underrated category

47. /designer-toolkit:write-rationale (Designer Skills → designer-toolkit) Write design rationale for decisions you’ve made. → Why use it: The single most important skill on this list. Every rationale you write is judgment your future self (and your team) can retrieve later.

48. /designer-toolkit:write-case-study (Designer Skills → designer-toolkit) Generate a portfolio case study from a project. → Why use it: The portfolio version of the rationale skill. Use the same writing as both — internal documentation today, hiring evidence tomorrow.

49. accessibility-decisions plugin (Inclusive Design Skills) Documents why accessibility decisions were made, so they survive team changes and refactors. → Why use it: MC Dean’s hardest plugin to build because the problem it solves is cultural, not technical. Knowledge preservation. Worth its weight.

50. /proofread (PM Skills → pm-toolkit) Grammar, logic, and flow checking with targeted fixes. → Why use it: For everything you write that someone else will read. Calibrate it once to your voice and it earns its keep weekly.

How to actually use this list

Don’t install all 50. That’s the trap.

Here’s the order I’d recommend:

Week 1 — install three things: Layers (start with /layers-orient), PM Skills’ pm-product-discovery, and Designer Skills’ designer-toolkit. That’s already 25+ skills covering discovery, framing, and personal documentation.

Week 2 — add one specialty plugin based on what you’re actually working on this month. Designing an AI feature? ai-design-skills. Auditing accessibility? inclusive-design-skills. Building a design system? design-systems from Designer Skills.

Week 3 — keep what survived, delete the rest. Most skills won’t stick. That’s fine. The two or three you actually use have already paid for the install effort tenfold.

The shift these skills represent is not “AI does the work.” It’s that the shape of design work is now installable — discovery loops, framing patterns, audit checklists, decision documentation. Things that lived in senior designers’ heads now live in markdown files anyone on your team can run.

That’s the real moment. Don’t miss it because someone told you AI is just for prototyping.

All five repos, one more time

All MIT-licensed. All forkable. All built by people whose Substacks are worth subscribing to:

If you install something based on this list and it makes a difference, tell me which one. I’ll keep this catalog updated.

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论