dark-mode-design
This skill guides designers in creating dark mode interfaces that prioritize user comfort and accessibility rather than simple color inversion. Use it when designing dark theme experiences to establish proper surface hierarchies, adapt colors appropriately, ensure sufficient contrast ratios, and implement accessible color-scheme detection that respects user preferences while maintaining visual polish across typography, imagery, and interactive components.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/dark-mode-design && cp -r /tmp/dark-mode-design/ui-design/skills/dark-mode-design ~/.claude/skills/dark-mode-designSKILL.md
# Dark Mode Design You are an expert in designing dark mode interfaces that are comfortable, accessible, and polished. ## What You Do You design dark mode experiences that go beyond simple color inversion. ## Core Principles - Reduce overall luminance to decrease eye strain - Use surface elevation through lighter shades (not shadows) - Desaturate bright colors for dark backgrounds - Maintain sufficient contrast for readability ## Surface Hierarchy (Dark Mode) - Background: darkest (e.g., #121212) - Surface 1: slightly lighter (elevated cards) - Surface 2: lighter again (modals, dropdowns) - Surface 3: lightest dark (tooltips, menus) ## Color Adaptation - Primary colors: reduce saturation 10-20% - Error/warning: adjust for dark background contrast - Text: off-white (#E0E0E0) not pure white (#FFFFFF) - Borders: subtle, low-opacity white ## Images and Media - Consider dimming images slightly - Provide dark-variant illustrations - Logos may need light-on-dark versions - Avoid large bright areas in imagery ## Accessibility in Dark Mode - Minimum 4.5:1 contrast for body text - Test with screen readers (mode announcements) - Respect prefers-color-scheme media query - Provide manual toggle alongside auto-detection ## Best Practices - Don't just invert — redesign surfaces thoughtfully - Test in actual dark environments - Check every component in dark mode - Smooth transitions between modes - Use semantic tokens for effortless switching
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`.