Designer Skills Claude skills

What each plugin in the design-practice collection covers

This repo is the design-practice collection: 111 skills and 34 commands spread over nine plugins. The other four collections live in sibling repos, but adding this marketplace pulls their plugins into the same picker. The README gives counts for most of the plugins in this repo:

The last three plugins are design ops, the designer's toolkit, and visual critique.

Sorted by the job you have in front of you, the skills fall out like this:

• User research. design-research includes affinity-diagram, card-sort-analysis, diary-study-plan, empathy-map, interview-script and behavioural-analytics. Use them for planning studies, writing discussion guides and synthesizing findings.
• Building design systems. design-systems handles tokens, theming and governance, and includes an accessibility-audit skill for WCAG gaps. The designer-toolkit adds a design-token-audit skill for checking token coverage.
• Polishing UI. ui-design is the largest plugin after interaction-design. It covers grids, type, color and platform conventions.
• Validating and critiquing. prototyping-testing holds heuristic-evaluation for solo expert reviews. design-ops holds design-critique for running a session with a group.
• Handing off to code. design-ops includes handoff-spec, alongside design-qa-checklist, design-review-process, design-sprint-plan, team-workflow and version-control-strategy.
• Reporting and debt. design-ops also has design-debt-audit, for inventorying drift, and design-impact-reporting, for presenting results to stakeholders. ux-strategy has metrics-definition for choosing what to measure in the first place.

If you design AI products, the README points you to the separate AI product design collection, which covers model interaction, alignment reasoning, error personality and agent orchestration. Accessibility-first teams have a dedicated inclusive design collection with plugins for cognitive accessibility, accessible content, inclusive personas and adaptive interfaces.

Example workflow: taking a feature from problem to handoff

The commands here all come from the README. The plain-language prompts are examples of what you might type to trigger a skill.

1. Find your stage. Run /designer-toolkit:start-here and describe the work, for example: "I'm redesigning the checkout flow for a mobile app and have analytics but no interviews yet." The README says it names the stage you're at, gives one command to run now and the two that follow, and tells you what you can skip.
2. Frame the problem. Run /ux-strategy:frame-problem to structure the design challenge before any screens exist.
3. Plan research. Ask for the method directly: "Write an interview script for five returning customers who abandoned checkout. Keep the questions non-leading." That request matches the interview-script skill. Once you have notes, ask for an affinity diagram to group them, or for an empathy map.
4. Design the flow. Run /interaction-design:design-interaction for any flow with meaningful state or motion. It produces a complete interaction flow for a feature or component.
5. Pull tokens from existing work. If you already have a stylesheet, /design-systems:tokenize extracts tokens and organizes them by naming, structure and theme mapping.
6. Plan testing. /prototyping-testing:prototype-plan creates a prototyping and testing plan for the initiative.
7. Review the work. For a group session, ask the agent to facilitate a team critique (design-critique). For a solo pass, ask for a heuristic evaluation.
8. Hand off. Ask for a handoff spec and a design QA checklist before engineering starts.

Every step produces written material: plans, scripts, checklists, flow descriptions, token lists. You still do the visual work in your own tools and design files. The plugin structures the design process around that work.

You can also enter halfway. If you only need a usability test plan or a critique agenda, skip start-here and call that skill or command on its own. Install only the plugins you use, and come back to the Discover tab for others later.

Inside a skill: what the agent actually receives

Each skill is a SKILL.md file. It opens with a description that tells the agent when to use it, followed by an outline of the method. Reading two or three of them shows what the agent gets.

design-critique splits a session into three phases. Before: the designer shares goals, constraints, audience and stage, and the group agrees on what feedback is wanted. During: present (5 minutes), clarify (5 minutes), feedback rounds, discussion, capture. After: the designer summarizes, and action items get owners and deadlines. It supplies sentence starters for feedback ("I notice...", "I wonder...", "What if...", "I think... because..."), names four critique types (desk crit, team crit, cross-team crit, stakeholder review) and lists pitfalls such as designing by committee.

design-debt-audit sorts debt into visual inconsistency, structural, accessibility, documentation, and design-relevant implementation debt. An example of the last is hardcoded values used instead of tokens. The process covers scoping and inventory (screenshot every screen and state in scope), then tags each item by severity (critical, moderate, minor) and category.

design-impact-reporting groups metrics into user metrics (task completion, error rate, SUS, activation), product metrics (conversion, onboarding completion, support ticket volume) and business metrics (churn, cost savings, time to market). It then describes two reporting formats: a quarterly design scorecard with three to five metrics per initiative, and a before/after case for shipped work.

These are outlines, not long reference documents. In the sampled folders, the SKILL.md files run from about 1.1 KB (card-sort-analysis) to about 4.8 KB (design-impact-reporting). behavioural-analytics is one exception, with one reference file and one test file.

The descriptions are the most useful part for choosing between skills. Many of them say when to use a neighbouring skill instead. design-critique sends solo reviews to heuristic-evaluation. design-debt-audit sends token coverage to design-token-audit and WCAG gaps to accessibility-audit. design-impact-reporting sends metric selection to metrics-definition. The README's skill index (INDEX.md) arranges every skill by situation and lists the pairs people most often confuse. Check it before you assume a skill is missing.

Setup notes for Claude Code and Gemini CLI

Running /plugin marketplace add Owl-Listener/designer-skills only tells Claude Code where the skills live. Nothing installs until you open /plugin, go to the Discover tab, tick plugins with the space bar and press enter. If the commands don't appear, check that you finished this second step.

That single marketplace lists all five collections. To see only one, add that collection's own marketplace instead, for example:

/plugin marketplace add Owl-Listener/inclusive-design-skills

Then pick plugins from Discover the same way.

For Gemini CLI, each plugin ships as an extension. From your project root, the README gives:

git clone https://github.com/Owl-Listener/designer-skills /tmp/designer-skills
mkdir -p .gemini/extensions
cp -r /tmp/designer-skills/.gemini/extensions/. .gemini/extensions/

This copies the extensions into the current project's .gemini/extensions folder, so repeat it in each project where you want them.

The README's getting-started path targets people with no coding background. It describes Claude Code as a free app and says no terminal is required for the Claude route. The Gemini route does use the terminal commands above.