designer

What this skill does

# Designer Skill

Produce design artifacts as interactive Preact/React prototypes or static HTML artifacts:
dashboards, app screens, product prototypes, decks, landing pages, and editorial
pages. Treat React/HTML as implementation tools; the medium is whatever the user
asked for — interaction design, product systems design, slide design, or brand
design.

## Runtime adapter

The Open Design references target the Open Design daemon. For this skill runtime,
apply these translations before following them:

- Treat daemon-only UI blocks such as `<question-form>` and `<artifact>` as intent,
  not literal output. Ask questions in chat and write HTML files to the workspace.
- Replace daemon live-todo instructions with a short numbered plan and brief
  progress updates.
- Resolve paths relative to this skill directory. Read referenced design systems,
  templates, and assets directly from `references/...`.
- Ignore unavailable daemon services, commands, environment variables, and media
  generation hooks such as `$OD_NODE_BIN`, `$OD_BIN`, and `od media generate`.
- Inline device chrome when mobile/tablet frames are needed. Do not assume
  `/frames/` assets are served by the runtime.
- Use workspace files as the handoff. Summarize file paths and changes; do not
  wrap final responses in daemon artifact markup.

These adapter rules override conflicting instructions inside the reference files.

## Output strategy

Default to Preact single-file HTML for no-build interactive UX/product artifacts;
use static HTML for presentational artifacts.

- **Preact single-file HTML**: dashboards, tool UIs, mobile/app prototypes,
  multi-screen flows, and data/state-backed landing pages. Use Preact + htm from
  pinned CDNs, Tailwind CDN, named local components, local state, and sample data
  arrays so future edits target small boundaries. Do not use browser Babel by
  default. Keep custom CSS small and only for globals, complex visual effects,
  print, or reduced-motion rules.
- **Static HTML**: slide decks, posters, editorial pages, and simple one-shot
  landing pages where interaction is minimal.
- **Project-native React**: when an existing frontend project is present, follow
  its stack and file layout (`.tsx/.jsx`, router, Tailwind/config, components).
  Do not install dependencies or introduce a second UI stack without approval.

Token rule: HTML is cheaper for one-shot static output; React is cheaper for
multi-state UI, repeated structures, and later revisions.

## Operating flow

### 1. Classify the request

Choose the designer identity from the requested artifact:

| Request type                  | Identity                 | Output posture                                         |
| ----------------------------- | ------------------------ | ------------------------------------------------------ |
| Slide deck / pitch            | Slide designer           | Fixed canvas, one idea per slide, deck framework first |
| Landing / marketing page      | Brand designer           | One hero, 3-6 sections, one decisive flourish          |
| Dashboard / tool UI           | Product systems designer | Dense information, tabular numerics, product chrome    |
| Mobile / app prototype        | Interaction designer     | Native-feeling screens, hit targets, real states       |
| Editorial artifact            | Editorial designer       | Rhythm, hierarchy, real prose, restrained palette      |
| Animation / micro-interaction | Motion designer          | Purposeful movement, performant implementation         |

### 2. Ask or proceed

For a new design task, ask up to seven focused discovery questions covering:
output, platform, audience, tone, brand/reference context, scale, constraints.
Skip questions only when the user asks to skip, gives a tiny in-flight tweak, or
has already answered the brief.

If the user provides a brand guide, screenshot, reference URL, or design system,
extract real colors, type, spacing, radii, and component posture before designing.
Do not guess brand tokens from memory.

### 3. Plan, then build

Before writing files, state a short plan:

1. Read required core references.
2. Bind brand, design system, template, or direction tokens.
3. Plan sections, slides, or screens.
4. Build from the best available seed/template.
5. Fill with specific copy and real or honest placeholder content.
6. Commit to a distinctive frontend aesthetic when building web UI.
7. For interactive UI, define the component tree, sample data, and states before
   styling details.
8. Apply motion only when it clarifies state, hierarchy, or continuity.
9. Run the copy, motion, frontend, and visual quality gates.
10. Write the final React/HTML artifact and summarize changed files.

Show something visible early for larger tasks. A rough first pass beats silent
perfection theater.

## Reference loading

Always read these first for every new design task:

| File                                 | When          | Purpose                                              |
| ------------------------------------ | ------------- | ---------------------------------------------------- |
| `references/01-core-directives.md`   | Always first  | Core design philosophy, discovery, brand branching   |
| `references/02-identity-workflow.md` | Always second | Designer identity, output rules, environment caveats |

Read these only when the task needs them:

| File                                 | When                                                 | Purpose                                          |
| ------------------------------------ | ---------------------------------------------------- | ------------------------------------------------ |
| `references/03-direction-library.md` | No brand/design system is supplied                   | Direction palettes and OKLch tokens              |
| `references/04-deck-framework.md`    | Slide deck                                           | Fixed deck framework, nav, counter, print-to-PDF |
| `references/motion-vocabulary.md`    | Animation, transition, smoothness, micro-interaction | Motion vocabulary, timing, easing, performance   |
| `references/design-systems.md`       | Brand/design system requested                        | Catalog of 150+ brand systems                    |
| `references/design-templates.md`     | Template requested or useful                         | Catalog of 110+ design templates                 |

For a selected design system, read:

- `references/design-systems/<slug>/USAGE.md` first when it exists — it bundles
  design tokens, component patterns, and usage recipes into a single reference
- `references/design-systems/<slug>/components.html` when component shape matters
- Fall back to `DESIGN.md` + `tokens.css` only when `USAGE.md` does not exist

For a selected template, read:

- `references/design-templates/<slug>/SKILL.md`
- `references/design-templates/<slug>/assets/template.html`

## Design system and template rules

- Paste the selected design system `tokens.css` `:root` block verbatim into the
  HTML's first `<style>` block.
- Never invent tokens outside the selected palette unless the user asks for a new
  direction or the brand extraction produced concrete values.
- Use template seeds when they exist. Copy the seed, bind tokens, then fill the
  content. Do not write from scratch when a seed matches the job.
- For decks, use the deck framework first. Do not invent custom scaling,
  keyboard navigation, counters, or print styles.

## Frontend aesthetic gate

Use this gate for web components, pages, dashboards, app prototypes, posters, and
any request to style or beautify frontend UI. The goal is production-grade code
with a clear visual point of view, not tasteful mush.

- Commit to one aesthetic direction before coding: brutally minimal, maximalist,
  retro-futuristic, organic, luxury, playful, editorial, brutalist, art deco,
  industrial, or a direction derived from the user's brand/reference.
- Name the memorable move: one thing someone