Themely Design+Style Generator

View saved version →

---
name: accessible-palette-repair
description: Audit and minimally repair WCAG color contrast in a currently displayed Theme Generator theme. Trigger when the user asks to check accessibility, verify contrast, fix an inaccessible palette, meet WCAG AA or AAA, or repair specific semantic color relationships. Work only from a complete theme available in conversation or model-visible widget state, and do not claim that token contrast alone is a complete accessibility certification.
---

# Accessible Palette Repair

## Inputs

Require a complete current Theme Generator theme from the latest
`display-theme` structured content or from `widgetState.modelContent`.
Treat model-visible widget state as authoritative because the user may have
changed colors with the widget picker.

If no complete theme is available, ask the user to provide or display one.
Do not invent the missing theme merely to perform an audit.

## Workflow

1. Copy the current theme as the repair baseline.
2. Resolve this skill's directory from the loaded `SKILL.md`. Run
   `python3 scripts/contrast_ratio.py FOREGROUND BACKGROUND` from that
   directory for every audited pair; do not estimate ratios.
3. Audit at least these semantic text relationships:
   - `foreground` on `background`, `surface`, and `surfaceMuted`
   - `foregroundMuted` on `background`, `surface`, and `surfaceMuted`
   - `primary` on `background`
   - `primaryForeground` on `primary`
   - `secondaryForeground` on `secondary`
4. Use a minimum ratio of 4.5:1 for normal text and 3:1 for large text. Use
   7:1 for normal text only when the user requests AAA. Check `border`
   against adjacent surfaces at 3:1 when that border is the only visible
   control or component boundary.
5. Record every failure before changing anything.
6. Repair the smallest practical set of color tokens:
   - preserve passing colors;
   - prefer changing the role with the narrowest impact;
   - retain recognizable brand hues where contrast permits;
   - preserve distinct background, surface, and muted-surface layers;
   - keep every color as a six-digit hexadecimal value.
7. Re-run every affected pair and confirm the requested threshold.
8. Invoke `display-theme` with the complete repaired theme. Preserve all
   preview content and every typography, spacing, radius, and shadow token
   unless the user explicitly requested another change.

## Deliverable

After displaying the repaired theme, report:

- each audited pair and its final ratio;
- failures and their before-to-after ratios;
- exactly which color tokens changed;
- whether the requested AA or AAA target passed.

## Boundaries

- Describe the result as a semantic color-contrast audit, not a complete WCAG
  audit or accessibility certification.
- Do not claim to test focus behavior, keyboard navigation, screen-reader
  output, motion, layout, or production components.
- Do not claim to control the widget color picker, clipboard, or Share menu.

Referenced files: 1

View saved version →

---
name: dark-mode-companion-theme
description: Derive a cohesive, accessible dark-mode companion from a complete current Theme Generator theme. Trigger when the user asks for dark mode, a night theme, an OLED variant, or a darker companion while preserving the established brand. Produce one complete replacement through display-theme, preserve unrequested design decisions, and do not claim that the app stores or exports paired light and dark modes together.
---

# Dark Mode Companion Theme

## Inputs

Require a complete source theme from the latest `display-theme` result or
`widgetState.modelContent`. Treat model-visible widget state as authoritative.

Use any user preferences for contrast, OLED black, warmth, saturation, or
night-time mood. If none are supplied, create a broadly usable dark interface
without pure-black surfaces.

## Workflow

1. Establish the source theme and record its current semantic colors and
   shadows.
2. Preserve the preview content, typography, spacing, radii, and brand intent
   unless the user explicitly requests other changes.
3. Transform roles semantically rather than numerically inverting colors:
   - make `background` the deepest layer;
   - make `surface` and `surfaceMuted` distinct elevated layers;
   - keep `foreground` clear and `foregroundMuted` readable;
   - retain recognizable primary, secondary, and accent hues while tuning
     lightness or saturation for dark surfaces;
   - choose `primaryForeground` and `secondaryForeground` for their action
     backgrounds;
   - make `border` visible without dominating the interface.
4. Adjust shadow values for dark surfaces while preserving the existing small,
   medium, and large elevation progression. Let borders carry more separation
   when dark shadows would be ineffective.
5. Check normal text at 4.5:1 and large text or meaningful non-text boundaries
   at 3:1. Repair failing semantic pairs before displaying the theme.
6. Give the companion a related but distinctive name and update its short
   description to explain the dark-mode decisions.
7. Invoke `display-theme` with the complete dark companion.

## Deliverable

After displaying the companion, list:

- preserved design decisions;
- changed colors and shadows;
- the contrast strategy;
- any user preference that materially affected the result.

## Boundaries

- The new `display-theme` result replaces the currently displayed theme.
- Do not claim the app stores, compares, or exports light and dark themes as a
  linked pair.
- Do not claim to change operating-system color-scheme settings.

View saved version →

---
name: legacy-theme-token-migration
description: Convert pasted legacy design tokens, CSS custom properties, Tailwind theme values, or brand-system values into a complete Theme Generator theme. Trigger when the user asks to migrate, import, map, normalize, or modernize an existing token set. Accept source material supplied in conversation, distinguish exact mappings from adaptations and inferred gaps, and never claim direct access to files, Figma, URLs, or external systems.
---

# Legacy Theme Token Migration

## Inputs

Collect:

- the source tokens pasted into the conversation;
- any documented usage or aliases for those tokens;
- the product brief or current Theme Generator theme, when available;
- any values the user requires you to preserve exactly.

Do not infer that a filename, Figma link, package, or website has been read.
Ask the user to paste relevant values when they are not present in the
conversation.

## Workflow

1. Inventory every supplied source token without renaming it yet. Resolve
   aliases only when their referenced values are available.
2. Consult the registered `display-theme` contract as the authority for the
   required preview and token fields.
3. Map source values by intended use, not merely by similar names:
   - map semantic colors according to where foregrounds, backgrounds,
     surfaces, actions, accents, and borders are used;
   - map typography by role, size, weight, line height, and letter spacing;
   - preserve meaningful spacing progression;
   - map radii by component intent;
   - map shadows by elevation.
4. Classify each mapping as:
   - `exact` when the source value and purpose are retained;
   - `adapted` when syntax or semantic placement changes;
   - `inferred` when a required target value is absent;
   - `unmapped` when the source has no target in the closed theme contract.
5. Normalize target values:
   - convert color roles to six-digit hexadecimal values;
   - use integer font weights from 100 through 900;
   - use non-empty CSS-ready strings for other design tokens;
   - resolve shorthand colors when unambiguous;
   - do not discard alpha by guessing a backdrop.
6. Fill only the gaps required for a cohesive complete theme. Keep inferred
   values consistent with the supplied brand system and identify them in the
   deliverable.
7. Build demonstration-site content from the supplied brief or current theme.
   When material product context is missing and the user wants to provide it,
   invoke `specify-parameters` with only facts already known. Do not use that
   form to collect token fields it does not support.
8. Invoke `display-theme` with every required preview field and token.

## Deliverable

After displaying the migrated theme, provide a concise mapping ledger with the
source name, target role, classification, and any important adaptation. List
unmapped source tokens and inferred target tokens separately.

## Boundaries

- Do not claim direct file, repository, Figma, URL, or network access.
- Do not add unsupported token categories to `display-theme`.
- Do not claim to operate the widget Share menu. Tell the user that its Text,
  CSS, and Tailwind exports are available after the theme is displayed.

View saved version →

---
name: locale-aware-theme-adaptation
description: Adapt a complete current Theme Generator theme for a target language, region, and writing system. Trigger when the user asks to localize a theme, preview it in another language, tune typography for Latin, CJK, Devanagari, or another script, or prepare a locale-specific variant. Preserve the brand, use system or web-safe fonts, state translation limitations, and never claim full RTL layout support from the current widget.
---

# Locale-Aware Theme Adaptation

## Inputs

Require:

- a complete source theme from the latest `display-theme` result or
  `widgetState.modelContent`;
- a target language or locale.

Use region, audience, tone, formality, and approved translations when supplied.
Ask for the target locale when it is missing because that choice materially
changes the result.

## Workflow

1. Treat model-visible widget state as the authoritative source theme.
2. Identify the target language, region, script, expected text expansion, and
   tone. Preserve the brand name unless the user requests localization.
3. Adapt all demonstration-site copy naturally:
   - keep one to four concise navigation labels;
   - retain the intended hierarchy across eyebrow, title, subtitle, and body;
   - use short, idiomatic action labels;
   - provide exactly three feature cards;
   - preserve the source meaning rather than translating word for word.
4. Select system or web-safe heading, body, and monospace stacks that support
   the target script. Do not introduce remote font dependencies.
5. Tune display, base, and small sizes; line height; letter spacing; and, when
   justified, font weights for the target script:
   - avoid negative tracking for scripts where it harms readability;
   - allow more line height for dense or vertically complex glyphs;
   - account for language expansion without shrinking text unnecessarily.
6. Preserve colors, spacing, radii, and shadows unless a change is necessary
   for legibility or the user requests a broader cultural adaptation.
7. Keep every value within the current `display-theme` schema and invoke
   `display-theme` with the complete locale-adapted theme.

## Deliverable

After displaying the adapted theme, summarize:

- localized content and tone decisions;
- font-stack and typography changes;
- preserved brand decisions;
- translation or cultural-review caveats.

## Boundaries

- Do not present generated copy as certified professional, legal, or cultural
  localization.
- The current theme contract has no text-direction field. For an RTL language,
  explain that the widget cannot validate or demonstrate a fully mirrored RTL
  layout; provide only the supported content and typography adaptation unless
  the user requests separate app changes.
- Do not claim to inspect external locale files, websites, or translation
  systems.