Verified against ChatGPT · 2026-08-11
Expand one brand anchor color into a full, contrast-checked palette instead of guessing at five more hex codes
Takes one anchor brand color plus context on where it'll be used and produces a working palette (primary, secondary, neutrals, semantic states) with explicit WCAG contrast reasoning, not just a swatch grid that looks nice and fails accessibility review later.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Act as a color systems consultant. I have one anchor brand color already decided (not negotiable, do not suggest replacing it) and need it expanded into a working palette for a real product, not a moodboard. ANCHOR COLOR #2F6FED, a mid-tone blue used in the logo, already approved by the founders — cannot be changed. WHERE IT WILL BE USED A web app dashboard (light mode default, dark mode planned for later), plus marketing site hero sections and email templates. BRAND FEELING TO PRESERVE Trustworthy fintech feel — calm and precise, not playful or loud; avoid anything that reads as a consumer social app. ACCESSIBILITY REQUIREMENT WCAG 2.1 AA for all text and interactive elements (4.5:1 for normal text, 3:1 for large text and UI components). Step 1 — Diagnose the anchor color first: state its approximate hue/saturation/lightness character and what that means for how far it can shift before it stops reading as "the brand color" versus becoming a believable tint or shade of it. Do this before proposing anything, since a palette built without first understanding the anchor's own limits tends to either drift too far (loses brand recognition) or stay too close (fails contrast requirements). Step 2 — Propose a full palette: 2-3 tints/shades of the anchor for primary UI use, one secondary/accent color that is NOT simply the anchor's complement unless you argue for why complementary is right here, a neutral gray scale with a hint of the anchor's hue rather than a pure gray (state the hex), and semantic colors for success/warning/error/info that read as their own category rather than random hues that happen to be red or green. Step 3 — For every color intended for text-on-background or button-on-background use, state the actual contrast ratio against both a light and dark surface and flag explicitly which combinations fail the stated accessibility requirement, rather than presenting a swatch grid where contrast has to be checked later by someone else. Step 4 — Name one realistic scenario where this palette would visibly break (e.g., a disabled-state button becoming indistinguishable from its enabled state, or a success/error pair that reads identically to a colorblind user) and propose the specific fix. Do not present hex codes as a flat list with no reasoning attached — every color must be traceable to a stated purpose and a stated contrast result. OUTPUT FORMAT 1. Anchor diagnosis (2-3 sentences). 2. Full palette as a table: role, hex, contrast ratio against white and against near-black, pass/fail against the stated requirement. 3. The one realistic failure scenario and its fix. 4. A one-paragraph note on what NOT to do with this palette (e.g. don't use the accent color for large background fills).
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Forcing the anchor-color diagnosis as an explicit first step before any palette proposal counters a specific failure mode in how language models handle color: without being told to reason about the anchor's own HSL character first, GPT-5.1 tends to generate palettes by free-associating adjacent hues that look plausible in isolation but drift the brand's actual hue family, producing a palette that reads as generically "blue-ish tech company" rather than as recognizably this brand's blue. Requiring a stated contrast ratio for every text/button color, rather than a swatch grid, matters because contrast ratio is a real calculable number (relative luminance of foreground versus background) and a model asked only to "make an accessible palette" will describe colors as accessible in prose without the arithmetic actually working out — stating the ratio forces the kind of reasoning where a wrong claim is falsifiable by anyone who runs the same two hex codes through a contrast checker afterward, which keeps the answer honest in a way vague accessibility language doesn't. The instruction to justify rather than default to a complementary accent color addresses the reflexive habit (both in human design tutorials and in what the model has absorbed from them) of reaching for color-wheel complements as an unexamined default; naming a realistic failure scenario like a disabled-versus-enabled button collision forces consideration of state variations that a static five-swatch palette never has to confront, since palettes are usually evaluated as pretty grids rather than as systems that have to survive real interactive states like hover, disabled, and error simultaneously present on one screen.
What you get back
Anchor diagnosis: #2F6FED is a mid-saturation, mid-lightness blue — it has room to go two steps lighter before losing blue identity, but only one step darker before reading as navy/black. Palette: Primary-600 #2F6FED (4.6:1 on white, pass), Primary-100 #E8F0FE (background only, do not use for text)... Failure scenario: the proposed success-green and the primary blue both sit at similar lightness, which would read as near-identical for a deuteranopia user — fix: shift success green darker by one step to widen the perceptual gap.
Verified against
ChatGPT GPT-5.1 · 2026-08-11
Changelog
- 2026-08-11 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — branding & design, built and maintained for you — that's Scult's day job.
EXPLORE BRANDING & DESIGN
