Generate Parameterized UI Themes with Spectral Field Rendering

Luminous UI Workshop is a single skill with two explicit modes rather than a generic material library: opal (mapped from "流光溢彩白") and obsidian (mapped from "五彩斑斓黑"). Both modes render a procedural spectral field, built from fBm/domain-warp noise, as a controlled environmental layer sitting behind a stable, information-dense workspace UI (navigation, list/queue, detail pane, metadata, and one signature observation band). The implementation is driven by a serializable manifest that defines a global color-intensity budget, a per-color list (each with its own intensity, peak opacity, spatial scale, and phase in OKLCH space with an sRGB fallback), and field parameters (scale, octaves, warp strength, motion speed, dither strength, luminance cap). Interactive sliders expose the global and per-color intensities, alongside reset, JSON export, and copy actions. When native image inspection or screenshot capture is unavailable, the skill still runs the deterministic pixel checks but marks its own report visual-unverified rather than inferring quality from DOM or CSS alone.

Use it when a request names either mode directly, asks for one unified skill covering both, or needs a reusable parameterized starter that reports total and per-color intensity, OKLCH values, and screenshot-based coverage measurements. Do not use it for a generic theme-token library, or to produce a one-off, unparameterized visual mockup. Before applying it, the skill calls for inspecting the existing project, framework, route, and build system, and it does not authorize replacing an existing design system without authorization.

The primary input is the manifest object, validated against a fixed schema:

{
  schemaVersion, mode, label, preset, seed,
  overallColorIntensity,
  base: { oklch },
  colors: [{
    id, label, oklch, srgbFallback,
    intensity, peakOpacity, lightnessBias,
    fieldScale, phase,
    measuredCoverage, effectiveShare
  }],
  field: { scale, octaves, warpStrength, motionSpeed, staticTime, ditherStrength, luminanceCap },
  output: { colorSpace, p3Enhancement, reducedMotion }
}

Manifests may hold between 3 and 12 colors, and the renderer uploads every configured entry up to that limit. Output is a rendered workspace (WebGL, with a CSS fallback when a WebGL context or shader/program cannot be created) plus a validation and measurement report that separates configured parameter values from measured pixel values - measured per-color coverage is not treated as an exact decomposition of shader energy. The report records modelVision, screenshotCapture, deterministicPixelMetrics, and visualVerificationMode, and can be marked partial, visual-unverified, or blocked when a required capability is missing.

Three bundled Python scripts drive the pipeline: scaffold_template.py copies the neutral starter for opal, obsidian, or both; validate_manifest.py parses a JavaScript manifest through Node and checks required fields and ranges; measure_preview.py measures a rendered pure-field PNG against the configured OKLCH palette and requires optional packages listed in scripts/requirements.txt, exiting with an unavailable-capability message if they are missing. JavaScript manifests are treated as executable code - the skill calls for inspecting them first and running the bundled helpers only on reviewed, locally authored configuration, never on an untrusted or freshly downloaded manifest.

It's for builders and agents implementing a UI that needs a spectral, colorful background treatment matched to one of the two named modes, while keeping semantic headings, labels, focus-visible states, keyboard escape behavior, readable contrast, and a responsive layout down to a narrow mobile viewport intact. It is not intended for teams that just want a generic reusable color or theme library, or for producing an unverified, purely visual mockup without deterministic or model-based checks.