Check a Dark Mode Color Palette in Claude Code

Use a practical workflow to review dark mode colors, assign palette roles, and spot weak contrast before implementation inside Claude Code.

check dark mode color palette inside claude code

Contents

  • [Use this review method](#use-this-review-method)
  • [Build a dark palette that stays readable](#build-a-dark-palette-that-stays-readable)
  • [Check the palette inside Claude Code](#check-the-palette-inside-claude-code)
  • [Keep a decision checklist](#keep-a-decision-checklist)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

Dark mode palette checks should start with color roles, not a list of hex codes. Inside Claude Code, review each color as a surface, text, border, accent, or status color, then test whether those roles still work across the whole interface.

Use this review method

  1. Collect the colors used in the dark theme. Group repeated values and ignore one-off image colors unless they are part of the interface. Keep both the hex value and where it appears.
  2. Assign a role to every important color. Typical roles include page background, raised surface, primary text, secondary text, divider, link, button, focus ring, success, warning, and error.
  3. Compare neighboring roles. Dark mode often fails when several surfaces are nearly identical or when muted text is too close to its background. Compare the actual combinations, not just the palette in isolation.
  4. Check states. Review hover, active, disabled, focus, selected, error, and success states. A palette can look balanced in a static screenshot while becoming unclear during interaction.
  5. Check consistency. Similar components should use the same surface and text roles unless there is a clear reason to differ.

A useful output is a table with columns for role, hex, used in, paired background, state, and decision. The final decision can be keep, replace, lighten, darken, desaturate, or reserve for emphasis.

The examples below include a Claude Code capture alongside Notion Developer Platform and Exa MCP Server references. Use them as visual prompts for comparing page structure and color direction, not as proof that their palettes are interchangeable with your project. The supplied color set includes dark greens such as #15502e, #14532d, #233f2a, and #254f1a, plus quieter tones such as #556659, #4a5a4a, and #799c92.

Captured pages

Colors

  • #496c10
  • #15502e
  • #14532d
  • #233f2a
  • #254f1a
  • #1e6f30
  • #295631
  • #556659
  • #4a5a4a
  • #2c7a4a
  • #2a966f
  • #799c92

Build a dark palette that stays readable

Start with two or three background levels rather than many nearly black values. Define a base page background, a raised card background, and an interactive surface. The difference should be visible without making every panel look outlined.

Use the strongest light color for primary text and reserve softer tones for supporting copy. Do not make all text gray by default. Secondary text needs to remain readable at its actual size, especially in navigation, form labels, table rows, and helper messages.

Keep accents purposeful. A saturated green can work for links, buttons, or positive states, but using it for every highlight makes hierarchy disappear. If several green values are present, decide whether they represent separate states or accidental variations.

Check the palette inside Claude Code

Ask Claude Code to trace each dark-theme color to its source and list the components that use it. Then ask it to produce a role-based table and flag combinations that need a visual check. The assistant can help locate variables and usages, but you should still inspect the rendered interface at common states.

Use this prompt:

> List every dark-mode color token used by this interface. Group aliases by actual value, assign likely roles from their usage, and report each text, icon, border, and control color with the background it appears on. Flag near-duplicate surfaces, low-priority text, missing focus states, and colors used for conflicting meanings. Do not change code yet.

After reviewing the report, ask for the smallest token changes. Make changes in one group at a time, then inspect the rendered result again.

Keep a decision checklist

Before accepting the palette, confirm that:

  • page, card, input, and hover surfaces are distinguishable;
  • primary and supporting text are easy to separate;
  • links and buttons are recognizable without relying only on color;
  • focus and selected states remain visible;
  • success, warning, and error colors are not confused with the brand accent;
  • the same token does not mean unrelated things in different components;
  • the palette still works when a user increases text size or uses a dim display.

Fudge lets you help inspect observed color roles, frequency, and contrast from a captured page. Use that evidence as a concrete reference, then make token decisions in your codebase.

Use this in your AI agent

> Review the dark mode color palette in this codebase. Find all color tokens and their usages, group duplicate values, assign roles such as background, surface, text, border, accent, focus, success, warning, and error, and list the paired foreground and background for each important UI element. Flag weak hierarchy, near-duplicate surfaces, unclear state colors, and likely contrast problems. Return a concise table and propose the smallest safe token changes, but do not edit files until I approve the plan. > > Install Fudge for your AI agent to compare the implemented page with captured design references while you work.

How should I organize dark mode colors into semantic tokens?

Use semantic names based on the job a color performs, not its hue. A useful starting set is background.canvas, background.surface, background.elevated, text.primary, text.secondary, text.muted, border.default, border.strong, accent.default, accent.hover, focus.ring, status.success, status.warning, and status.error.

Keep raw values in one palette layer, then map them to semantic roles. This lets you change a green or gray without searching every component. Avoid names such as darkGreen2 or gray700 for component-facing code because they hide meaning.

Ask Claude Code to show every component using each semantic token. Look for tokens used in conflicting roles, such as an accent used for both links and success messages. If two roles need different behavior, split the token even when the current hex value is identical.

For each role, document its intended background and interaction states. This makes future palette reviews faster and gives you a clear checklist when adding a new component.

What should I ask Claude Code to change after the palette review?

Ask for a written change plan before edits. Have it name the token, current value, proposed value, affected components, expected visual effect, and any state that needs a separate treatment. This prevents a broad find-and-replace from changing unrelated UI.

A focused prompt is:

> Based on the approved dark-mode review, propose a minimal token migration. For each change, show the current token, replacement token, affected components, and reason. Preserve visible hierarchy, focus states, and status meanings. Separate safe alias changes from changes that require visual review. Do not modify source files yet.

Then approve one category at a time: surfaces, text, borders, controls, and status colors. After each category, review default, hover, focus, disabled, error, and selected states. If a change improves one screen but weakens another, split the token rather than forcing one value everywhere.

Finish by asking Claude Code to report unused tokens, duplicate aliases, and components that still use raw hex values. Those findings are useful after the visual decisions are settled.

Related questions