Immutable. This exact content is served forever at /api/v1/blob/6d64755a6a00af8a.
--- name: sc-ui description: "SI-Coder visual interface quality skill. Design, audit, and refine web UI with strong hierarchy, typography, spacing, color, density, motion, component states, responsive craft, and an anti-AI-slop filter while preserving an existing product's design DNA by default." use_when: "Use for visual UI design, visual polish, design-system consistency, component styling, layout craft, desktop shell visual structure, responsive visual issues, or anti-slop UI review." do_not_use_when: "Do not use alone when the primary problem is user flow/usability, developer ergonomics, agent ergonomics, infrastructure, or deployment; route through sc-fe/sc-ux/sc-dx/sc-ax/sc-all as appropriate." required_tools: [] security_constraints: "Never request or expose credentials. Never copy proprietary assets or pixel-clone a branded interface when a preset/reference style is requested." references: [] compatibility: "Standalone SI-Coder; host invocation syntax and available tools may vary." --- # sc-ui — visual craft without AI slop ## Language Keep durable instructions in English. Reply in the user's language unless requested otherwise. ## Default behavior Inspect before inventing. If the project already has a coherent UI, preserve its design DNA unless the user explicitly asks for a redesign. Do not reset an existing product to generic defaults. Before editing, produce an internal Design Read from the available product/code/rendered UI: - product type and primary jobs, - audience and expertise, - platform and viewport priorities, - hierarchy and information density, - typography and spacing rhythm, - surface/border/radius/shadow language, - color roles and contrast, - icon and illustration language, - motion language, - existing design tokens/components, - explicit exclusions from the user. ## Anti-slop filter AI slop is not a specific color or component. It is unearned sameness: choices made because they are common in generated interfaces rather than because they serve the product. Apply a purpose test to every visible decision: `What user/product job does this choice serve?` Flag and fix when unjustified: - cards wrapping every section or nested cards with no hierarchy benefit, - decorative gradients/glass/blur/noise that do not communicate state or brand, - excessive pills, badges, rounded rectangles, icon buttons, and floating containers, - generic centered hero/marketing composition inside an application shell, - fake metrics, fake social proof, placeholder dashboards, decorative charts, or meaningless activity, - repeated same-sized modules that flatten hierarchy, - arbitrary huge headings, low-information whitespace, or over-spacious admin/tool UIs, - excessive shadows/radii that erase grouping structure, - animation on everything rather than on state change or spatial continuity, - hard-coded one-off colors/spacing where project tokens already exist, - rebuilding a mature design system instead of extending it. These are detectors, not blanket bans. Keep any pattern that has a clear product, accessibility, or brand reason. ## Visual system contract Prefer a small coherent system over many local decisions: 1. Typography: clear roles for display/title/body/label/code; readable measure and line height. 2. Spacing: repeatable rhythm; proximity communicates grouping before boxes do. 3. Color: semantic roles before decorative palette; preserve brand tokens. 4. Shape: radii/borders/shadows have explicit hierarchy roles. 5. Density: match task frequency and expertise; tools can be compact, reading surfaces can breathe. 6. Components: all interactive states exist — default, hover where relevant, focus-visible, active/selected, disabled, loading, error. 7. Motion: communicate causality, continuity, feedback, or hierarchy; respect reduced-motion preferences. 8. Responsive behavior: preserve task priority rather than merely stacking desktop rectangles. ## Desktop shell rules For application/workbench shells, prefer `frame → navigation → primary work area → contextual tools/inspector` over dashboard-card composition. Keep frequent actions visible, secondary actions discoverable, separators aligned, resize behavior intentional, and selected/focus states unmistakable. Never redesign or modify an explicitly excluded surface. If the user says not to touch mobile navigation, treat it as a hard scope lock. ## Verification gate Do not call visual work done from code inspection alone. When tools allow it, inspect rendered pixels at representative sizes and verify: - hierarchy is obvious in a 3-second scan, - no accidental overflow/clipping/wrapping, - alignment and divider continuity, - typography and density consistency, - component states, - light/dark theme if supported, - responsive behavior, - no new generic/slop patterns introduced. Report concrete defects and fixes, not subjective praise.