MCPInstall

designer-skills

111 skills from owl-listener/designer-skills

Install every skill in this repository:

npx skills add https://github.com/owl-listener/designer-skills
  1. 1

    Structure a design presentation for a specific audience and decision. Use when presenting internally. For a portfolio narrative use case-study; for the written argument use design-rationale.

  2. 2

    Create a modular type scale with size, weight, and line-height relationships. Use when establishing typographic structure. For line length only use readable-measure; for judging type on an existing screen use critique-typography (visual-critique).

  3. 3

    Define an illustration style guide — visual language, colour usage, and application rules. Use when commissioning or standardising illustration. For icons, use icon-system (design-systems).

  4. 4

    Establish hierarchy through size, weight, colour, spacing, and position so the eye lands in the intended order. Use when composing new work. For judging an existing screen, use critique-visual-hierarchy (visual-critique).

  5. 5

    Build a product colour system — tonal scales, semantic roles, and contrast compliance. Use when defining or rebuilding colour from scratch. For dark-mode adaptation use dark-mode-design; for chart palettes use data-visualization; for multi-brand token architecture use theming-system (design-systems).

  6. 6

    Adapt an existing palette to dark mode — surface elevation, contrast rebalancing, and desaturation rules. Use when you already have a light palette to translate. For building the base palette first, use color-system.

  7. 7

    Specify an icon system — grid, sizing, stroke weight, naming, categories, and implementation. Use when standardising iconography. For broader illustration, use illustration-style (ui-design).

  8. 8

    Diagram screen-level paths, decision points, and branch logic. Use when specifying how a feature is traversed. For the emotional end-to-end arc, use journey-map (design-research).

  9. 9

    Define a responsive grid — columns, gutters, margins, and breakpoint behaviour. Use when establishing page structure. For the spacing scale inside components use spacing-system; for cross-device behaviour use responsive-design.

  10. 10

    Select chart types and design data encodings — marks, axes, labels, and accessible chart styling. Use when presenting data graphically. Owns chart selection and encoding only; the categorical colour ramp itself belongs to color-system.

  11. 11

    Run an expert review against Nielsen's heuristics and domain criteria, with severity ratings. Use when you need findings without recruiting participants. For a facilitated team feedback session, use design-critique (design-ops).

  12. 12

    Create a spacing scale from a base unit with rules for when each step applies. Use when standardising padding and margins. For page-level columns and gutters, use layout-grid.

  13. 13

    Design layouts and interactions that adapt across screen sizes and input methods. Use when one design must serve many viewports. For the underlying column grid use layout-grid; for OS-specific patterns use platform-conventions.

  14. 14

    Specify one micro-interaction completely — trigger, rules, feedback, loops, and modes. Use when handing a single interaction to engineering. For motion craft alone use animation-principles; for multi-state components use state-machine.

  15. 15

    Specify wireframe layout — content priority, component placement, and annotation. Use when defining structure before visual design. For grid mechanics, use layout-grid (ui-design).

  16. 16

    Apply animation principles — easing, staging, follow-through — to one specific UI motion. Use when tuning how an animation feels. For product-wide duration and easing tokens use motion-system (design-systems); for a full interaction spec use micro-interaction-spec.

  17. 17

    Audit token usage across a product for coverage, drift, and hard-coded values. Use when tokens exist and you suspect they are being bypassed. For defining tokens in the first place, use design-token (design-systems).

  18. 18

    Design waiting experiences — spinners, skeletons, optimistic updates, and progressive reveal. Use when content takes time to arrive. For the latency budget itself use doherty-threshold; for success confirmation use feedback-patterns.

  19. 19

    Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use heuristic-evaluation (prototyping-testing).

  20. 20

    Model component behaviour as explicit states, events, and transitions. Use when a component has many interacting states that must be exhaustive. For the feel and feedback of a single interaction, use micro-interaction-spec.

  21. 21

    Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use handoff-spec.

  22. 22

    Design error prevention, detection, and recovery across a product — message content, placement, and escape routes. Use when errors span multiple flows. For validation inside a single form, use form-design.

  23. 23

    Define and organise tokens for colour, spacing, type, and elevation with naming and usage rules. Use when establishing the token layer. For auditing existing usage use design-token-audit (designer-toolkit); for multi-brand mapping use theming-system.

  24. 24

    Craft a portfolio case study with narrative arc, process evidence, and outcomes. Use when telling a project's story to an external audience. For an internal stakeholder deck, use presentation-deck.

  25. 25

    Design a usability study — research questions, methodology, participant criteria, metrics, and facilitation guide. Use when planning the study as a whole. For writing the task scenarios inside it, use test-scenario (prototyping-testing).

  26. 26

    Write interface copy — microcopy, error messages, empty states, and CTAs. Use when the words are the deliverable. For content structure and ownership, use content-strategy (ux-strategy).

  27. 27

    Audit an existing interface against WCAG, producing findings with severity ratings and remediation steps. Use when you have a design or build to assess now. Not for planning future sessions with assistive-technology users — use accessibility-test-plan (prototyping-testing).

  28. 28

    Define actionable principles that resolve trade-offs when the team disagrees. Use when the same decisions keep getting relitigated. For a single project's framing, use design-brief.

  29. 29

    Specify one component — props, states, variants, accessibility, and usage rules. Use when defining a library component. For the reusable doc scaffold use documentation-template; for a problem-solution pattern use pattern-library.

  30. 30

    Map one persona's end-to-end experience with stages, touchpoints, emotions, and pain points. Use when improving an existing experience. For the multi-channel ecosystem use experience-map (ux-strategy); for screen-level paths use user-flow-diagram (prototyping-testing).

  31. 31

    Design theming architecture — brand variants, dark mode, and high-contrast — mapped through token layers. Use when one system must serve multiple themes. For a single palette use color-system (ui-design); for dark mode craft use dark-mode-design (ui-design).

  32. 32

    Choose prototype fidelity and method to match the design question and the decision at stake. Use before building a prototype. For what to test once it exists, use test-scenario.

  33. 33

    Compare UX patterns, features, strengths, and gaps across rival products. Use when you need to know what others actually do. For deliberately adopting their conventions, use jakobs-law (interaction-design).

  34. 34

    Write a project brief — problem space, constraints, audience, and success criteria. Use at kickoff for one specific project. For long-horizon aspiration use north-star-vision; for reusable decision rules use design-principles.

  35. 35

    Design confirmations, status updates, and notifications that tell users an action registered. Use when the system must acknowledge success or change. For waiting states use loading-states; for failures use error-handling-ux.

  36. 36

    Design gesture interactions for touch and pointer — swipe, drag, long-press, and their discoverability. Use when input is gestural. For OS-standard gestures on iOS and Android, use platform-conventions (ui-design).

  37. 37

    Build research-grounded personas with goals, frustrations, and behavioural patterns. Use when decisions need a consistent user reference. For one session's emotional snapshot use empathy-map; for motivation framing use jobs-to-be-done.

  38. 38

    Map functional, emotional, and social jobs with outcome expectations. Use when reframing decisions around motivation rather than features. For who the user is, use user-persona.

  39. 39

    Map the full ecosystem of touchpoints, channels, and relationships across a service. Use when the experience spans more than one product. For one persona's linear journey use journey-map (design-research); for backstage operations use service-blueprint.

  40. 40

    Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use design-qa-checklist; for reusable library components use component-spec (design-systems).

  41. 41

    Build a Says, Thinks, Does, Feels map for one user or segment. Use when sharing user understanding quickly. For a composite archetype with goals and behaviours use user-persona; for cross-session themes use affinity-diagram.

  42. 42

    Establish naming rules for components, tokens, and layers with patterns and worked examples. Use when names are inconsistent or being set. For what the tokens actually contain, use design-token.

  43. 43

    Generate a reusable documentation scaffold for components, patterns, or guidelines. Use when standardising how the system is documented. For the content of one component's spec, use component-spec.

  44. 44

    Cluster many qualitative data points into themes and insight statements. Use when synthesising across multiple sessions or sources. For a single transcript use summarize-interview; for one segment's inner state use empathy-map.

  45. 45

    Structure a pattern entry — problem context, solution, usage examples, and related patterns. Use when documenting a recurring solution rather than a component. For a single component's API, use component-spec.

  46. 46

    Analyse open or closed card sort results into a proposed grouping and label set. Use after running a sort study. For turning that evidence into a full structure, use information-architecture (ux-strategy).

  47. 47

    Write rationale connecting decisions to user needs, business goals, and principles. Use when a decision needs defending in writing. For a live conversation, use design-negotiation.

  48. 48

    Write a structured interview guide — warm-up, core exploration, and wrap-up. Use before running interviews. For analysing what comes back, use summarize-interview.

  49. 49

    Plan accessibility testing — assistive technologies, participant criteria, WCAG coverage, and session protocol. Use when scheduling testing with real AT users. Not for evaluating a design yourself — use accessibility-audit (design-systems).

  50. 50

    Design an A/B experiment — hypothesis, variants, primary metric, and sample size. Use when a change can be measured quantitatively at scale. For observing behaviour qualitatively, use test-scenario.

owl-listener/designer-skills Agent Skills | MCPInstall