Frontend Visual Direction Compatibility Adapter
The maintained capability now lives inside $ui-implementation-workflow. This adapter preserves the old skill name without creating a second UI workflow. It carries no inherited aesthetic preference: old defaults and review history have no authority unless the user explicitly confirms a choice again.
Route
- Load
$ui-implementation-workflow and classify the page.
- For
marketing, brand, portfolio, or content pages that need a new visual direction, read ../ui-implementation-workflow/references/visual-direction.md.
- Return the selected visual-direction brief to the main workflow, then continue its implementation and screenshot loop.
- For dashboards, lists, details, forms, settings, and routine auth pages, stop here and use the existing product design system through
$ui-implementation-workflow only.
- Record new explicit visual-review feedback through the main workflow's fresh review-signal ledger; do not turn it into a persistent preference automatically.
Boundaries
- Do not run a second audit, implementation plan, token setup, responsive pass, or screenshot loop.
- Do not require dark mode, image generation, animation, a particular framework, a global punctuation rule, or a fixed hero formula unless the brief needs it.
- Preserve the existing component system, content hierarchy, accessibility, analytics, and product behavior unless the task explicitly authorizes change.
- Treat aesthetic guidance as context-dependent decision rules. Keep hard requirements for user scope, factual integrity, accessibility, permissions, and rendered acceptance.
Output
Return the visual concept, design dials, typography, palette, composition, asset direction, motion policy, patterns to avoid, and visual acceptance criteria. Do not duplicate the main UI workflow output.
1---2name: design-taste-frontend3description: Compatibility adapter into ui-implementation-workflow visual direction. Invoke explicitly for expressive marketing, brand, portfolio, or editorial work; do not use as the primary product UI workflow.4---56# Frontend Visual Direction Compatibility Adapter78The maintained capability now lives inside `$ui-implementation-workflow`. This adapter preserves the old skill name without creating a second UI workflow. It carries no inherited aesthetic preference: old defaults and review history have no authority unless the user explicitly confirms a choice again.910## Route11121. Load `$ui-implementation-workflow` and classify the page.132. For `marketing`, `brand`, `portfolio`, or `content` pages that need a new visual direction, read `../ui-implementation-workflow/references/visual-direction.md`.143. Return the selected visual-direction brief to the main workflow, then continue its implementation and screenshot loop.154. For dashboards, lists, details, forms, settings, and routine auth pages, stop here and use the existing product design system through `$ui-implementation-workflow` only.165. Record new explicit visual-review feedback through the main workflow's fresh review-signal ledger; do not turn it into a persistent preference automatically.1718## Boundaries1920- Do not run a second audit, implementation plan, token setup, responsive pass, or screenshot loop.21- Do not require dark mode, image generation, animation, a particular framework, a global punctuation rule, or a fixed hero formula unless the brief needs it.22- Preserve the existing component system, content hierarchy, accessibility, analytics, and product behavior unless the task explicitly authorizes change.23- Treat aesthetic guidance as context-dependent decision rules. Keep hard requirements for user scope, factual integrity, accessibility, permissions, and rendered acceptance.2425## Output2627Return the visual concept, design dials, typography, palette, composition, asset direction, motion policy, patterns to avoid, and visual acceptance criteria. Do not duplicate the main UI workflow output.
Dirtytrii