Gradient Maker - Linear Color

View saved version →

---
name: brand-gradient-kit
description: Create a role-based brand gradient kit from a brand brief, mood, and optional hex palette, then display it with the Gradient Picker. Use when users ask for a branded gradient system, reusable brand gradients, or coordinated gradients for hero, accent, surface, promotional, and dark roles. Do not use for logo design, image palette extraction, or verified accessibility auditing.
---

# Brand Gradient Kit

Build a coordinated gradient system for distinct brand roles rather than a set of unrelated color experiments.

## Gather inputs

Identify:

- the brand traits, audience, and product context;
- required and forbidden colors, expressed as hex when provided;
- the surfaces or roles the kit must cover;
- the requested mood, intensity, and number of options.

Ask one focused question only when a missing brand color or required role would materially change the kit. Otherwise, make restrained assumptions and state them briefly.

## Build the kit

1. Treat supplied brand colors and prohibitions as hard constraints unless the user explicitly permits variations.
2. Choose one to eight useful roles. Prefer a compact set such as hero, accent, surface, promotional, and dark over near-duplicate options.
3. Establish cohesion with shared anchor colors, deliberate angle relationships, and consistent stop-position logic.
4. Give every gradient a concise semantic name that identifies its intended role.
5. Order the collection from the most prominent brand use to the most specialized use.
6. Call `display-gradients` once with the complete proposed collection and a concise `reason`.

For `display-gradients`, provide one to eight gradients. Give each gradient a name of at most 80 characters, an integer angle from 0 through 359, and two to eight stops. Give every stop a three- or six-digit hex color and a position from 0 through 100.

## Deliver the result

After rendering the widget:

- provide a compact role-to-gradient usage map;
- explain the shared design logic in no more than a few sentences;
- invite the user to adjust names, angles, colors, or stops in the widget;
- point to the widget's Names, CSS variables, Tailwind classes, and swatch-image exports when implementation assets are wanted.

When valid current gradients are available in model-visible widget state, treat them as the current collection during follow-up discussion. Never rely on private widget state.

## Boundaries

- Create linear gradients with opaque hex colors only.
- Do not claim to sample colors from an image or external brand site.
- Do not claim that a gradient passes accessibility requirements. Recommend testing it with its actual text and layout when accessibility matters.
- Do not claim to save a persistent brand library or modify the user's codebase.

View saved version →

---
name: controlled-gradient-comparison
description: Compare linear gradients by varying one chosen design factor while holding the others constant, then display the controlled set in the Gradient Picker. Use when users want to compare angles, stop positions, hues, intensity, or another specific gradient decision. Do not use for unrelated mood-board options or claim that subjective comparisons are measured tests.
---

# Controlled Gradient Comparison

Create a fair visual comparison in which the effect of one design variable is easy to judge.

## Define the experiment

Identify:

- the baseline colors, angle, and stop positions;
- the one factor to vary;
- the intended UI context and decision the user needs to make;
- the desired number of variants, normally three to six.

If the baseline or comparison factor is missing, ask one focused question. Do not silently vary multiple factors.

## Build the variants

1. State the control values and the factor being tested.
2. Choose values that span a useful range without producing trivial duplicates.
3. Copy every fixed property exactly into each variant.
4. Change only the selected factor. When comparing color, define precisely which stop or color relationship changes.
5. Use concise names that expose the tested value, such as `Hero 45deg` or `Hero Midpoint 65`.
6. Order variants logically from the lowest to highest value or from control to strongest change.
7. Call `display-gradients` once with one to eight variants and a concise `reason`.

For `display-gradients`, give every gradient a name of at most 80 characters, an integer angle from 0 through 359, and two to eight opaque hex stops at positions from 0 through 100.

## Report the comparison

After rendering:

- summarize what stayed fixed and what changed;
- give a short evaluation rubric based on the actual use case;
- identify the strongest candidate or tradeoff when the brief supports one;
- offer a narrower follow-up round around the user's preferred value.

## Boundaries

- Keep the comparison linear and hex-based.
- Do not present preference as statistical evidence or measured usability data.
- Do not introduce extra variables for visual variety.
- Do not claim to observe edits held only in private widget state.

View saved version →

---
name: gradient-handoff-pack
description: Prepare a concise, semantically named gradient collection for design-to-development handoff and display it in the Gradient Picker for exact exports. Use when users need gradients organized for UI roles, CSS variables, Tailwind classes, or a shareable swatch sheet. Do not claim to edit source files, operate the widget's export controls, or persist a shared design-token library.
---

# Gradient Handoff Pack

Organize a final or near-final gradient collection so a developer can understand each role and export exact current values from the widget.

## Gather inputs

Identify:

- the product or interface context;
- the required semantic roles, such as hero, card, CTA, accent, or decorative surface;
- fixed gradient values or brand constraints;
- the target handoff formats: named values, CSS variables, Tailwind classes, or PNG swatches.

Use valid gradients from the prompt, conversation, or model-visible widget state when supplied. If no final collection exists, design the smallest collection that covers the requested roles.

## Prepare the collection

1. Assign one clear responsibility to each gradient and remove redundant variants.
2. Use short, unique, semantic names that remain understandable when converted into CSS-variable slugs.
3. Preserve approved colors, angles, stop positions, and collection order.
4. Keep the pack between one and eight gradients, with two to eight stops per gradient.
5. Call `display-gradients` with the complete handoff collection and a concise `reason`.

For every gradient, provide a name of at most 80 characters, an integer angle from 0 through 359, and opaque hex stops positioned from 0 through 100.

## Deliver the handoff

After rendering:

- provide a compact mapping from semantic role to gradient name;
- note any assumption that still needs design approval;
- tell the user to make final visual edits in the widget before exporting;
- direct the user to the Names, CSS variables, Tailwind classes, or swatch-image action matching the requested handoff.

Treat the widget export as the source of exact values after local edits. Do not reproduce supposedly final code from stale pre-edit values.

## Boundaries

- Do not claim to click export controls, write files, install tokens, or modify an application repository.
- Do not invent support for formats beyond the widget's text and PNG exports.
- Do not promise cross-session storage or synchronization with a design system.
- Do not label the pack accessible without separate testing in its real UI context.

View saved version →

---
name: gradient-refinement-ladder
description: Refine an existing linear gradient through controlled, clearly labeled variants and display the comparison with the Gradient Picker. Use when a user says a gradient feels muddy, harsh, flat, busy, weak, or otherwise needs systematic improvement. Require a usable baseline from the prompt, conversation, or model-visible widget state; do not imply access to private widget state or objective visual testing.
---

# Gradient Refinement Ladder

Turn subjective feedback into a controlled comparison that reveals which change improves the gradient.

## Establish the baseline

Identify:

- the baseline name, angle, hex colors, and stop positions;
- what feels wrong and where the gradient will be used;
- any colors or geometry that must remain fixed.

Use a valid baseline from the user's message, earlier conversation, or model-visible widget state. If the actual gradient values are unavailable, ask for them instead of reconstructing them from private state or an unseen image.

## Create a refinement round

1. Restate the problem as a design hypothesis, such as reducing a muddy midpoint or softening a transition.
2. Preserve the baseline as the control unless the user asks to omit it.
3. Choose the smallest relevant adjustment axes from hue, saturation, lightness, angle, stop count, and stop spacing.
4. Create three to five variants. Change one meaningful factor per variant relative to the baseline so the comparison remains interpretable.
5. Name each variant for its change, not with generic labels such as Option A.
6. Keep all user-declared fixed values unchanged.
7. Call `display-gradients` once with the baseline and variants, up to the eight-gradient limit, and include a concise `reason`.

For `display-gradients`, give each gradient a name of at most 80 characters, an integer angle from 0 through 359, and two to eight stops. Use hex colors and positions from 0 through 100.

## Explain the comparison

After rendering:

- list the single intentional change in each variant;
- give a short decision rubric tied to the stated use case;
- recommend one or two candidates without presenting taste as an objective result;
- invite the user to choose a direction for a narrower second round.

In a second round, refine the chosen candidate and drop unrelated branches. Keep the comparison within one `display-gradients` call whenever possible.

## Boundaries

- Work with linear gradients representable by opaque hex stops.
- Do not claim to detect banding, contrast failures, or rendering defects that were not actually measured.
- Do not change several variables in a supposedly controlled variant.
- Do not claim direct control over widget edits or exports.

View saved version →

---
name: light-dark-gradient-pairs
description: Create semantically matched light- and dark-theme linear gradient pairs and display them together in the Gradient Picker. Use when users need coordinated gradient treatments for light and dark interfaces, paired campaign assets, or theme-aware UI roles. Provide visual design guidance only; do not claim verified text contrast, automatic theme switching, or code integration.
---

# Light and Dark Gradient Pairs

Design paired gradients that feel like the same visual identity across light and dark contexts.

## Gather inputs

Identify:

- the brand or anchor colors;
- the UI roles that need paired treatments;
- the desired mood and intensity;
- any fixed colors, angles, or stop positions;
- likely foreground text colors when the user provides them.

Ask a focused question only when the anchor palette or required roles are genuinely unclear. Limit the collection to four pairs because `display-gradients` accepts at most eight gradients.

## Design the pairs

1. Assign a semantic role to each pair, such as Hero, Card, or Accent.
2. Design the light member for a light surrounding interface and the dark member for a dark surrounding interface.
3. Preserve recognizable relationships through shared anchor hues, related angle logic, and deliberate changes in lightness and saturation.
4. Avoid mechanically inverting colors; adjust them to preserve the intended mood.
5. Name members consistently, for example `Hero Light` and `Hero Dark`.
6. Place each light member immediately before its dark partner in the tool input.
7. Call `display-gradients` once with all pairs and a concise `reason`.

For every gradient, provide a name of at most 80 characters, an integer angle from 0 through 359, and two to eight opaque hex stops positioned from 0 through 100.

## Deliver the result

After rendering:

- provide a compact pair-to-role map;
- explain how each dark member relates to its light partner;
- label any foreground-color suggestion as preliminary;
- invite visual adjustment in the widget and point to its exact text or swatch-image exports.

## Boundaries

- Do not claim WCAG compliance or verified contrast across the gradient. Recommend testing real foreground content at representative points.
- Do not claim to implement CSS theme switching or modify application code.
- Do not sample images, websites, or external design systems.
- Use only linear gradients with opaque hex stops.