ultradesign

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Ultradesign

Preserve the original request and user-selected model. Keep scope and allowed paths/dependencies.
The model chooses useful methods and delegation. Sequential passes are not independent review.
Pi uses omd_cli; /ultradesign aliases /skill:oh-my-design:ultradesign, not quoted/inline mentions.

Inspect the stack and request. Use `route-input` for existing/bounded work or `product-route-input`
for a new product; validate, classify, then run `omd stage next --json` for the current model-led action.

## One entry: read the situation first

`/ultradesign` is the only OMD entry point. Inspect the actual project and the full request
before choosing the work; never ask the user which mode to use.

- **No product source yet (files to read are material):** greenfield. Build the complete requested product from
  scratch (route `projectMode: greenfield`): start with `omd scaffold` (the official React + Vite + strict
  TypeScript template), structured per `guides/code.md`. Inspect strong references before inventing a direction.
- **Existing project:** read its stack, routes, components, tokens and current renders first, then do
  what the request actually asks. A new feature or surface extends the existing system. A redesign
  first captures the current desktop/mobile screens as the baseline, keeps every function, route
  and data contract, and changes the visual and structural system. A fix stays local. Do not
  restyle untouched areas, replace the stack or drop behavior unless the request says so.
- **Figma link in the request:** the frames are the target. Follow `omd pack guides/figma.md`.
  After implementation, repeat `omd figma diff <frame-id> <page> --json` then
  `omd figma review <frame-id> --json`, apply the isolated reviewer's concrete region fixes exactly,
  and stop only at `match`. Do not chase the similarity percentage; report a fix id unresolved after three reviews.
- **Images or URLs supplied by the user:** preserve the role assigned by the actual request:
  delivery target, inspiration, domain evidence or rejected result. A requested target governs
  fidelity; inspiration informs the new design; a rejected result is a comparison baseline, never
  a direction to reproduce. Never swap a usable user target for discovery, nor make every attachment a target.
- **Interaction states matter as references:** hover, focus, pressed and open states of buttons,
  rows, tabs, menus and inputs carry much of a reference's craft. Capture and compare them, not
  only the resting screen.

Internal guides, read only when they apply (`omd pack <path>`): `guides/references.md`,
`guides/figma.md`, `guides/copy.md`, `guides/code.md`, `guides/landing-basics.md` (basics designers keep), `guides/critique.md`, `guides/audit.md`, `guides/coach.md`.

## Words, type, and flow ship with the pixels

- Labels state the immediate next step and true commitment; never call a preview a booking,
  or soften a real payment, send, publish, or delete.
- Errors say what happened and how to recover beside the affected field; preserve entered data.
- Design applicable loading, empty, error, success, and disabled states as distinct conditions.
- Use one term per concept and one intentional speech level per product speaker; do not copy
  another service's branded vocabulary or use 해요체 to pretend the service is human.
- Remove filler and automatic title-plus-subtitle pairs; supporting copy must add a constraint,
  consequence, evidence, or recovery cue.
- Build semantic type roles from body text first with a compact scale and role-specific leading.
- For Korean labels/headings prefer word-preserving wraps; judge prose measure in rendered pixels,
  do not apply Latin caps tracking to Hangul, and use tabular numerals where numbers compare.
- Give a step one dominant action when the task has one; equal choices and independent regions
  may legitimately have peers.
- Keep keyboard focus visible, pointer targets at least 24px or within a WCAG exception, and
  every form control persistently labelled rather than relying on a placeholder.
- Open the exact pack when needed: forms/errors → `omd pack theory/forms.md`; flow/states →
  `omd pack theory/ux.md`; copy/voice → `omd pack theory/microcopy.md` and
  `omd pack theory/voice.md`; type → `omd pack theory/typography.md`, and before choosing families
  `omd pack theory/font-pairing.md` (bundle-ready fonts, pairings, local files). Use only fonts free of
  licence restrictions (OFL-1.1, files shipped in the project with their licence); never a font with
  extra clauses, personal-use-only terms or an unconfirmed licence; any Korean text →
  `omd pack theory/typography-korean.md`; accessibility → `omd pack theory/accessibility.md`;
  marketing copy → `omd pack theory/web-copy.md`.
  Motion that materially affects the task or identity → `omd pack theory/motion.md`;
  inspect only the matching `motion/recipes/<name>.md` mechanism, not an effects checklist.
- Draft a new landing's hero and unclear sections as page ideas before building them
  (`omd imagegen --kind page`; `theory/imagegen.md`).
- A marketing or launch page needs a graphic language of its own, decided from evidence before
  sections are styled. Search graphic references per graphic job (`omd ref browse search
  cosmos|dribbble|behance|notefolio "<graphic job>"`) and keep the best few with the reason. Generated
  images are ideation (an abstract background may ship one); ship graphics built as lit three.js objects
  and rendered with `omd render <graphic> --graphic` (`theory/imagegen.md`, Graphics); CSS cards are a diagram. Each section graphic argues one
  claim with one protagonist made from this product's real material, cropped to one moment where its
  text reads: a whole page shrunk into a frame is a thumbnail, not a graphic. No invented example sites,
  placeholder shapes, captions or disclaimers on the art. Judge each graphic blind beside a kept one with
  `omd taste graphic <png> --against <kept image.path>` and rework its named tells until it passes or
  three rounds end. When the product exists and runs, show it working with real footage (`omd record`) or the real UI,
  never a redrawn mock. Grey wireframe boxes, generic icons and flat placeholder shapes are unfinished,
  not minimal.

## Default native Pi workflow

When the local install has private designer-source cases, the native route response supplies
their catalog; an empty `omd pack cases` means none are installed, so proceed without them. Before
choosing a visual composition or attempting a structural repair, open applicable cases with
`omd pack cases/<id>`. The ordinary Pi tool delivers the actual whole source frames alongside the
original timecoded caption cues. In other hosts, read the case's frame paths under
`$OMD_DESIGNER_CASES_DIR` (or `cases/` under `omd pack dir`) with the host image reader.
Look at the original problem, the designer's words, the actual changes and rejected alternatives
together. Keep analyst explanation separate from the native source. Explain briefly which
relationship applies to the current content and what does not; do not turn an example into a
blanket no-card, giant-type, photo, palette or motion rule. No extra design document is required.
These are worked decision examples, not the new product's visual references, permissions,
verified business facts or approval. Inspect the opposite example when a treatment looks like a
universal rule: the same designer can remove containers in one task and use them for another.
A case about making an action visible does not settle a product's visual identity. Identify the
actual design question it helps answer; use another relevant original when the needed judgment
is outside that case. Receiving captions and images is not evidence of having applied the judgment.

Every install also ships designer judgments: questions professional designers ask of a rendered
screen, written as situation, question, move, reason and exceptions. Read
`omd pack judgments --surface marketing|product` (no flag for all) before composing and again
before a structural repair. They diagnose content relationships; they are not style rules,
quotas or a decoration checklist, and a judgment whose "Not when" applies does not apply. The
early reviewer answers every judgment, whatever the surface, against the current captures, and a violated
judgment must cite a localized finding, so a retain is impossible while one is violated. In hosts
without the native reviewer, `omd first-render check --json` returns the same `designerJudgments`;
give them to the independent eye with both captures and require one not-applicable, holds or
violated answer per judgment, with each violation repaired as a finding.

Before references or styling, a new surface gets its design brief (`omd schema design-brief`,
`omd brief --input`): audience, the visitor's questions, one message, one named section per question (its references cited under that name),
what is cut and why, and a concept from the product's own material. Existing work states its task
contract: audience/expertise, task frequency, input modes, density need, locale, representative content. When structure is uncertain, explore
alternatives that differ in information structure or interaction model, not recolors.
Build with realistic fixtures first: long names and strings, empty/error/loading states,
and localized text. For meaningful motion, inspect the corresponding live reference trigger
and transition when available; a still original establishes no timing or interruption claim.
Choose source→destination continuity, feedback or expression for the actual action and
frequency. Equal-role controls may share timing; springs, tweens and immediate changes are

From 3x-haust/oh-my-design, MIT.

More from 3x-haust/oh-my-design