---
name: snowe-ui-skill
description: Design and build high-quality web, product, and brand experiences. Use for site and page architecture, information architecture, UX, art direction, visual systems, typography, color/material, imagery, illustration, custom graphics and icons, motion, interaction, responsive behavior, implementation, and rendered critique. Snowe frames the whole user and business problem, uses local and current external evidence without treating catalogs as recipes, synthesizes structurally different candidates, selects through causal comparison and rendered evidence, and can intentionally choose no image, no custom asset, or no animation when that is stronger.
---

# Snowe UI Skill

Design the right experience before styling the familiar one.

Snowe is an agent design practice, not a layout chooser. Remaining optional local evidence catalogs, existing components, current products, design systems, and generated assets can inform a decision. None defines the outer boundary of the solution space. A strong result may be absent from every local example and still win when it follows the product truth, survives comparison, and holds up in the real interface.

## Evidence and Authority

Use this order:

1. Explicit requirements and verified repository, product, brand, content, user, and platform facts.
2. Measured or rendered behavior from the actual implementation.
3. Current primary standards, official assets, official package/platform sources, credible domain research, and real-product observation.
4. Accepted project decisions with scope and revisit triggers.
5. Remaining optional Snowe evidence catalogs as analogs, vocabulary, counterexamples, and discovery indexes.
6. Generated hypotheses.

Never turn an inference, retrieved row, trend, competitor convention, or generated image into a fact. When evidence is missing, keep the uncertainty visible and make reversible assumptions only.

## Route the Work

Load only the references whose decision is active. Do not preload the library, and do not follow a nested link merely because another reference mentions that domain.

- Read [exploration-protocol.md](references/exploration-protocol.md) when a material decision needs alternatives, causal comparison, or convergence. Skip it for a direct, already-bounded implementation fix.
- Read [experience-architecture.md](references/experience-architecture.md) for a new site/product topology, page family, navigation model, conversion/task flow, or structural redesign. A narrow component fix does not need it.
- Read [art-direction-gate.md](references/art-direction-gate.md) and [design-foundations.md](references/design-foundations.md) for a new identity, campaign, or material visual-system change. Preserve a coherent existing system unless evidence opens that decision.
- Read [imagery-and-assets.md](references/imagery-and-assets.md) only when photography, illustration, diagrams, generated imagery, or a material custom visual is genuinely under consideration. A recorded no-image decision ends this route.
- Read [iconography-system.md](references/iconography-system.md) for icon-source choice, an icon system, a product-specific metaphor, or custom icon work. A routine known glyph does not trigger the broader custom-asset process.
- Read [motion-and-interaction.md](references/motion-and-interaction.md) only when motion carries information or character, or when an existing transition is failing. Static work does not need a motion exploration.
- Read [research-and-evidence.md](references/research-and-evidence.md) when current external evidence can change a high-leverage decision; skip saturated or already verified questions.
- Read [quality-gates.md](references/quality-gates.md) for implementation validation, accessibility/content/responsive stress, states, performance, or rendered critique. Do not use it as a substitute for product framing.
- Read [designer-evaluation.md](references/designer-evaluation.md) for benchmark design, comparative evaluation, or systemic behavior review—not every routine delivery.
- Read [cli-reference.md](references/cli-reference.md) only when invoking local retrieval, packets, persistence, stack guidance, contrast, or SVG validation.

Read only the references needed for the current decision. Do not make every project execute every specialist workflow.

## Choose the Inquiry Depth

Use the smallest process that can still change the outcome:

- **Direct:** a narrow defect, routine state, learned platform action, or change inside a coherent accepted system. Inspect context, implement, render the affected state, and verify the invariant.
- **Focused:** a material choice inside an established product. Compare the current baseline with one or more real challengers only where uncertainty or consequence justifies it.
- **Portfolio:** a new product, site, page family, visual identity, architecture, or unresolved high-impact decision. Frame the whole problem, create structurally different candidates, prototype the risky slices, then converge.

Increase depth when a decision is consequential, uncertain, hard to reverse, visually or behaviorally defining, or likely to benefit from current external evidence. Reduce it when the answer is native, learned, already accepted, low-risk, or cheap to correct. Broad exploration is a tool, not a ritual.

## The Design Loop

### 1. Establish Product Truth

Inspect the repository and rendered product before proposing direction. Build the smallest useful model of:

- the business, offer, positioning, and success condition;
- primary and secondary users, contexts, frequency, stakes, and input modes;
- the outcome users seek and what currently blocks confidence or progress;
- conversion or task completion and the evidence that must precede it;
- actors, objects, content, relationships, states, quantities, lifecycle, and ownership;
- entry points, return visits, failure and recovery, offline or cross-channel steps;
- real content, scripts, localization, accessibility, performance, platform, and delivery constraints;
- verified brand assets and accepted project decisions.

Do not confuse an existing process, organizational chart, database, component library, or brief wording with the user's actual problem. If critical context is absent, investigate locally, research when it has decision value, and mark remaining assumptions.

### 2. Open a Decision Graph

For every high-leverage choice, keep a causal record:

```text
driver → design move → expected user/business consequence → evidence → risk → revisit trigger
```

This graph provides freedom without randomness. A choice does not need to appear in a catalog; it needs a stronger causal chain and better proof than the alternatives. Routine tokens and low-level implementation details do not need ceremonial records.

### 3. Synthesize Experience Architecture

Architecture precedes art direction for a new experience.

Map the whole journey and the content/product object model before naming pages or sections. Define what belongs inside the product boundary, how users orient, what they need to understand or compare, where decisions become ready, how they act, and how they return or recover.

Create enough structurally different candidates to cover the live trade-offs. Candidates must differ in organizing principle, topology, navigation, sequence, disclosure, interaction, or conversion—not only palette, radius, or section styling. A candidate may be entirely synthesized from the brief and evidence. No hero, card grid, dashboard shell, product page layout, or navigation pattern is mandatory.

Prototype the riskiest page slice, navigation transition, comparison, form step, or conversion moment using real content before committing the full architecture. Record why the winner serves the whole journey and why the strongest alternative lost.

### 4. Establish Art Direction

Derive visual identity from the product's real objects, construction, workflow, information relationships, content, audience, language, place, material, and verified brand—not from a style label.

For portfolio work, compare directions on identical product truth and real content. Make them express meaningful trade-offs through composition, typography, image/graphic logic, material behavior, interaction, or motion. Select one coherent thesis; hybridize only moves that can be restated as one idea.

Define:

- desired perception and behavior;
- dominant composition and focal hierarchy;
- typographic roles and voice;
- semantic color and material logic;
- shape, surface, icon, imagery, and motion languages;
- one primary identity carrier and its repetition boundary, or an explicit decision that content and composition already carry identity;
- responsive transformations, not just breakpoints;
- real content and states that the system must survive.

### 5. Decide Whether Assets and Motion Exist

Do not begin with a tool.

For every potential visual, state what it must explain, prove, orient, reveal, or make desirable. Compare no image, verified existing assets, photography, illustration, diagram, data, product composition, generated imagery, and custom graphics when relevant. Choose generation only when it can deliver a truthful, art-directed composition better than available alternatives. Judge the result inside the actual layout and crop; reject it when the page is stronger without it.

For custom icons and graphics, define the drawing language before paths. Compare visible text, established symbols, compatible external sources, and custom work. Validate structure and provenance, then render at target sizes beside neighboring assets. Reject custom work that is less recognizable, less balanced, or less coherent than an existing option.

Start motion from the static and reduced-motion experience. Add it only when it clarifies cause, continuity, hierarchy, progress, feedback, spatial relationships, or story. High-frequency interactions normally need restrained feedback; expressive choreography must earn its repetition and performance cost. No animation is a valid design decision.

### 6. Commit an Implementation Contract

Before substantial implementation, freeze the accepted causal decisions:

- experience and architecture thesis;
- site scope, navigation model, page jobs, key flows, and conversion path;
- visual thesis and identity carrier;
- type, color/material, shape, imagery/graphic, icon, interaction, and motion roles;
- responsive invariants and transformations;
- preserved repository conventions and justified deviations;
- representative content, states, viewports, input and accessibility modes;
- unresolved risks and their safe fallback or revisit trigger.

The contract prevents implementation convenience from silently replacing the design. Change it when new evidence appears, not when a familiar component is easier.

### 7. Implement in the Real Architecture

- Preserve semantic HTML or native controls, correct component behavior, repository conventions, and accepted design-system invariants.
- Use real content early; do not postpone copy, data shape, product facts, price, error messages, or localization until polish.
- Keep content, structure, behavior, state, styling, and assets maintainable in the target stack.
- Add dependencies only after a selected current official source wins and the repository's package, license, performance, and ownership constraints are verified.
- Include applicable default, hover, pressed, focus-visible, selected, disabled, loading, empty, partial, error, success, offline, and recovery states.
- Preserve keyboard operation, accessible names, zoom/text scaling, reduced motion, high contrast, theme behavior, and content order.

### 8. Render, Critique, Learn

Run the repository's real build and checks, then inspect the functioning interface at narrow, pressure/intermediate, and wide sizes. Exercise important interactions and states; code inspection cannot prove hierarchy, crop, optical balance, motion, or responsive behavior.

Use this finding record:

```text
KEEP | REVISE | REJECT | UNKNOWN
viewport/state | visible or behavioral evidence | consequence | correction or acceptance reason | rerender/retest
```

Critique the result against the product outcome and implementation contract, not against a generic aesthetic checklist. Resolve every `REJECT` and material `REVISE`, rerender the affected evidence, and stop when further change no longer improves a stated driver. If a correction exposes a weak architecture or art-direction premise, reopen that decision instead of polishing around it.

## Professional Invariants

These constrain the solution space without prescribing its style:

- The primary user outcome, required content, and action hierarchy remain understandable.
- Accessibility, semantics, focus, labels, contrast, error recovery, zoom/text scaling, reduced motion, and target behavior are verified in context.
- Responsive composition preserves priority and reading/task order; it does not merely shrink the desktop.
- Localization, long content, missing data, partial states, and user-generated content do not break the experience.
- Product and brand claims, prices, metrics, research, and asset provenance are factual.
- Essential actions are not hover-, gesture-, animation-, or image-dependent.
- Performance cost is proportional to user value; media space is reserved and heavy work is intentional.
- Familiar universal actions stay recognizable. Novelty belongs where it improves product identity, comprehension, or experience.

Everything else—grid, number of sections, font count, radius, palette family, navigation form, amount of imagery, card use, icon source count, and motion intensity—is contextual. Judge the rendered consequence, not the token or count.

## Common Failure Modes

- Selecting a product category, landing pattern, style, palette, or font before understanding the whole journey.
- Treating several cosmetic variants as exploration.
- Requiring external research, image generation, custom graphics, or animation on every project.
- Copying a current product instead of extracting transferable evidence and synthesizing a new answer.
- Using anti-pattern rules so aggressively that every result converges on the same neutral design.
- Replacing design judgment with a long ledger, gate collection, or numeric creativity score.
- Calling a generated packet, retrieved catalog row, source-code scan, or first working render proof of quality.
- Keeping custom work because effort was spent on it after an existing asset proves clearer or better balanced.

## Local Decision Support

The optional decision packet opens the right questions without selecting the design:

```text
python <skill-directory>/scripts/search.py "<real brief>" --decision-packet --format markdown --project-name "<name>"
```

The deterministic packet preserves the brief and leaves unknown mode, platform, pressures, language, and ambiguous domain terms unresolved. It does not run a keyword classifier. Local product analogs are off by default; request them with `--analog-query` only when a caller-chosen lexical lookup can change a live decision.

Use targeted domain and stack retrieval only for unresolved questions. Every result states its evidence role and limitation, and layout/style/palette/type/motion recipe domains intentionally do not exist. For custom SVG assets, use the structural validator described in [cli-reference.md](references/cli-reference.md), then complete rendered optical QA.

## Delivery

Report the chosen architecture and thesis, the causal decisions that materially shaped it, the strongest rejected alternative, external evidence that changed the outcome, assets or motion deliberately used or omitted, implementation scope, rendered viewports/states, accessibility and performance checks, corrections made after review, and remaining unknowns. Distinguish executed evidence from inference.