omd-ultradesign

Files (1)

• SKILL.md

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:omd-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`.

## New pages: work like a designer

A new product or landing (taskNeed `new-product` or `new-marketing`) follows this section, "Words, type, and
flow" and the graphic bullet only. The rest of this file (reference ledgers, `ref context`, cases and judgments,
lifecycle manifests, feedback reports) is for existing work. Spend the time building, looking and cutting.
1. Truth: read the project, README first, and write `.omd/studio/brief.md`: what it really does, for whom, its
   personality (logo, README voice), the one message, the user's exact asks word for word. List every documented
   capability with the demo that shows it: the page's material. Keep the README's logo and all not asked away.
2. Study: two or three finished sites in the project's spirit, `omd studio refs <url>... --json`; look at each
   first screen, full page and section crop beside its measured `study.json`.
3. System: borrow ONE site's measured system in `.omd/studio/system.md` (type ramp, at most three weights,
   rhythm, product framing, motion, its signature) with identity from the project's logo and voice, and
   `.omd/studio/system.json` `{"reference", "sizes", "weights"}`. Every size and weight comes from it.
4. Key visual first: the product's real look made in code (`data-product`), large and crisp, playing its real
   flow on its own; never a recording. Look at it alone and refine until it could sit on the reference.
5. Build at the reference's rhythm and depth, compositions varied, real logo in the header. Subtract with
   `omd studio check`; compare your page beside the reference and fix the biggest differences, three passes at most.
6. Finish: `omd lifecycle finish --json` builds, measures logo, 3D and system on the real page and compares the
   render once with the reference; the page ships with what that look still names.

## 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.
- 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 only. Ship graphics as live three.js scenes on the page (look at one alone with
  `omd render <graphic> --graphic`): a rendered PNG of a scene is a picture of 3D, CSS cards are a diagram,
  a page shrunk into a frame is a thumbnail. Each graphic argues one claim with one protagonist made from
  this product's real material. No invented example sites, placeholder shapes, captions or disclaimers on
  the art. When the product runs, show it working with real footage (`omd record`) or the real UI, never a
  redrawn mock. Show the logo the README shows, as shipped, never redrawn. Generic icons and 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, and say briefly which relationship applies here; do not turn an example into a blanket
no-card, giant-type, photo, palette or motion rule. Cases are worked decisions, not visual
references, permissions or approval.

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, not style rules; 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.

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

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