dark-mode-converter
Convert a light-only site or app to a real dark mode -- semantic token mapping, elevation-based surfaces, recalibrated shadows and imagery -- not a naive inversion. Handles Tailwind, CSS variables, and styled-components, plus the toggle, persistence, and no-flash boot.
git clone --depth 1 https://github.com/OneWave-AI/claude-skills /tmp/dark-mode-converter && cp -r /tmp/dark-mode-converter/dark-mode-converter ~/.claude/skills/dark-mode-converterSKILL.md
# Dark Mode Converter Build dark mode the way design-mature products do: as a second theme with its own logic, not the light theme with colors flipped. Inversion fails because dark UIs work differently -- elevation is communicated by lighter surfaces instead of shadows, saturated colors vibrate on dark backgrounds, and pure black plus pure white is glare, not contrast. ## Workflow 1. **Tokenize first.** Inventory every color in the codebase. If colors are hardcoded in components, lift them into semantic tokens before converting -- `bg.base`, `surface`, `surface.raised`, `text.primary`, `text.muted`, `border`, `accent`, states. A dark mode built on raw hex replacements breaks on the next feature. (If tokens exist, audit for strays with the same sweep.) 2. **Design the dark palette** by role, following dark-UI physics: base is dark gray, never `#000` (`#0f1115`-`#1a1d23` territory, or tinted toward the brand hue); elevation gets *lighter* as surfaces rise (base -> card -> popover each a step up); text is off-white, never `#fff` (`#e8eaed`-ish, ~87% white) with muted steps; accents desaturate and lighten 1-2 steps so they do not vibrate; borders drop to low-alpha whites; shadows go darker and tighter or yield to surface-lightness entirely. Verify every text/surface pair at WCAG AA minimum. 3. **Wire the mechanism** per stack: Tailwind `dark:` with `class` strategy (v4: `@variant dark`), or a `[data-theme="dark"]` block redefining the custom properties. Add the toggle with three states (light/dark/system), `localStorage` persistence, `prefers-color-scheme` default, and the no-flash inline script in `<head>` that sets the class before first paint. 4. **Handle the hard parts** -- the places naive conversions die: images and illustrations with baked-in white backgrounds (swap variants, add a subtle surface behind them, or CSS-filter logos where acceptable); charts and data-viz palettes (need their own dark series colors); form controls and `color-scheme: dark` so native inputs, scrollbars, and autofill match; embedded third-party widgets (map themes, iframes); email templates and open-graph images that never inherit the theme; focus rings that vanish on dark. 5. **Audit pass.** Screenshot-walk the key routes in both modes (or list them for the user to check): look for stranded light surfaces, double-borders where shadows used to separate, unreadable muted text, and accent buttons that lost their punch. Output `dark-mode-report.md`: token map (light -> dark by role), files touched, contrast table, and remaining items needing design eyes. ## Rules - Semantic tokens or nothing. `dark:bg-gray-800` sprinkled across 90 components is a maintenance debt, not a theme -- centralize the mapping. - Never pure black base, never pure white text. Reserve those for moments, not defaults. - Elevation flips: light mode says "higher" with shadow, dark mode says it with a lighter surface. Convert the logic, not just the colors. - Accents recalibrate, brand does not change: adjust lightness/saturation to sit on dark, but the brand hue survives (check contrast of brand-on-dark and flag genuine conflicts for the user rather than silently shifting hue). - Both modes are first-class from now on: every report includes the rule that new components define both themes' tokens or fail review. - Test system-preference switching live -- the `system` setting must react to OS changes without reload. ## Quick Commands - "Convert this project to dark mode" -- full workflow - "Tokenize my colors first" -- step 1 standalone - "Just design the dark palette" -- step 2 from existing tokens - "Dark mode audit" -- step 5 against an existing implementation
Audit websites for accessibility issues and WCAG compliance. Use when checking accessibility, fixing a11y issues, or ensuring WCAG compliance.
Deploy a 2-layer parallel agent hierarchy for large, parallelizable work — big refactors, multi-file migrations, codebase-wide audits, bulk generation. A top-tier commander (Fable or Opus) orchestrates the swarms; the user picks a power level (Max Power / Heavy / Balanced / Economy) that sets the Opus/Sonnet/Haiku model mix per layer. Layer 1 is 3-50+ specialist agents, each with its own full context window; Layer 2 is 2+ sub-agents per member. Includes git safety, tiered sizing, a pre-deploy gate, phantom-completion checks, and multi-wave follow-up.
Deploys swarms of sub-agents for massive parallel data processing tasks. Unlike agent-army (which is for code changes), this is for DATA tasks -- processing 1000 documents, analyzing datasets, bulk content generation. Configurable swarm size, task distribution, result aggregation, progress tracking, and error recovery.
Designs and deploys custom agent teams for specific business workflows. Interactive discovery of business processes, then generates complete team configurations with specialized agent roles, tool access, communication protocols, and handoff rules.
Agent-to-Agent (A2A) communication protocol. Connect two or more Claude agents that pass messages, share context, delegate tasks, and collaborate. Implements structured handoffs, shared memory, and multi-agent conversations.
Assesses how ready a business is for AI adoption across six dimensions. Evaluates data maturity, tech stack, team skills, process documentation, budget, and culture. Generates a comprehensive ai-readiness-report.md with scores, gap analysis, and recommended starting points. Aligned with OneWave AI's audit methodology.
Generate animated videos and motion graphics from natural language descriptions. Creates a standalone Vite + React project with Framer Motion scenes that auto-play in the browser. Use when the user wants to create animations, motion graphics, video intros, animated presentations, or product demos.
Generate comprehensive API documentation including endpoint descriptions, request/response examples, authentication guides, error codes, and SDKs. Creates OpenAPI/Swagger specs, REST API docs, and developer-friendly reference materials. Use when users need to document APIs, create technical references, or write developer documentation.