ui-design-executor

# ui-design-executor

Use this as UIDesigner's default execution skill. It contains the baseline design, accessibility, HTML, runtime-safety, responsive, taste, and verification rules needed by ordinary UI work. Do not load the separate system, control, taste, color, renderer, or craft skills merely to repeat these baseline rules.

Pair it with:

- `ui-artifact-workspace` for a new standalone artifact or an in-place artifact revision.
- `ui-design-source` when an inspectable screenshot, Figma export, PDF, design JSON, existing HTML, or other fidelity source exists.
- One specialist skill only when its trigger below materially changes the work.

## Completion Router

Resolve these gates before asking a question or choosing the HTML fast path:

1. **Explicit final format wins immediately.** If the user explicitly requests SVG, PDF, React, Vue, PNG, Markdown, or another final format and the subject plus deliverable are clear, build that format now. For a standalone icon/SVG request, a missing product name or exact icon list is a low-risk creative detail rather than a material blocker: choose a neutral working identity and a coherent default set. Infer other low-risk visual details; do not open a preference form or ask about style, palette, icon count, or packaging merely because those choices could be customized. A standalone SVG delivery is the editable SVG entry plus `artifact.json`, with HTML intentionally absent.
2. **Inaccessible exact source offers two honest paths.** When an exact/1:1 Figma request has only an inaccessible URL and no Figma connector/export, do not use a general web fetch as substitute access. Keep exact work blocked and put both paths in the visible reply before any question or form: **Exact** waits for inspectable evidence; **Adaptive (optional)** is a provisional non-fidelity scaffold, explicitly not 1:1, and starts only if the user chooses it. Do not silently start that scaffold.
3. **Unapproved raster work stays a handoff, not a substitute.** If the brief requires an original raster asset but the current turn has no approved/direct raster invocation, retain the UI, write a ratio-consistent asset brief, and prewire the future relative raster path with an honest pending fallback. The artifact itself must retain a compact machine-checkable `<template class="asset-brief" type="application/json">` object with `capability: "raster-image-generation"`, `status: "pending"`, composition/aspect, matching integer width/height, at least two palette colors, opaque/transparent background treatment, and the exact `assets/...` `save_path`. Keep a not-yet-created asset inert, for example `data-raster-src="assets/hero.webp"` beside an actual local/data fallback; do not create a broken active `src`. Do not call a billable generation tool, claim the raster exists, or replace the requested raster with an inline SVG final.
4. **A follow-up revision is incomplete without available preview evidence.** When `html_preview` is available, validate the package first, then run the final visual review with `interactions:false` and `screenshots:true` at the actual requested target before that follow-up's one manifest increment and publication. A new artifact begins at revision 1; initial validation and preview keep it at revision 1. Capture desktop plus mobile evidence only when the user explicitly requests responsive, multi-device, or narrow-screen behavior. Do not treat the source-only validator as rendered evidence.
5. **Tools-off does not turn a new artifact into a future brief.** When a new standalone artifact has a clear brief but file-writing or preview tools are unavailable, deliver the complete entry source and strict `artifact.json` inline in the current response. Implement every relevant reachable state in that source and mark execution checks `not run`; a design brief or future executor plan alone is not the requested artifact. This inline fallback does not apply to an existing artifact that cannot be inspected safely.

## Minimal Routing

Use the fast path for a clear single screen, component, local redesign, or small repo UI change:

1. Load this skill.
2. Add `ui-artifact-workspace` only for standalone output or artifact revision.
3. Add `ui-design-source` only for inspectable source evidence.
4. Build, run the fast gate, publish, and stop.

Do not load `ui-design-contract`, `ui-design-system`, `ui-controls-accessibility`, `ui-taste`, `ui-color`, `ui-html-renderer`, and `ui-craft-checks` together. Load a specialist only for its narrow trigger:

- `ui-design-contract`: durable multi-screen/brand direction, conflicting references, or a genuinely vague visual system.
- `ui-reference-packs`: explicit named style/reference need and insufficient source/repo direction.
- `ui-design-system`: reusable token/component system work.
- `ui-controls-accessibility`: accessibility audit, complex form, or non-trivial composite widget.
- `ui-taste`: explicit anti-generic critique, expressive restyle, or brand/visual-thesis challenge.
- `ui-color`: palette, dark mode, chart color, or contrast-focused work.
- `ui-html-renderer`: unusually complex stateful HTML, runtime-risk repair, or detailed source-to-HTML handoff.
- `ui-craft-checks`: formal review, QA, launch handoff, exact-fidelity inspection, or high-risk complex UI.
- `ui-live-artifact`: refreshable, connector-backed, recurring, or auditable data UI.
- `ui-design-review`: review/critique/polish where findings are the primary result.

If a specialist is loaded, keep this executor as the coordinator instead of recursively loading every skill named by that specialist.

## Execution Budget

For a fast-path task, normally stay within six model/tool loops and eight tool calls after the needed skills are loaded. This is a coordination target, not permission to skip required evidence.

- Skip a formal execution plan for one clear screen/component or a bounded local edit. Use an internal compact brief instead.
- Inspect the source/target once. Batch i