no-ai-slop

No AI Slop: Warm Color Palette for Software Design

When to use it

Use this skill when designing user interfaces, dashboards, marketing sites, or any software visual system where the default would be cool blues, purples, or generic tech gradients, and the goal is a warmer, more human feel.

When NOT to use it

Do not use this skill when:

• Brand guidelines mandate specific cool colors.
• Accessibility requirements demand specific contrast ratios only achievable with the brand palette.
• The product is a developer tool where users expect conventional syntax highlighting (blue/purple keywords).
• A design system already exists and cannot be changed.

Prerequisites

• Access to a design tool (Figma, Sketch, Adobe XD, or code-based styling).
• Basic knowledge of HSL/HSB color models.
• Ability to test contrast ratios (WCAG AA minimum 4.5:1 for text).

Procedure

1. Define the warm hue range. Set the primary hue between 15° and 45° HSL (orange to amber). Record the exact hue value.
2. Build a 5-step scale for the primary hue. Create tints and shades at lightness values: 95, 85, 65, 45, 20. Keep saturation between 55% and 75%. Name them warm-50 through warm-900.
3. Select a neutral warm gray. Choose a hue between 25° and 35° at 8%–12% saturation. Create a 9-step gray scale (50–950) for backgrounds, borders, and text. Verify each step against white and black for 4.5:1 contrast.
4. Pick an accent hue. Choose a complementary warm hue: either 5°–15° (red-orange) or 45°–55° (yellow-green). Build a 3-step scale (light, base, dark) at 60%–70% saturation. Use sparingly for CTAs and alerts.
5. Ban forbidden hues. Document in the design system: no hues between 190° and 280° (cyan through purple) in any component, illustration, or marketing asset.
6. Replace standard semantic colors.

• Success: use warm-600 (amber) or accent yellow-green, not green.
• Error: use accent red-orange, not pure red (#FF0000).
• Warning: use warm-500.
• Info: use warm-700 or a desaturated warm brown, not blue.

1. Apply to components. Update buttons, cards, inputs, navigation, and data visualizations to reference only the new tokens. Remove any hardcoded blue/purple values.
2. Test in context. Render three key screens (dashboard, settings, empty state) in light and dark modes. Verify:

• All text meets 4.5:1 contrast.
• Interactive states (hover, focus, active) are distinguishable.
• No forbidden hue appears in dev tools color inspector.

1. Document tokens. Export a JSON/TS token file with names, HSL values, and hex fallbacks. Include a "do not use" list of the banned hue range.
2. Hand off to engineering. Provide the token file, a one-page cheat sheet mapping old semantic names to new tokens, and a checklist for QA to verify no forbidden colors ship.

Rules and constraints

• Mandatory: Primary hue must be 15°–45° HSL.
• Mandatory: No hue between 190° and 280° may appear in production code or exported assets.
• Mandatory: All text must pass WCAG AA contrast against its background.
• Forbidden: Using opacity overlays on cool colors to "warm them up."
• Forbidden: Adding a single warm accent while keeping a blue primary.
• Forbidden: Using "warm" as a vague descriptor without measured HSL values.

Examples

Input

A SaaS dashboard currently uses a blue primary (#2563EB), purple accent (#7C3AED), and gray neutrals. The team wants a warm redesign.

Expected output

• Token file colors.tokens.json containing:
• primary: { 50: "#FFF7ED", 100: "#FFEDD5", 500: "#F97316", 600: "#EA580C", 900: "#7C2D12" } (hue 24°)
• neutral: { 50: "#FAFAF9", 100: "#F5F5F4", 500: "#78716C", 900: "#1C1917" } (hue 30°, 8% sat)
• accent: { light: "#FDE047", base: "#EAB308", dark: "#A16207" } (hue 52°)
• semantic: { success: "#A16207", error: "#EA580C", warning: "#F97316", info: "#78716C" }
• bannedHues: [190, 280]
• Updated Figma library with all components referencing tokens.
• Three screened screenshots (light/dark) showing zero blue/purple pixels in dev tools.

Common mistakes

• Picking a hue at 10° (too red) or 50° (too yellow) and calling it warm orange. Fix: stay 15°–45°.
• Keeping blue for "info" toast because "users expect it." Fix: use warm brown or amber; test comprehension.
• Using opacity on a blue brand logo instead of requesting a warm variant. Fix: get logo redrawn.
• Forgetting dark mode: warm hues shift perception; re-test every token at both backgrounds.
• Naming tokens "orange-500" instead of semantic names. Fix: use primary-500, accent-base so redesigns don't break code.

Final checklist

• [ ] Primary hue measured and locked between 15°–45° HSL.
• [ ] Full 5-step primary scale created with saturation 55%–75%.
• [ ] Warm neutral gray scale created and contrast-verified.
• [ ] Accent hue chosen outside primary range, 3-step scale built.
• [ ] Banned hue range (190°–280°) documented and enforced in CI.
• [ ] Semantic colors remapped to warm tokens only.
• [ ] All components updated to token references, zero hardcoded cool values.
• [ ] Light and dark mode screens tested for contrast and forbidden hues.
• [ ] Token file exported and handed to engineering with migration map.
• [ ] QA checklist includes automated color audit for banned range.