--- name: ux-design-from-scratch description: Orchestrated, build-from-zero UX workflow. Establishes context once, then composes the generative ladder in order — foundations (color, type, spacing) → components → screens → flows — applying each skill with relevance gating, and hands the result to design-review. Trigger when the user is starting a new product/app/UI from scratch, "help me design an app", "set up a design system and screens", "I'm starting a new product", or any multi-artifact design build — but NOT when they ask for one specific screen or component (let that skill trigger directly). license: MIT metadata: author: uxcel version: "1.0.0" --- # Design From Scratch (UX Creation Orchestrator) Skill ## How this skill behaves (read first) This is the **front door for building a new design from zero**, and the generative twin of `ux-design-review`. Where design-review orchestrates the *validation* direction (generative → audit), this skill orchestrates the *compositional* direction (generative → generative): it sequences the **scope ladder** — foundations → components → screens → flows — pulling in each lower-scope skill as the work needs it, then hands the result to design-review for validation. It is the executable form of the **compositional orchestration** section of `docs/orchestration-policy.md`. Its whole job is to avoid two failures: building a single screen with no system underneath it, and over-building everything (all foundations, all 12 components) when the product only needs a few. **When NOT to use this skill:** if the user asks for one specific artifact ("design a pricing page", "build a date-picker"), let that skill trigger directly. This orchestrator is for multi-artifact, from-scratch builds. Explicit scope overrides orchestration. --- ## Step 0 — Establish the context profile (once) The single most important field here is the inverse of the review case: - **Design system in play?** For a true from-scratch build the answer is usually **no** → the **foundation skills are in scope and come first**. If the user *does* have tokens/a styleguide already, **skip the foundations** and start at components/screens, inheriting their system (the suppression matrix, applied to creation). - **What's being built** — a single screen with its system, a small flow, or a whole product surface? This sets how far down the ladder to go and how many screens/components to compose. - **Platform** — mobile vs. web (changes layout, touch targets, navigation patterns). - **Brand / audience / industry** — drives the gated decisions inside the foundation and screen skills (color emotion, tone, security posture). State the assumptions you're proceeding with, then build in order. --- ## Step 1 — Compose the ladder, gating at each rung Walk the ladder top-down. At each rung, classify the child skills into **core / offer / skip** (see the policy's compositional model) — don't apply every skill at a rung by default. > Child skills are named by their installable skill `name`. Compose one only if it's installed; > if a named skill isn't present, apply that rung's intent inline with general best practice and > note the gap rather than blocking the build. ### Rung 1 — Foundations (only if no design system) Establish the system first so everything above is consistent: - **Core:** `ux-color`, `ux-typography`, `ux-layout-spacing-grids` — a product needs a palette, type scale, and spacing system before screens are meaningful. - **Offer:** `ux-iconography` (if the product is icon-heavy). - **Skip entirely** if a design system already exists — inherit its tokens. Each foundation skill still **gates** its own context-dependent decisions (don't auto-pick dark mode, brand saturation, etc.). ### Rung 2 — Components (only those the screens need) Pull in component skills **on demand**, driven by the screens being built — not all of them: - A form-bearing screen → `ux-inputs-and-forms`, `ux-buttons`, `ux-selection-controls`. - A data screen → `ux-tables`, `ux-search`. - Overlays/feedback → `ux-modals-and-dialogs`, `ux-notifications-and-toasts`, `ux-loaders-and-progress`. - Navigation → `ux-navigation`, `ux-menus`. Building every component skill "to be safe" is the bandwagon failure — only compose what a requested screen actually contains. ### Rung 3 — Screens (the artifacts the user asked for) Build the requested screens with the relevant skill (`ux-login-signup`, `ux-pricing`, `ux-dashboard`, `ux-settings`, `ux-empty-states`, `ux-landing-page`, `ux-activity-feed`, `ux-contact-support`). Each screen skill gates its own context-dependent levers and reuses the foundations/components above rather than re-deciding them. ### Rung 4 — Flows (if the build spans multiple screens as a journey) If the product needs a journey, compose the flow skill (`ux-onboarding`, `ux-checkout-payment`, `ux-error-recovery`, `ux-offboarding`), which sequences the screens into a coherent path. > **Consistency rule:** decisions made at a lower rung propagate up. A color/spacing decision > made once in foundations is reused by every component and screen — don't re-litigate it per > screen. This is the whole point of building bottom-up. --- ## Step 2 — Validate via design-review When the artifacts exist, hand them to **`ux-design-review`** (if installed), which applies the audit policy (Tier A auto-runs; Tier B offered; and since you just *built* the foundations, the visual-foundation audits are **in scope here**, not suppressed — the design system is brand-new and worth checking). Resolve any findings back toward the primary task. If `ux-design-review` isn't installed, run whichever audit lenses *are* present directly, or self-review against the policy. --- ## Common do/don't patterns | ❌ Don't | ✅ Do | |---|---| | Jump straight to screens with no color/type/spacing system | Establish foundations first (when there's no existing design system) | | Build all 12 component skills "to be safe" | Compose only the components the requested screens contain | | Re-decide color/spacing inside every screen | Decide once in foundations; reuse upward | | Run this orchestrator for a single named screen/component | Let that skill trigger directly (explicit scope wins) | | Skip foundations because "the screen looks fine" | A screen with no system underneath isn't a design — it's a mockup | | Declare done after generating | Hand to design-review for validation | --- ## Relationship to the policy This skill *is* the compositional-orchestration section of `docs/orchestration-policy.md` in executable form. If the two diverge, the policy governs; update this skill to match it. Its validation twin is `ux-design-review`. ## Source lessons (Uxcel) This is an orchestrator — its substance lives in the skills it composes. See the source lessons in each foundation, component, screen, and flow skill it routes to (e.g. `ux-color`, `ux-inputs-and-forms`, `ux-pricing`, `ux-onboarding`).