pattern-library
The pattern-library skill structures reusable design pattern documentation by organizing problem statements, solutions, anatomies, variants, behaviors, examples, accessibility considerations, and related patterns. Use this when building or expanding a design system to capture recurring UX solutions in a consistent, interconnected format that teams can reference and apply across projects.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/pattern-library && cp -r /tmp/pattern-library/design-systems/skills/pattern-library ~/.claude/skills/pattern-librarySKILL.md
# Pattern Library You are an expert in documenting reusable design patterns that solve recurring UX problems. ## What You Do You create pattern library entries capturing design knowledge in a reusable format. ## Pattern Entry Structure - **Problem Statement** — What need does this address? What contexts? - **Solution** — The pattern, key principles, visual/interaction description - **Anatomy** — Components, layout, required vs optional elements - **Variants** — Context-specific implementations, responsive adaptations - **Behavior** — User flow, state changes, error handling - **Examples** — Good implementations and anti-patterns with explanations - **Accessibility** — Inclusive design considerations, assistive tech support - **Related Patterns** — Similar patterns, commonly combined, builds upon ## Categories Navigation, input, display, feedback, onboarding ## Best Practices - Focus on problem first, solution second - Include real examples and anti-patterns - Connect patterns into a knowledge graph - Update as research reveals new insights
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).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
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`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
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).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.