Design from scratch

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).