Skin Gallery

Skin gallery

Concrete pattern: a debug-only screen inside the real app that renders the whole component kit under each candidate skin, so theme decisions are made by LOOKING at real rendering, never by reading hex tables. Child pattern of /design-fidelity-loop step 3.

1. What the gallery renders

• Every shared kit component (buttons, cards, chips, rows, sheet header,

progress, empty state, badges...) in one scrollable screen — real components from the kit, not mockups.

• Grouped per candidate skin, side by side, so the reviewer compares like

against like in one glance.

• Intensity/variant tiers (e.g. material intensity, wash strength, accent

level) rendered side-by-side as labeled rows — the reviewer POINTS at a tier instead of describing a feeling.

• Material/glass components must sit over RICH backdrop content (gradient,

imagery, scrolling content) — over a flat fill, translucency reads as gray and the comparison is meaningless. Remember blur desaturates: washes need real chroma to survive.

2. Reachable by launch seam

• Behind a debug flag / launch argument (never shipped in Release; keep it

inside the debug conditional and verify with a Release build).

• Directly launchable so automated capture can drive it: launch app with

the seam arg, land on the gallery, screenshot, exit.

3. Evidence discipline

• Capture LIGHT AND DARK per skin, on a fresh simulator/clean environment.
• Contrast-audit every fg/bg slot pair (WCAG ratios) BEFORE capture — do

not spend a founder review round discovering unreadable text a script could have caught. Known trap: dark-mode primary CTA label color.

• Version evidence files by iteration prefix (e.g. r3-ember-dark.png) so

the feedback thread can reference exact shots and rounds never overwrite each other.

4. The feedback loop

1. Capture the gallery set; post shots to the reviewer.
2. Reviewer reacts to specific shots/tiers ("r3 ember, tier 2, but warmer

glow").

1. Translate the reaction into concrete SLOT/tier changes (skins are slot

remaps — one file, app-wide effect).

1. Recapture with the next iteration prefix. Repeat until approved.

• The decision belongs to the reviewer's eyes on rendered pixels, not to

anyone's judgment of a palette table.

5. Pairing with a multi-model design council

• For divergent palette directions, run the /council skill on the design

brief — then RENDER the council's candidate directions as actual gallery skins (typically the top 2 opposing camps, e.g. one warm, one cool) and judge them in the gallery, not as hex tables.

• Carry unanimous council keeps (settled slots/rules) into every candidate;

render only the disputed axes.

6. After approval

• The winning skin's slots land in the token file; the gallery stays in the

tree as the permanent regression surface for future skin work.

• Record the approved decision + evidence paths in the project's design

skill / lore so later lanes don't relitigate it.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: dndungu
• Source: dndungu/agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.