← ClaudeAtlas

color-skillslisted

Apply a deliberate, non-default color scheme when creating or restyling ANY document, presentation, or spreadsheet — PowerPoint (.pptx), Word (.docx), Excel (.xlsx), or a slide/document-styled HTML artifact. ALWAYS consult this skill for these, even a plain request like "make me a slide" or "write a report" with no mention of color — that silence is the trigger, since the default fallback (Tailwind swatches: blue-900 1E3A8A, green-900 14532D, orange-900 7C2D12, amber-900 78350F, purple-700 7E22CE, slate-900 0F172A, one hue per section) is the biggest tell that output is AI-generated. EXCEPTION — do not trigger for CVs/resumes/cover letters (their own ATS-safe conventions), nor for PDF or markdown output (PDF inherits from its docx source; markdown has no color mechanism). Also trigger on "use our brand colors," "change the color scheme," "use the neutral palette," "pick a different palette," "black and white," or a saved one-word palette name (e.g. "generate alpha").
aishdwivedi27/color-skills · ★ 0 · Data & Documents · score 70
Install: claude install-skill aishdwivedi27/color-skills
# Custom Color Palette ## Why this exists Left unspecified, AI-generated decks and documents default to the Tailwind CSS swatch set, and — worse — assign a different hue to every section or category (blue for one row, green for another, orange for a third). That rainbow-coded, default-blue-and-green look is the fastest way for a viewer to tell a document was AI-made. The fix: use ONE dominant hue family for the entire document, and differentiate sections by lightness/tint, not by switching hues. **Core rule to apply in every case below:** > Use a single dominant color family for the whole document. Differentiate > sections by lightness, not hue. Avoid the default Tailwind palette and avoid > assigning a unique bright color per category — that pattern reads as > AI-generated. ## Checking contrast without guessing "Dark enough for white text" and "≥4.5:1 contrast" aren't things to eyeball. Use this approximation: convert the hex to HSL and look at lightness (L). - L below ~50% → safe for white/light text on top, treat as a dark-text/header candidate. - L above ~55% → too light for white text; darken the same hue (reduce L, keep H and S) until L drops below 50% before using it for text or headers. - L between 50-55% → borderline; darken slightly rather than risk it. This is an approximation, not a WCAG-exact calculation, but it's specific enough to apply consistently instead of relying on visual judgement. Exception: semantic/status indicators (red = at risk, green =