| name | webkit-ui-craft |
| description | Umbrella entry for building product UI on @aziontech/webkit with taste and PRO UX. Explains the 3 principles and the non-negotiable rules, then routes to the focused skills — mechanics (usage), structure (ux-heuristics, ui-states, form, tables, navigation), foundation (baseline-ui), cross-cutting quality (theming-dark-mode, data-viz), polish (motion-polish, impeccable-polish), verification (ui-verify), and adoption (ds-adoption). |
| status | active |
| last_updated | "2026-07-21T00:00:00.000Z" |
| scope | general |
| enforced_by | ["webkit-prefer-over-custom","webkit-tokens","webkit-accessibility","ui-verify"] |
Skill: webkit-ui-craft
Purpose
Make UI built on top of @aziontech/webkit + @aziontech/theme look and feel like the design
system intended: technical, minimal, polished, PRO-UX-first. This is the map to a pack of focused
skills — it carries the shared principles and routes each task to the skill that owns the detail. It
is for consuming apps (composing screens from shipped components and tokens), not for authoring
webkit primitives.
How to use
/webkit-ui-craft — apply the principles below to all UI work in this conversation and route to the
right child skill for the task at hand./webkit-ui-craft <file> — run the progression as a review: structure (/webkit-ux-heuristics →
/webkit-ui-states → /webkit-form → /webkit-navigation) → foundation (/webkit-baseline-ui) →
cross-cutting quality (/webkit-theming-dark-mode, /webkit-data-viz) → polish
(/webkit-motion-polish → /webkit-impeccable-polish) → verify (/webkit-ui-verify). Output each
child skill's findings under its own heading.
The 3 principles
- Tech language. Infrastructure-grade product UI: copy and visuals are precise, calm, and literal
— no emoji-as-decoration, no marketing fluff inside the product.
- Minimal and polished. Remove before you add. Every element earns its place; ornament is the
exception that has to justify itself.
- PRO UX first. Get flow, states, and feedback right before any aesthetic pass. A beautiful
screen with a missing empty/error/loading state is not done.
The non-negotiable rules (detail lives in the owning skill)
- Components only — compose from
@aziontech/webkit; never hand-roll a button/input/modal/
dropdown the system ships. (Find them via the webkit MCP suggest_component or
node_modules/@aziontech/webkit/catalog.json.) See /webkit-usage, /webkit-ds-adoption.
- Tokens only — color, typography, shape, spacing, shadow come from
@aziontech/theme; no hex,
rgb, hsl, or Tailwind palette. See /webkit-baseline-ui.
- Typography hierarchy — only the
text-* tokens, never inverted (text-heading-* > text-body-* > text-label-* > text-overline-*). See /webkit-baseline-ui.
- Spacing rhythm — one
--spacing-* step, applied consistently. See /webkit-baseline-ui.
- Contain the page — cap reading/content width with
max-w-[var(--container-*)], keep
data-dense surfaces fluid; never a raw px/rem width. The full container doctrine (fluid-first
shell, focused-flow centering) lives in /webkit-baseline-ui.
- Token motion only —
animate-* utilities + duration-*/ease-* tokens, with a
motion-reduce:* escape; no animation library. See /webkit-motion-polish.
- Accessible by construction — labels, focus, ARIA state, target size. See
/webkit-form,
/webkit-ui-verify.
- Works in both themes — style through role tokens so light and dark need no per-theme edits.
See
/webkit-theming-dark-mode.
Accessibility is enforced by the shipped accessibility rule and verified at runtime by
/webkit-ui-verify (axe on the rendered screen).
The progression — route by phase
Run roughly in this order; polish amplifies a sound structure, it can't rescue a broken one.
| Phase | Goal | Skill |
|---|
| Mechanics | Import path, tokens, tree-shaking | /webkit-usage |
| Structure | Right component + Nielsen heuristics; the 3 states must exist | /webkit-ux-heuristics |
| Structure | Full loading/empty/error/partial state surface + async scope-lock & toasts | /webkit-ui-states |
| Structure | Accessible forms: fieldset/legend, submit-time required/invalid | /webkit-form |
| Structure | Data tables: data-driven <Table :data :columns>, toolbar, internal scroll, cell recipes | /webkit-tables |
| Structure | The two console shells; one GlobalHeader; user always visible | /webkit-navigation |
| Foundation | Deslop: components-only, tokens-only, hierarchy, rhythm, containers | /webkit-baseline-ui |
| Quality | Both themes work with zero per-theme edits | /webkit-theming-dark-mode |
| Quality | Charts mapped to tokens: form by question, palette, anatomy | /webkit-data-viz |
| Polish | Smooth motion with tokens only | /webkit-motion-polish |
| Polish | The "feels finished" cross-screen sign-off, incl. an earned delight moment | /webkit-impeccable-polish |
| Verify | Drive the screen: both themes, widths, console, axe/a11y, states | /webkit-ui-verify |
| Migrate | Adopt webkit incrementally in an existing app; coverage scorecard | /webkit-ds-adoption |
When to invoke
- Building or reviewing a product screen/flow that consumes
@aziontech/webkit.
- The user asks for "polish", "make this feel better", "deslop", "is this good UX", "review this UI".
- You're about to write UI on top of webkit and want the constraints and the right child skill loaded.
Definition of Done
